Strong Basics: The Building Blocks of Software Engineering
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.