I’ve just reached the end of Codurance’s utterly fantastic Apprenticeship Program. Looking back on the last three months, I wondered: what advice might I give to colleagues lucky enough to be starting the program in the future? What would I do differently if I could turn back the clock to day one?
On that note, here’s a collection of thoughts about how to get the most out of this amazing opportunity.
With so many world-class developers packed into one office, it’s possible (especially for a junior new starter) to be a bit paralysed by their enormous expertise. When I arrived, I would try to get everything right first time and only ask for code review on polished, perfect work.
It wasn't long before I realised that writing perfect code up-front is quite a challenge. In fact, when you’re using test-driven development properly, it’s impossible: TDD relies on making a mess first and then cleaning it up later (in the ‘refactor’ stage).
One of the great things about Agile is that it values incremental improvement over getting it right first time. For a beginner, this means that progress matters far more than the starting point.
These days, I’m much more comfortable approaching a colleague with something rubbish, and asking them to tear it apart. Then I can learn from the feedback, rinse and repeat. The apprenticeship program makes this possible by design: there’s no consequence if you get something wrong, and lack of knowledge is never met with condescension or disdain. It’s just an opportunity for growth.
(This strategy isn’t unique to coding, of course: it’s Paul Saffo’s “Strong Opinions weakly held” in disguise.)
Software houses often value figuring things out for oneself. There are positive reasons for this: writing custom software means doing something nobody has done before, so creativity and problem-solving persistence are very useful.
That said, as a consultancy, Codurance’s ‘product’ is its craftspeople. So it makes sense to foster a culture of knowledge sharing and constant learning, particularly amongst those who’ll benefit from it the most.
This means that while on the apprenticeship, being stuck on basic stuff has more limited value than it would normally. I realised it was OK to have a lower threshold for asking a craftsperson or a fellow apprentice for help or advice. Besides, as above, you will never encounter condescension or negativity for asking for help, even if you’ve made a mistake (because everyone does).
It can be distressing when, as a junior developer, you ask a question and the response comes back as “it’s a value judgment”. Argh... why isn’t there just a rule we can follow!?
Of course, this is missing the point. As Pedro Santos points out in Agile Technical Practices Distilled, if software development was just about following logical rules, programming jobs would have been automated out of existence by now.
I came to realise that value judgments - situations where there may be some vague heuristics, but no consistent right answer - are where software craftspeople thrive. If nearly everyone gets it wrong, and you get it slightly less wrong, you’re slightly closer to craftsmanship.
The only way to get comfortable making value judgments is experience, experimentation and practice. There are never any guarantees, of course: experience just leads you to make decisions that are more likely to be right in the circumstances.
When learning new programming skills, the little-and-often approach beloved of musicians and language learners isn’t necessarily best. It’s personal, of course, but I realised that when coding, especially in a pair, I’d often not really hit my stride until 60-90 minutes in. When as a musician I could make a big difference to my technical skill even in a focused half-hour a day, that just didn’t seem possible with programming.
If I did the apprenticeship again, I’d switch topics a bit less and do a bit more deep work. Raw coding, solo or in a pair, is incredibly important but it requires effort and very high concentration. It’s very easy to end up not doing it for long enough to really reap the rewards.
Learning is a skill, a muscle which strengthens with regular use. Software developers spend their entire careers learning, so it’s a muscle worth exercising.
On the apprenticeship, I noticed that I vastly preferred to learn new things from the bottom up. In other words, I’d start from axioms or existing knowledge and sequentially build strong, long-lasting blocks of understanding. This method is preferred in school and at university, and it’s great for “evergreen” knowledge, like design and computer science fundamentals.
However, there’s another way to go about it: from the top down. This means attacking a given problem with clear success criteria, and picking up along the way just enough of what you need to solve that problem. To use a software metaphor, it’s designing from the outside in rather than from the inside out. It can be a great way to efficiently acquire more ephemeral knowledge, like frameworks and programming languages.
For consultants, a combination of both approaches works best. With a solid foundation of evergreen knowledge built bottom-up, a craftsperson can walk into a huge variety of development situations, quickly pick up the local knowledge top-down, and start delivering value as soon as possible.
Acquiring the skills the program teaches is rewarding, but can be a challenge. Apprentices must grasp difficult, unintuitive concepts, and form and reform old habits.
Rest (and sleep) are absolutely critical to this process. It’s known that sleep deprivation interferes with the brain’s ability to record new memories (if you’re feeling brave, here’s a paper on the subject). Miss a night’s sleep and you’ll be slower the next day; trying to compensate by working harder will only produce a vicious cycle.
It’s important to mitigate this by respecting the XP principle of sustainable pace. After all, becoming overworked today just steals progress from the future. Codurance supports this by allowing apprentices to find and stick with their own personal learning velocity. 'Graduation' to craftsperson status often takes around three months, but the journey may be shorter or longer depending on individual background and circumstances. This is fine: there’s no correlation between apprenticeship length and later success as craftsperson.
Apprentices are very much a part of Codurance as a whole. They are encouraged to attend and speak at evening catchups, Open Space Days, and meetups. Their opinions on recruitment, sales, management and company culture are valued and encouraged, even if (especially if!) they are controversial. After all, Codurance’s value is its people.
Internal events are just as non-judgmental as the program itself. So it’s a great opportunity to polish presentation skills. It might be scary at first, but then I wished I’d done it more often!
This one’s easy :-)
P.S. If the apprenticeship sounds like it’s up your street, we’d love to hear from you.
