One of the most influential teachers I’ve had was my university music professor. One piece of wisdom particularly resonates with me: he asked, “How good would you be if you did everything your teacher told you to do?” His point was not that you should unquestioningly do what you’re told. Rather, he meant that after we’re familiar enough with a discipline, we know what yields improvement at it. We know what habits, procedures, and mindsets will make us better at what we do.
Of course, he wouldn’t have made this remark if we did consistently do what we knew we should. But why? There are many possible reasons, but I believe the most common is simply laziness.
Addressing all those fundamentals is hard work and not as fun as doing the flashy stuff. If you were building a skyscraper, would you prefer to cement the foundation or construct the penthouse level? We don’t appreciate that sturdy base unless we discover, often catastrophically, that it’s faulty.
Inspection Time
In that spirit, I wanted to be a responsible engineer and examine our foundation. The following observations were compiled with software engineering in mind, as I identified them while working in that discipline. However, these practices apply universally. For each one, I have an example of when it proved the decisive factor for success.
Check every assumption. It is alarmingly easy to assume a “truth” on faith when, in reality, it is open to debate. Effective problem-solving starts by examining assumptions because the assumptions that survive your scrutiny will dictate which approaches remain viable. If you didn’t know your intended plan rested on an unfounded or invalid assumption, imagine how disastrously it would be to proceed anyway. Why take that gamble?
Recently, I worked on a project that involved aligning software deployment to an industry best practice. However, to meet specialized requirements, the project’s leadership relied on unique definitions of common terms, deviating ever so slightly from the standard industry definitions. If I had assumed the typical industry definitions, I would have missed some requirements.
Look up every term you don’t understand. When encountering an unfamiliar term, it’s easy to expect that we can intuit it from context or that it’s marginal enough in context that we can get the gist without it. Even if that’s true, how do you know until you check? How do you know you wouldn’t understand the topic on a much deeper level if you took five minutes to look it up?
When I initially embarked on my crash course in computer science, I didn’t read very deeply into object-oriented programming. “Yeah, yeah,” I thought, “everything is an object.” But once I took the time to explore the details, I learned what traits define object-oriented programming and how those traits, in turn, dictate how it can be applied. From there, I had enough background to start considering what problems an object-oriented approach is good and bad at solving.
Check the credibility of all your sources. I’m not telling you to only read the documentation (although it’s wise to start there), but you shouldn’t ascribe credibility to a source until you’ve checked it against information you already know is credible — like the documentation. I’ve written more than one piece about the difference between the commonly accepted way and the correct way. My recent article on Linux DNS configuration is a good example.
I constantly encounter wide gulfs between what the documentation advises and what developers on forums confidently assert. For instance, I had to generate RFC 4122-compliant UUIDs. In the particular language I was using, many developers recommended using a 3rd-party library. However, after careful research, I determined that the language’s built-in cryptographic library could already generate UUIDs. By omitting the third-party package, I reduced the number of dependencies as well as the attack surface for the application I was creating.
Take notes, then take some more notes. In the last year or so, I have made a point to capture the stray ideas, whether internalized or synthesized, instead of letting them dissipate. Since then, I’ve observed that I’m more productive and absorb more information even if I don’t reread my notes. The value of copious notes is intuitive: it takes much less time to write down too much and scan through everything than to write down too little and return to your sources to relocate what you omitted. With digital notes, it makes even more sense to record everything you read. A Ctrl-F search of even the most massive note file is far faster than retracing your investigation.
While researching how to configure and test some applications, I took notes on the criteria I used to select configurations. I noted everything on a private documentation page, even creating a flowchart to illustrate all my considerations. At the time, the page was only for checking and reinforcing my understanding. But once I realized that other developers would benefit from following in my footsteps, I already had a page ready.
Test everything you design or build. It is astounding how often testing gets skipped. A recent study showed that just under half of the time, information security professionals don’t audit major updates to their applications. It’s tempting to look at your application on paper and reason that it should be fine. But if everything worked like it did on paper, testing would never find any issues — yet so often it does. The whole point of testing is to discover what you didn’t anticipate. Because no one can foresee everything, the only way to catch what you didn’t is to test.
One time, I was writing a program to check a response payload that arbitrarily contained nested data structures of various types. While there is one overwhelmingly common data structure for the top level of such payloads, i.e., the payload root, I wrote the program to handle a variety of top-level data structures. However, I only added this flexibility after testing a wide range of payloads during development. Had I not tested with uncommon or unexpected inputs, the program could have encountered edge cases that induced a failure.
Basics Aren’t Everything, Just Everything That Everything Depends On
Why do I fixate on basics like this? I can think of two reasons.
First, I’ve seen the results for myself. Putting each of the above into consistent practice has improved the quality of my work, allowing me to tackle more complex problems. The work I’m doing now would be impossible without solidity on these basics.
Second, companies continue to squeeze out more productivity from their workforce by adopting the cutting-edge technology of the day, generative AI being merely the latest iteration of this trend. Don’t mistake the means for the ends: Companies don’t intrinsically want generative AI or any particular tool; they want increased productivity.
It’s too soon to say if generative AI will yield the quantum leap that so many seem to think it will. Before embracing a new paradigm, why not fully leverage an existing one? It’s way more efficient to improve on basics than add a new and specialized factor that may not remain relevant to the equation.
Regardless of your discipline, more of what you do on a regular basis draws on basic skills than highly advanced ones. This is the Pareto Principle (more commonly known as the “80/20 Rule”) in action: 20% of your skills toolkit accomplishes 80% of your work.
My current teacher likes to say that “mastery is just really refined basics.” Don’t overlook the road to mastery because of how unassuming it appears.
Loading ...
