Over the course of a few years of programming, I’ve noticed myself grow incrementally, from simply trying to make things work, to learning to do better and make things pretty. After building a variety of applications in the software industry, I realized there’s a common pattern in what an individual should prioritize when learning about a new skill.
This blog post enumerates the different phases or mindsets of learning. I had these when I was growing as a software developer, but it can be generalized for use in learning any new skill or venture.
It all begins by simply making things work (i.e. Do a Shitty Job).
Make things work
As a young developer, I initially studied to make things work (following how-tos and tutorials online, copy-pasting code to see things work). Once I get it running on my machine, then I study the language, tweak parameters, and see how I can change something as simple as a square at X position 50, to a circle at X position 100. Very simple things.
Once I learn the language better, I find myself exploring how to make sure that the code that I write not only appears to work- but is also correct. That’s a big distinction especially for younger developers, who struggle to see the in-between step of making things work before making sure they’re correct.
Run the code, see what happens, hypothesize why it is broken, experiment, and repeat.
This incremental approach is not always effective, but it’s a good place to start especially for someone who is overwhelmed by feelings of “I don’t know how to do this or that”. This is flipped by instead practicing in a safe “sandboxed” area where you can try the code, see what happens, and wield it. Tweak it. Make it your own, until it is no longer something you copied, and instead something that you could have written yourself.
Make things correct
As we reach the first steep mountain of making things work, we realize that our initial code doesn’t actually work all the time. There were edge cases we didn’t factor in, and so the code must be fixed. Then we realize that we didn’t actually understand the problem well enough the first time. There were implicit assumptions we accepted, and went ahead rather than ask important questions that would have saved us time.
A big portion of making things correct is first making sure that you understand the problem deeply, because it is difficult to find an optimally correct solution for a problem which is not well defined. This is all the more true for a problem that you had not spent enough time on to understand more deeply.
Make it usable
Once we plateau at the skill level of software development where we are confident that we can make things correct, we find the next goal of pushing our craftsmanship in achieving optimizations and usability improvements.
What good would a functional application be (gives correct results), if the users struggle to learn how to use it, or if the data processing takes minutes or hours to complete? It makes sense then, that usability and optimizations come next.
At this point in your software development career, you’d find yourself maxing out your individual potential contributor output. I highly recommend you check out Sarah Drasner’s book: Engineering Management For the Rest of Us. I really like her book because she begins with understanding ones’ values, which is similar to how I recommend people figuring out their direction in life.
A lot of engineering leaders worked to be best engineer they could be… and then we were promoted. It’s tough to transition roles. I wrote the book I wish I had when I started leading teams.
Sarah Drasner, on Twitter
Make it pretty
Aesthetics is not something to be undervalued but I perceive it to be something to be pursued only after more important items were met. I studied myself on how I actually weighed which of these factors were important, and what I think would have been important to me, had I been a client requesting for a software to be built.
In my opinion, functionality (working and correct) comes first, followed by usability (optimizations), and lastly, aesthetics.
I would rather have something look ugly but get the job done rather than have an application that is very pretty but not useful or functional.
Later on, I realize that these activities were taking form based on what I perceive to be business value. There are outlier cases where the general guidelines I provided above will be invalid. For example, sometimes aesthetics is more important than functionality such as in the case of having a pretty marketing tool even if you still don’t have the full product yet.
Software Developer Apprenticeship
Where do you find yourself in this simplified model/spectrum of mastery in software development?
If you want to study along with others who are in an apprenticeship or are journeying to different places, feel free to send me a tweet or DM, or just say hi! I have a group of friends who are part of a Discord community of diligent and generous learners.
As always, thank you for reading.