Categories
Dev Process

The three stages of developer growth

Today I happened across a great Quora post by Andreas Blixt. In the post, Andreas outlines the three stages of developer growth:

The novice hacker
“This code sure is ugly and I don’t quite understand why it works, but here it is!”
A developer in this phase finds creative solutions to problems, they just happen to be copy/pasted from all over the internet.
The problem is that the code breaks whenever it needs to be changed or it encounters a new situation

The philosophizing abstracter
“This code works for now, but if I move this part into a factory, and create an interface for these methods, it’ll also support all these future cases I can think of!”
They’ve read all the articles on how to structure code. There’s a lot of patterns out there for object-oriented (or functional!) code. Their code has all sorts of useful interfaces, abstraction layers, factories, extension methods, data structures.
Things break down when the project needs to move in an unexpected direction and it turns out that implementing the change requires changing a lot of the codebase because there were a bit too many abstractions that ended up creating hidden dependencies across the code.

The wise hacker
“Move fast. Break things. Revise and fix. Get shit done.”
Finally, developers balance the concepts of hacking and abstracting. They write code that simply solves the problem at hand, then they take a step back and look for repetition that can be simplified. They know from experience that things always change unexpectedly and that you can’t always foresee what will or will not be useful in the future.

Blixt, A. (2015, October 22). What are the growth stages of a programmer? Retrieved March 20, 2019, from https://www.quora.com/What-are-the-growth-stages-of-a-programmer/answer/Andreas-Blixt

As someone basically just starting out, I find this perspective from a senior developer very reassuring. I can absolutely see this path before me. Already I find myself writing code to get things working, then revisiting the code to see how I can improve it.

I’m yet to have the knowledge to do a great job on the improvements, but I feel that is my workflow. Having these stages outlined actually impacts my pathway through them. As I develop more skills I’ll be mindful of when and where I should deploy them.