Guidelines to pragmatic engineering
While pursuing my B.S. in computer engineering, the subjects I’ve learned so far have been the fundamental sciences like math and physics — the principles by which things that are engineered function and behave. In turn, I’ve also learned to think like an engineer and ask myself: “What sort of tool should I use to solve this problem? How can I accomplish my goal more efficiently?”
This is an important mentality that I might’ve never adopted otherwise, but I now understand in my graduating year that engineering is far more about hands-on experience and working knowledge than my conceptual classes have led me to believe. In fact, this is supposed to be what distinguishes the subject from the other sciences. Engineering deserves to be treated more as its own field, and less an amalgamation of the scientific theories it follows. Here I discuss some of my key takeaways derived from engineering classes but more or less discovered independently.
First, I want to emphasize that unlike other highly-technical fields, there is practically no barrier to entry should you want to be an engineer (aside from Canada, where the title is apparently protected by law). If you create any robust system that you’ve at least attempted to optimize to fit some criteria, it’s not unreasonable to say you’ve engineered something. In this regard, an engineer more closely resembles an artist than a mathematician.
On a similar note, there’s little reason to worry about “cheating” when it comes to adding intermediary black boxes like open-source software or off-the-shelf components to a project you’re building. What really matters are results in engineering, and the best results are achieved by using the right tools for the task. Even professional chefs use microwaves (or as they call him, “Chef Mike”) for certain tasks.
It’s the role of a scientist, not engineer, to understand every minute detail of a particular process in their work. Of course, a good engineer can explain what they’ve built and how they did so, especially in a professional setting. But this is a belabored point at my university, when most students would benefit from learning the tools of the trade and building something unique in the first place.
I’ve encountered two fundamental concepts that are ubiquitous in all branches of engineering — architecture and abstraction. When laypeople remark how impossibly complex something is, these are often the overlooked aspects responsible for their amazement. In the most general definition of the term, architecture depicts how components, divided into imaginary hierarchical sections called abstraction layers, interact with each other. Each abstraction layer is characterized by certain rules and are consequently designed via a set of specialized tools, typically familiar to only a handful of designated roles.
Architecture and abstraction serve to break down a complicated system into increasingly finer (not necessarily simpler) chunks, which can then be summed to describe the operation of the whole. The most prominent example of architecture and abstraction is the modern computer. I’ll spare the banal analogies of how fast and efficient computers are — when you turn on a flashlight, you don’t comment on how mind-bogglingly fast the speed of light is every time. What’s more interesting to me is the interconnectivity between the dozens of distinct layers working synchronously to enable such speeds.
From signal propagation in copper traces described by electromagnetic theory to transistors forming fundamental logic gates like NAND and NOR, and from the ISA standardizing interaction between software and hardware to the OS that bridges the gap, these many layers are intrinsic to the overall functionality of the computer we’ve come to rely on.
Abstraction layers can be utilized to understand all kinds of infrastructure: urban planning, communication networks, and any conceivable piece of software. These principles are central to development and analysis in fields outside of engineering as well — any field seeking efficiency will naturally adopt aspects of engineering design.
Without discrediting the brilliance of all individuals who have contributed to the development of the computer, modern innovations we take for granted are never truly as “magical” as some make them out to be because of the near-limitless descriptive power of architecture and abstraction. Keeping these concepts in mind helps me ground myself in a world where everything is overwhelmingly complex.
I interpret the Pareto Principle, the idea that 80% of an effect can be attributed to 20% of input conditions, as a universal rule of thumb that impels you to hit the ground running when starting something new. It describes a generalization that, while not always statistically accurate, will help orient your efforts to make the greatest net positive impact.
When looking to achieve a goal, there’s a perceived balancing act between taking the “proper”, more sophisticated route and reaching your objective in a timely manner. Beginners especially tend to misjudge this tradeoff, opting to make things difficult for themselves in fear of making mistakes or learning the wrong way. This can materialize as immediately purchasing the most expensive equipment (what I like to call “rushing town hall”), excessive research, and an overall lack of progress.
Getting caught up in this trap is known as bikeshedding; for example, I often witness students spending far more time moving around notes and shapes on their iPads than listening to the professor in predominantly oral lectures. Most of an envisioned outcome will always be beholden to purposeful action towards that end — equipment and planning are responsible for disproportionately less.
The 80/20 rule is the overarching principle behind Silicon Valley’s favorite slogan: move fast and break things. If you know what needs to be done and a trusted, simple way of accomplishing it, that’s typically the best path forward. When I started learning how to cook, I had a habit of never exceeding medium-low heat on the stove — not because I had lots of experience burning my food, but because of my preconceived notion that burning food was a rookie mistake. Because of this, I’d have to spend an extra 5–10 minutes hovering by the stove for no good reason. This could have been avoided entirely had I taken a step back to assess my end goal and experiment more with my constraints.