Humility
In my job as a software developer, there are MANY things that, contrary to popular belief, are absolute necessities. Software documentation is one of those things. A developer’s value is not entirely based on code output; it actually largely depends on the phase of a project. During design and prototyping, a developer with good tooling knowledge who can also code quickly is more valuable than one who can write good documentation and kick-ass tests. It’s not that documentation and testing are not important in general; it’s just that they are not really the focus of this particular phase.On the flip side, in a project that is largely in O&M, a developer who can easily regression-test legacy systems and keep the plethora of documentation updated is worth their weight in gold.
Of course, because of “all the new things”—like hearing stories of rapidly developing startups using AI, robotics, quantum computing, etc.—we tend to mentally associate the pathological coder as the one with the highest merit. But if you can write really good code that does not adhere to requirements, is not testable, or is not documented, it loses value outside of prototyping phases.
Ok—enough software talk (for now).
There is something to be said about the forgotten aspects of our work. They are not forgotten because they are less important but because people are hyper-focused on other things. Ironically, this is the reason their importance heightens.
Some sports analogies: Defense wins championships, but a good defensive lineman’s highlight reels garner fewer views than that wide receiver who never seems to even make the playoffs. It’s called the trenches for a reason. It’s not pretty, but if you talk to a defensive coordinator, it’s where everything starts—it is the foundation of a good defense.
So if you’re now convinced that there is at least some merit to these undesirable parts of work, how can we learn to take pride in them? How can I be proud to be proficient at the things no one else seems to care about?
This might seem defeating at first because you are absolutely correct—no one is going to go out of their way to praise you for this work. Hell, it might go completely unnoticed for a period of time too. This boils down to a pretty simple philosophy in actuality:
Ask yourself: Am I good at what I do, and how do I truly feel about my answer to that question?
If you believe you are good at what you do, how often do you obsess over the details and the little things? By my own definition of “good,” I would consider things like tests and documentation just as important as code itself. Can you be an effective developer at all points of a project’s lifecycle? Are you only useful during certain phases? Are you OK with that?
What is preventing me from being the best at what I do? How can I close this gap as soon as possible?
This, of course, requires some amount of self-awareness and humility—the same kind of humility it takes to approach the most undesirable tasks with pride and find joy in the process of mastering them.
Speaking of, it has never been easier to master something in such a short amount of time, so don’t let silly excuses like “I don’t know how” stop you from performing at the level you consider acceptable for your own standards. If you are reading this, within seconds, you can be learning anything. You are only at most 2–3 weeks away from becoming extremely proficient in any topic of your choosing.
I will be writing more about this in the next blog post, but the access you have to information, research, and literature is profound and novel from a historical perspective—so take full advantage of it. Soak up every second of suffering through writing that unit test today, because the edge and humility it creates are exactly what will make you better tomorrow.