How to Understand Something Deeply (My 4 Favorite Techniques)
Not-so-well-known but bullet-proof.
In a nutshell
In my previous post, "Why I Hire for Depth (as a VP of Engineering)", I discussed why the ability to understand things in-depth is critical for a developer.
Today, I'll share 4 powerful techniques for deeply understanding any topic.
Nothing can replace working with an experienced team on real-life, long-term, complex projects.
However, even this kind of experience doesn't automatically result in deep understanding if you aren't intentionally seeking to deepen it.
So how do you pursue depth?
Here are my 4 favorite techniques:
1. Explore the boundaries
Push good practices to the extreme.
If functions with fewer parameters are considered good, how would your code look if no function had more than one parameter? How would it look like if no function had any parameters at all? Would it even be doable? What workarounds would you have to implement to make this possible?
The most interesting things — and the most learning — happen at the edge cases. To fully understand how and why something works, you must understand when it doesn't work anymore.
Consider also the opposites. Can you think of any edge case (even if a bit unrealistic or crazy) where a function with a long list of parameters would work better? Why would it?
No principle is universal. No principle always works. Stretching it, stress-testing it, discovering its limitations is the only way to understand it in-depth.
This can be done in two ways: through mental or practical experiments.
You can just imagine or discuss with your teammates how your code would look if all the functions had zero parameters.
Or you can challenge yourself to write only zero-parameter functions for the next week and see what happens. Code is extremely malleable, so such experiments carry no risk — you can always easily roll it back.
2. Search for criticism
For every "best practice", there will be naysayers and critics.
Some will feel close to the truth but slightly off. Some will feel almost blasphemous.
Embrace both groups.
For the "slightly off" ones, consider why they see things this way. What nuance do they miss? Can they see something that you don't? How is their context different from yours? Could they be correct in their context?
For the "blasphemous" ones, consider why they see the world so differently. What may be their underlying assumptions? What are yours? What experiences could lead them to such a wildly different perspective?
Finding naysayers is easy. Just Google phrases like "Why I no longer use X", "Why X is dead", "Why I hate X", and similar. Or post a provocative comment on social media and check the replies.
You can also play the devil's advocate yourself. Wear a contrarian (or even extremist) hat for a little while. Ask "What if?". Play the critic. You'll be surprised how much deeper and more nuanced your point of view will become.
3. Understand the original context
No "best practice" is born in a vacuum.
It always stems from a solution to its creator's pain point or emerges as a common pattern observed in its creator's environment.
You will never understand the practice in-depth if you don't understand when, why, and in what circumstances it was created.
And this information gets obscured over time. If a practice is popular, it will be synthesized, summarized, cloned, and adapted — and also misinterpreted and distorted — to the point where decrypting the original context becomes impossible.
But it's not that hard to find the practice's creator and the publication where it was first introduced.
Read it for the original context. Then, consider how the industry has changed since then, what's the current state of the art that wasn't available at that time, and how your particular context and pain points compare to those of the practice's creator.
Compare it also with the most up-to-date publications on the topic, especially "official" ones (if the practice is still backed by the original creator or some organization). Is it preserved intact or has it evolved? How? Why do you think it has evolved this way? What turned out to be evergreen and what had to be changed to keep up with the industry?
This will not only help you understand the practice in and out but also anticipate how well it will fit your case and how easy it is to tweak.
4. Consider how something will scale
Technologies, methodologies, and best practices often have a sweet spot regarding scale.
And I mean scale in a broad sense, not only the number of requests: more developers and teams, bigger codebase, more complex architecture, more features, more customers, more markets.
For example, will a particular deployment pipeline work equally well for a monolithic project and multiple microservices? A single Git repository, multiple repositories, and a monorepo with multiple projects? One team deploying a few times per week, and 20 teams deploying several times per day? A single geographical cloud region and multiple?
Or will a methodology like Scrum work equally well for a single person, single team, multiple teams working on a single product, and multiple teams working on a portfolio of products with many stakeholders and types of customers?
How easy will it be to adapt or replace a given technology or practice to accommodate various aspects of the product and company scaling up?
Considering questions like these will greatly deepen your knowledge and help you make more future-proof decisions.
Bottom line
Applied regularly, these 4 techniques will let you understand any topic in and out — and shine in your next interview. Plus, you'll become a much better developer.
To make it clear: I don't want you to become a software engineering philosopher, spending days and weeks contemplating the subtlest nuances. Be pragmatic. Be practical. But also don't shy from diving deep.
It doesn't take much. A quick mental experiment. An occasional discussion with your teammates. Paying more attention to critics. More deliberately choosing which books to read. You'll be surprised how much depth you'll gain — and how quickly.