I was an apprentice at 8th Light from July to November of 2017. It was a great experience, and I learned a lot. Here are a few notes on some takeaways.
Test-driven development (TDD)
One of the mentors told me, about the purpose of tests: “Tests are not there to ensure your program is correct. Tests are there to ensure your program does what you say it does.”
I like this. In the ongoing discussion over whether software is more like math, or more like literature, currently I’m on the literature side. (Surprised? I was!) But the way I see it right now: yes, software eventually gets compiled in one way or another to a sequence of symbols in a formal language, i.e., a whole bunch of ons and offs. But at the level most of us are working at — as the developers of software, or its end-users — we’re trying to represent sequences of actions, summaries of data, or states of systems, and our models have so much less context than the reality we’re representing. The words, sentences, gestures, and functions we use are necessarily encoding a lot of hidden ideas and assumptions.
I like writing tests first because it forces me to think about those assumptions. I have to consider how I want to use some fragment of code before I even have the code available. I might not insist on TDD if it’s not how the team I’m with does things; but the fearless refactoring that’s possible with a well-written slate of tests seems to justify the cost.
My poet and information architect tendencies often lead me to come up with a good number of short, potent words when I go to think about a system I’d like to have. I’ve long believed that complex problems can be broken into simple pieces. But now I’ve seen how breaking a problem up prematurely can lead to problems of a different kind. Sometimes its best to work with one unwieldy lump of code, develop the behaviors you want in that lumpy form, and look for the clean breaking points later in the process. Lots to learn here.
Story points are cool. I have a better sense now for how to give optimistic, realistic, and pessimistic estimates for a particular task. I feel lieske I was just barely starting to figure out the key properties of a good software spike as my apprenticeship ended; a place where I have room to grow is, getting better at converting a quick, dirty, lumpy bit of spike code into an estimate of how long it will take to develop clean code for the story at hand.
I had a great time working with Tam on a ping-pong kata for scoring a bowling game. Pair programming is a great way to keep flexing different muscles as you go about solving a problem. I didn’t have a chance during this apprenticeship to write about Sarah Mei’s excellent talk, “Factory Workshop Stage”, but it gave me lots to chew over about the possible congruences between improvisational theater and software development. Since I have experience in both, I’m going to be wanting to continue to meditate on what practices from the former could be used as the bases of exercises in the latter.
It was great to work in an environment that was so dedicated to learning, and to hewing to a principle of continuous improvement and quality. I’m really excited to bring what I learned to my next gig. (Speaking of which: if you, dear reader, might be the source of that next gig, come check out my homepage, where I’m expanding on what I have to offer for your data, software, or research organization. Or write to me, at tom[remove this]@[also remove this part]mathpunk.net.)