When I wrote Your job is to produce value, I got a few responses that could be summed up as something along the lines of:
Telling developers to get better at reading and writing and problem solving is sort of like telling them to get better at writing fewer bugs: it might be true, but it's anodyne and unactionable.
First off: this is not true, and if you think this way (that, say, communication is some sort of inherent skill and not a thing that improves with practice and study) you should probably try to carve out daily rituals of blogging, reading, and UX research.
But! I am sympathetic to the argument that there are more decisions and options an engineer has to make in their career than simply being customer-, finance-, and experience-focused. Knowledge accretes, and while a certain radical generalism — no stacks, no sectors — is probably the best overall meta for a young engineer the reality is that you will have to make choices about which companies/organizations/teams/languages to spend time on, and those choices have marginal consequences: all other things equal, someone who joined a web3 startup in 2020 or an Angular shop in 2018 probably has marginally worse prospects than someone who got into GIS work or Swift right as they were taking off.
(I use the word "marginal" there intentionally: the industry or technical stack you land in is far less important to your career than anything else.)
This belies the question: assuming that you don't have oracular vision, what kind of opportunities (at the company level, at the project level) are the right ones to pursue?
I have two answers that I think overlap a good deal:
- Haunted forests. In the linked essay, John talks about this metaphor within the context of SRE, but I think its true at a broader, more conceptual level: the prize for tackling domains and codebases that terrify others is knowledge, esteem, and many battle scars.
- Lindy tech. In the grand catalog of infrastructure required to run the modern world, the most powerful and most useful — DNS, SMTP, relational databases — tend to be old.
I say these two things overlap because folks often use the terminology of the former to describe the latter. "Don't roll your own auth"; "DNS is an eldritch horror"; "never try and send your own emails"; it's tempting to buy into these truisms, but the twelve months you spend really understanding how DNS works at a primordial level is going to have more long-term value than the twelve months you spend on GraphQL or whatever.
(All of this is true at an organizational level, too. Institutional knowledge decays over many axes; one way to stave off the inexorable decline is to invest in meaningful, durable substrates.)
