Dear new developer,
I have recently been doing a lot more puzzles. It’s a low tech way to spend time with the family. As I was working on one recently, I snapped two large sections of a puzzle together. It was very satisfying. I mused on how working on a jigsaw puzzle is a lot like coding. You work on small pieces, checking back in periodically with the big picture. Slowly, slowly, you build up toward your goal, which is a working system or a finished puzzle.
Puzzles are like software development in other ways too. For one, it helps to take time away from both a puzzle and a software system periodically. Often when I take a break, I return with both renewed excitement and additional insight. The break can be a night’s sleep, a pause for lunch, even something as simple as a short walk.
Another way I can make progress in either case is to shift my focus. When I’m working on any problem, there are multiple tasks that need to be done. Some are hard, some are easy. Some require deep work, some require conversations with other team members, domain experts, or customers. Just like you can shift from from one section of a puzzle that has you stumped to another, shifting from one software task that you need to do to another is a good way to maintain forward progress. Nothing saps my motivation more than beating my head against a wall.
Finally, the satisfaction when you bring all the pieces of a software system together is similar to when I finish a puzzle. Watching someone use a completed system which I had a hand in building is a joy.
However, puzzles aren’t a precise analog to software systems. There are some substantial differences.
First off, most software systems are far larger than puzzles, often involving the efforts of tens or hundreds of people. Puzzles seem to max out at around four people or so, and even then there are delays where one person is waiting for the box or to get access to an area of the puzzle. And software systems are built to work on problems that affect people’s lives, as opposed to being an amusing hobby.
Also, with a puzzle there is a known end state; the picture on the box is what you’re aiming for, and you can constantly checkpoint against that; unless of course, you’re working on one of these. An essential difficulty of software is that the end state isn’t typically known with anything like that level of precision. In fact, in most systems I’ve built, the end state changes as the team builds and learns more about capabilities. Check that, I remember one time we had a prototype mobile app in Cordova and we were able to rebuild it using native libraries. Of course, that got outsourced, so maybe it’s better that the end state changes.
Another difference is that with puzzles I always start with the easy stuff. The corners and edges of a puzzle are usually the first major components that are done. With software, that’s a recipe for disaster. I always work on the hard parts as soon as possible, preferably first, because doing so decreases the risk of a failure. There are always more and less risky sections of any project and my advice is to tackle the areas of least certainty and highest risk as soon as possible. It’s scary, but if you wait, it’ll only get scarier.
Sincerely,
Dan
Letters To A New Developer 