Over the course of a few years of programming, I’ve noticed myself jump from one activity to another: making things work, to making things pretty.
After building a variety of applications in the software industry, I realized there’s a way to prioritize those activities. Here, I list them down:
At first, I initially thought that these goals were sequential because it made sense to me as a developer.
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 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.
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.
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?
As always, thank you for reading.