On my journey to becoming a masterful software engineer, I regularly find myself pulled in multiple directions simultaneously. For me, the issues seem to break down like this:
- The reality of unproductive distractions in the internet era.
- Need it or not? What can I skip and still achieve mastery?
- If I need it, where to begin and how far to dig?
The reality of unproductive distractions in the internet era.
A fact of life. We each find our own way on this one.
Need it or not? What can I skip and still achieve mastery?
This is an easy one to answer –but! not until you’ve amassed the requisite experience. For newcomers to any field or activity, it’s actually quite difficult to answer this question meaningfully. Maybe even impossible.
In researching potential approaches to solve a given problem, subtleties of both the problem and the potential solutions reveal themselves – leading to an ever deeper investigation to understand how the layers of each are likely to interact. For problems/solutions of any complexity, looking into that crystal ball can be dizzyingly confusing.
So, while recognizing the tremendous value of the perfect tool, it’s also important to acknowledge the hazards of code bloat and unnecessary complexity. Leading me to frequently default to the approach I used in math & physics: When in doubt, derive things from first principles.
I think of the software equivalent as: Use the smallest, most fundamental (i.e., most dependency-free) pieces possible to build a solution. Yes, this is practically guaranteed to take longer than just applying a formula (or, in the case of software, deploying a tool), but starting from scratch gives me an opportunity to reinforce understanding and, hopefully, avoid unforeseen constraints and biases introduced by a generic formula/tool.
A note on strategy, optimization, perfection.
It’s pretty easy to over-strategize. See Eric Eliot on the propensity of programmers to make things more complicated than need be. Make it work, make it right, make it fast. Take care not to take that too literally, though…
There are reasonable refutations of the misuse of the all too well known Donald Knuth quote:
We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%.*
…the misuse of which arises largely from lack of attention to the final sentence. The part of Josh Barczak’s refutation which struck home:
As a citizen of planet Earth, I am tired of all the electricity that gets wasted by organizations who throw hardware at software problems, when a more efficient implementation might allow them to consume much, much less, and spend less money powering it all.*
We need to stop wasting our customers’ resources. We need to build a developer culture in which efficiency loss is not tolerated unless it is done consciously, to satisfy a functional requirement, or achieve some tangible benefit beyond mere expediency. This is not merely a matter of taste or opinion, it is a matter of professional ethics.*
I respect the conscientiousness of this perspective – it’s hard to argue that needless waste is good.
If I need it, where to begin and how far to dig?
Perspective is everything. Currently, my context is framed both by what will be useful to me long term, and what will be useful in the immediate future in joining a new team. I’m free to dig as necessary to satisfy my goals, and stop at my discretion.
Part of what’s special about the software engineering community generally is that there are many opinions on how to do things, and they – for the most part – coexist peacefully. You’re free to pick and choose your sides with abandon, and there’s not even a need to be consistent. Do what’s right according to the circumstances. What I love about this is that developers are thereby afforded the freedom to truly create, innovate, and explore as they see fit. Whether one is an explorer and digs as deep as possible, or whether one is a doer and digs only as deep as necessary, it’s all good. As a newcomer to this space, I’ve been the beneficiary of the fruits of both approaches, and am sincerely grateful. For all of it.
This is cross-posted on Medium.
Top comments (1)
Hmmm, that's what I don't have, a group.
Interesting reading.
As a beginner I often go to ask questions and like you've experienced trying to help people get into coding, is that "what is the magic bullet" or in my case "the right question" to get the as said, "knowledge". Seem there is no easy way. In saying that I like the idea of being part of a group.