Tag: Programming

on by

A friendlier type of nuking

Our practice tech test for the past two days at Makers Academy was? Refactoring some hideous legacy code. See that method above? That SINGLE method that is over 40 lines long and bursting with nested if/else conditionals?

Yep, that one. So we had to refactor it AND THEN add an additional item type.

(Ever heard of a squint test? Screw up your eyes and just look at the layout — see all those arrows? A bad sign.)

So this is what I did:

1. Wrote some tests
There was one pre-existing test, which was pretty meaningless anyway. I had no idea what all this code was meant to do, nor did I have any intention of losing myself in a forest of nested conditionals. I read the specs and wrote tests to pass the specs. As luck would have it, the hideous nests actually did work, so eventually I had a full suite of tests and a good knowledge of what the program was designed to do.

2. Deleted everything in the update_quality method
Nuking is not always the best method for refactoring, but that code was just irritating me. Luckily I had tests to guide me so I wasn’t too worried about writing the code.

​
3. Googled ‘ways to refactor nested conditionals’
Came up with references to duck typing

4. Took a nap in the sunshine
Seriously. I was tired at this point and knew I had to have a clear grasp of the design before moving forward. So a nap sounded good.

5. Read POODR’s chapter on duck typing
A lot. Also looked into inheritance but that seemed possibly messy.

A big issue at this particular moment was the instruction that I wasn’t allowed to change the item class. Duck typing was a great solution, but it would require changing the item class, which would apparently upset a goblin.

​​6. Damn the goblin, I’m writing well-designed code
Once I made that decision, it was full steam ahead with TDD’d duck typing. I ran into some snafus about how I was storing and calling objects, but after a few hours had sorted those out and it was really simple. I ended up with several small classes and super-extensible code. I added the new feature on in about half an hour, complete with full testing.

7. Inheritance!
At this point I felt I’d done enough original work to watch Sandi Metz’s video on the Gilded Rose. In it, she mentioned that inheritance isn’t always bad, as long as all of the subclasses share the behaviour of the superclass. So I thought, hey why not DRY this out a bit more and create a Product class which will contain the instantiation behaviour common to all the objects? Easy!

8. Satisfying the goblin
On my way back from the gym later that day, I had an epiphany: I could in fact satisfy the absurd goblin by making the original Item class the superclass and having all the other classes inherit their behaviour! It meant a bit of name-switching (my product and item classes switched names, along with all attendant methods), and the one downside is I couldn’t work out how to throw the errors upon instantiation without changing the item class, so the goblin’s code has slightly less functionality. Still, I’m pretty damn happy with this duck typed, inherited code.

You can check out the full code on my GitHub repo. It should be pretty self-explanatory!

Master branch (with errors for instantiating with disallowed max/min quality)
Item-class branch (item class totally unchanged from original repo)

Don’t hesitate to get in touch if you have more ideas on duck typing, inheritance, or just want to chat code. I’m friendly and I like meeting people!

The refactored method

on by

When I found out I was going to be pairing with “Captain Code”, I was curious to work with this snazzy computer program that would somehow mysteriously assist me in my programming learning. I envisioned a chirpy little bot that would come out with such pearls of wisdom as, “Ahoy there, are you sure your constant is defined, matey?”

Obligatory photo of Jack Sparrow. Entirely unrelated to Captain Code, who is much more intelligent.

Needless to say, Captain Code is a loveable pirate captain who retired from the high seas when his wooden leg was destroyed in a cricket match. He has a keen eye for detail, drinks just enough rum to be constantly jolly, and was never a very good pirate because he chatted too much to his captives, became their friends, and let them off for absurdly low ransoms. His profit margins were crap so he reinvented himself as a programming coach and joined a ukulele band.
​

Sing to the Beatles “All you need is love”

Turns out Captain Code is a polite way of saying, “You’re on your own today.”

So after 2.5 weeks of intense pair programming, today I became a lone wolf coder.

To be honest, I was really looking forward to today. I have found the pairing process rather exhausting, being in such close contact with another human being for so long. And while I’ve certainly grown better at it, and worked out when to take breaks and how to communicate to make the experience successful, I was delighted to have the chance to work untrammelled by a pair’s lunch schedule.

​
So here’s my run-down of a day of solo coding.

What went well:
1. My own schedule! I took my lunch break when I wanted it!
2. Pomodoros — I was really disciplined about 25 minutes on and 5 minutes off, and that timer really helped make my day productive.
3. Error debugging — I hit a stride today in debugging errors/fixing failing rspec tests. 
4. Code production — I finished the Single Responsibility principle, so am very happy that I’ve come this far.

What didn’t go so well:
1. I was lonely. I figured working on my own would be a walk in the park, after many years of practising violin 4–5 hours a day alone. Turns out I like talking to people, and this was the first day on the remote course I felt like I wasn’t getting enough human contact. This loneliness had a cascading effect:
2. I was grumpy because I was lonely.
3. I struggled to take breaks, because I was already grumpy so kind of figured I might as well keep on being a grump, and my grumpiness wouldn’t affect a pair. (I took 5 minutes because of my pomodoros, but really would have benefitted from longer breaks as well.)
4. Accountability. I didn’t slack off, but I really wanted to take an hour-long nap or watch TV and finish coding in the evening. This isn’t an option when you’re pairing, so the temptation never comes up. So I wasted mental energy combating this desire.
5. Not having a pair means you miss obvious things! I had to ring up my coach because of an absurdly stuck test and he spotted immediately that “Borg: 3 LS” and “Borg: 3LS” weren’t the same — a pair would have spotted it.

A borg, debatably.

I had wondered if the pair process was the best way of learning — it can be unbelievably frustrating to be at a different stage (whether higher or lower) than your partner — but after today, I can definitely say that I’d rather the frustrations and trials of pairing than doing much more solo coding.

So cheers to my cohort for being full of awesome pair partners!

on by
Me as a kid atop my brother’s car.

Originally published in April 2017.

Makers Academy day 1 of 60 (not counting weekends) is finished. It’s 8:45pm and I am in bed absolutely exhausted and very happy.

We had orientation this morning, learning about how MA functions. It was great to see their intelligent approach to learning and even better to hear from Dana, our Chief Joy Officer (meditation/yoga/life coach). I’m so glad MA encourages us to take care of ourselves!

Then I had a fantastic Alexander technique lesson over lunch, which really helped with some left shoulder issues I’ve been having.

And finally, spent 4.5 hours pair programming. It was an intense experience! Learning to work in close proximity with another human being is always a learning curve but years of playing chamber music have really helped to train me in listening and communicating. We both thought our pair session went really well, we had a good feedback session, and are going to chat on Slack tomorrow morning about what we learned.

The actual coding itself was pretty easy, which is good — the focus was on learning to pair effectively. Am looking forward to some deeper coding challenges!

As soon as we hit 6pm my brain just shut off. While I wanted to do another 5 hours and totally finish the week’s challenges on day 1 (afternoon 1 even!) all of the sudden none of the words on the page made any sense to me so I had to call quits on the session 🙂 .

I then went on a walk for an hour to appease the FitBit gods (while chatting on the phone to a friend, conveniently), came home and ate bacon and porridge for dinner (yum!) and now am struggling to stay awake till 9pm.

So what have I learned from today?
 — I need to read instructions, code, and error messages slowly. I read far too quickly and get away with it a lot, but what’s the rush? Where’s the race? Better to do it slower and more mindfully. Hm, mindful code reading…
– I am very much eyes on the prize — complete the challenge the recommended way before finding other ways to do it. I do think this approach is borne out by Bloom’s Taxonomy — master the apply stage before moving on to the analyze stage.

– I really can’t sit still. In 4.5 hours of pairing (including breaks), I moved from the desk to the floor to lying on the floor (not great for typing but ok for navigating), back to sitting on the floor and ended up at the desk again. I apologise to everyone I am pairing with that I will be roving around.
– I need to wear more comfortable shoes when walking.

​Bye for now!