“It’s no use going back to yesterday, because I was a different person then.”
Five learnings from my first full-time week of Makers Academy.
1. Test-driven development isn’t (just) about preventing screw-ups. It’s more beautiful than that.
You need a program to do something? Previously I’d just write the program and check that it works. Looks okay on my machine? PUSH TO LIVE! Hmm… turns out that isn’t the best idea.
So being test-driven seems sensible right? Sure, but what I didn’t understand before is that the TDD methodology doesn’t just help you prevent errors — it HELPS YOU DESIGN A BEAUTIFUL PROGRAM!
First off — you have to break it down. What’s the simplest feature you can start with? Got it? Then you follow the RED — GREEN — REFACTOR cycle.
- RED: You write a feature (user interface level) test that fails. You replicate that as a unit test. (sorry for jargon).
- GREEN: You write the code to make the tests pass . In the simplest possible way. No fluff.
- REFACTOR: Think you’re done? Nope! Now you should refactor. Apparently you should spend about 25% of your time getting the tests to pass, and 75% refactoring so your code adheres to SOLID principles and is therefore easy to read and maintain.
Then you repeat until you’ve fully implemented your program.
A really nice quote I got from one of the instructional videos was:
“You’re not writing code for a computer. You’re writing code for a human being.”
So TDD isn’t just a useful tool; it’s a moral obligation to your fellow coders.
I have to admit that at first I found TDD counter-intuitive because I was so used to jumping in to write the code — it was a hard habit to break. But having practised it a lot over the last few days, I’m now an advocate.
2. It’s called Git for a reason.
We use Git for version control and we manage it all in the command line which, as an interface, is NOT FRIENDLY TO BEGINNERS. So imagine needing to swap your pair programming partner and choosing a different codebase to work from EVERY SINGLE DAY. In your first week!
I think I’ve finally got the hang of it, but only after a lot of pain and frustration. If you’re suffering from git pain, check out ‘http://ohshitgit.com/’ (thanks Alex Saunders for this link).
3. “Memoization” is not a typo.
So I was looking up some technique and this word ‘memoization’ kept popping up, and I was tutting and chuckling to myself about poor proofreading, thinking that it should be ‘memorization’. Only to realise MEMOIZATION IS AN ACTUAL THING (although for some reason, it’s not in the dictionary. Let me know if you find it!)
As far as I understand it’s a way of improving performance by caching the results of an ‘evaluation’ so that once it’s been done, you don’t need to do it again — therefore SAVING TIME AND PRECIOUS RESOURCES. If you want to know more, here let Wikipedia inform you.
The lesson here? Don’t assume it’s a typing error. It might be YOU that’s the moron.
4. A good code re-factor is sexy as hell.
We had an interactive workshop on object-oriented programming where we had to refactor a program to be more in line with OO principles and thus make it cleaner and easier to extend. Frankly, we were useless at it — as we have been at most of the workshops we’ve done so far. Actually I’ve gotten used to feeling useless and I’m beginning to embrace it!
Anyway, our coach Ben walked us through how HE would do it, and it was absolutely MIND BLOWING. We were totally in awe. Honestly, you should have been there.
5. The teaching style at Makers is really different. Learning is prioritised over task completion.
GCSEs, A-levels, degrees. What do they have in common? You attend the course, you take notes, maybe do some practical work, submit some coursework, and do exams. The emphasis is all on getting through the material and GETTING THE CERTIFICATE.
At Makers, it couldn’t be more different. They actually want you to LEARN and UNDERSTAND. This is emphasised over task completion. And there’s no piece of paper at the end. Just really marketable, up-to-date skills.
Several times this week, my competitive nature has come out to play and I’ve rushed to complete exercises so I could be one of the first to complete the set. WRONG. There is no point completing the set unless you thoroughly understood what you were doing and WHY.
Luckily because of the way we pair program (swapping partners each day and starting with the least advanced codebase), there’s plenty of opportunity to backtrack on material you’ve already completed. One of the best days I had was when I had to go back 4–5 exercises. Only then did I really understand why the code was working and together we made the codebase better.
By the end of Friday, my pair partner and I hadn’t fully finished the challenge and it DIDN’T MATTER because what we had learned had really gone in (well I think it did anyway) and there are plenty more opportunities to go over the more advanced concepts as the course progresses.
Anyway, I’d best go to bed as it’s gone 2am and I have to get up at 7am. Hope you’ve enjoyed this update! As you can tell, I’m loving the course so far!
Frances x
