As engineers, part of our job is encountering technical challenges and power through them to a solution.
Challenges give rise to an appropriate solution, and then on to the next challenge. It happens often — and this is a good thing.
But after each challenge, are you taking the time after the solution to go back over what you’ve done to truly understand why that solution worked?
Stopping at a solution solves the current problem. Going further and digging deeper to understand why it works is how you gain mastery over your craft.
How often does this happen: you’re troubleshooting a bug, making a bunch of incremental changes, hoping to fix said bug. After hours of effort, you fix it.
What do you do next? Do you assume that the last thing you did resolved the issue, and move on to the next issue? Do you at least revert the last change to see if it did have an impact?
I’ve see this happen often; engineers erroneously attributing the solution to a series of inexplicable steps. Passed along to others, it becomes like an old wives tale without logical reasoning to substantiate the conclusion.
To truly understand the problem and the solution, you should start over and apply just changes you think that matter, test each incremental change to make sure the solution breaks without it. At the end, you should be able to explain why and what was fixed. Maybe it was just the last change you made, or maybe it was a combination of a couple of changes, but without understand why something worked, you a missed opportunity for deeper understanding.
True masters dig deep to figure out why something worked — and add it to their toolbelt.
Today we have great software frameworks like React, VueJS and Rails that gives engineers patterns to tackle common software tasks. Engineers can use these patterns to achieve some great results, but still lack the mastery of the “how” and “why”.
Engineers are brought up by learning the framework, which involves following specific patterns to create “Units” of work. Units have different names depending on the framework and frameworks can have more than one type of Unit. In React/VueJS the basic unit is a Component, and in Rails, an MVC framework, have Models, Views and Controllers as basic units. Frameworks allow engineers to stack many of these units to build software products.
And this would be great and all we needed if we were building the exact same software over and over again. But one of the interesting qualities of our profession is that while some elements of what we build are common, we are rarely building the exact same thing. Also, it’s the differences that matter most.
It’s these differences that, at some point, will lead you into a problem that the framework isn’t exactly designed for. This is where you’ll need to deviate from the framework to achieve your solution. If you’re just a framework practitioner that only understands problems based on how a they translates to units, then you’ll struggle.
If you’ve taken the time master your framework, then deviations are no big deal. You can use the deep understanding of the framework and develop a solution that works within the framework where it can, but not be limited by it.
It’s analogous to the difference between a line chef that follows instructions vs a master chef who can improvise based a deep understand of ingredients and techniques that complement and accentuate each other.
We appreciate the value of mastery because we understand the work it takes to get there. It involves taking on many challenges, each arriving to a solution, and then making sure to understand why that solution worked before moving on.
We’ve been there, and done that.
My business partner Randy once ran into memory allocation issues for a graphic-rich app he was building. As he dug deeper, he realized that rather than pulling from the allotted memory on the virtual machine, he could tap into the memory of the native OS.
Ultimately, even that didn’t work, but the process of digging deeper made him a master of memory management and served him well beyond that project.
We’ve all heard that to Master something takes a lot of time and effort, but it’s important that the effort is put in the right place. Repetition is a part of it, but pushing yourself to understanding why’s and how’s of it accelerates the process.
Start by focusing on a narrow slice of a technology and gain an expert level understanding of how it works, why it works, and why it doesn’t work in some cases. From there, it becomes easy to expand since most well built software are build on similar principals.
This will position you as a top engineer in your field.
This isn’t just about fixing bugs. When I work with engineers and suggest patterns, it’s more important that they understand why I’m making my feedback, rather than simply executing. My suggestions are influenced by my past experience and knowledge about the current software. To not ask why is to miss out on an opportunity to understand more about the software you’re working with or why this solution is better than others.
When people run into issues with new technologies, they write the tech off as junk. Sometimes it’s legitimate, but other times it’s be cause we look at it only from our perspective, and try to fit the technology into the box we’re comfortable with. Only when we dig deeper do we realize that we weren’t using it correctly.
These are always opportunities to learn more; mastery is on the other end of these learnings.
How hard we dig to understand the true nature of the issue… and what specifically fixed it AFTER solving it is what differentiates a practitioner from a master.
Solving a problem doesn’t gain mastery as much as understanding how you solved that problem.
