Cultivate the Skill of Undivided Attention, or 'Deep Work' (Crosspost from `letterstoanewdeveloper.com`)
Article Table of Contents
Dan Moore is always welcoming to guest authors; he accepted something I wrote: Cultivate the Skill of Undivided Attention, or “Deep Work” (Letters to a New Developer). It ended up on Hacker News with 100 comments. I wrote this back in December 2019, forgot to post here until now.
Dan published a book by the title Letters to a New Developer. This letter is in it, but don’t let that disuade you. The book is full of great insights from developers of all experience levels.
Dear New Developer,
You know that there’s a chasm between your skill level and that of the mythical “senior software developer”.
If you build a list of topics you encounter on your job that, if learned to a deep enough level, would put you on the same level as a senior developer, you’ll end up even more demoralized than before compiling that list.
No need to assemble this list yourself! I’ve done it for you.
Here’s the list of topics that I’d need to dedicate significant time to, in order to close the gap between me and the senior developers on our team, that I’ve encountered in my last two days of work:
- Breaking complex unknowns into simpler unknowns that can be further split into individual tickets
- Adding tests to complex, legacy code, to guide further refactoring of said code.
- Using
grepto comb through server logs to diagnose a hard-to-identify-and-reproduce problem - Provisioning new servers
- Building bash scripts to automate complex workflows
- Digging into gem source code to can shed gem dependencies while maintaining certain features
- Understanding indexing well enough to see that certain queries that we thought were using indexes were not, and fix this oversight index on the fly, without causing any blips in availability
Each of these line-items has many books written about the topic.
It seems like you could fill a bookshelf with books that address knowledge senior developers have available to them inside their own heads.
It takes me long enough to work through a single book, so imagining a bookshelf of extra-curricular reading is quite daunting.
It might feel daunting for you, too.
Leading vs. lagging indicators #
The above list of skills is a lagging indicator of the underlying knowledge. We should not target improving lagging indicators, we should improve leading indicators.
Josh, what is this ‘lagging and leading indicator’ stuff?
Great question!
A lagging indicator is “evidence that something has already happened.”
If you got an A on a test, that is evidence that you learned the material.
A leading indicator is “evidence that something will likely happen”.
If you want to get an A on a test, you should study in a similar way as others who have gotten an A on that test. Maybe you need ten high-quality hours of study to get an A, so “number of high-quality study hours” would be a leading indicator of your grade.
We no longer take tests (phew. I hated taking tests.) but we get mini-tests of our knowledge, daily. We’re paid to solve problems, which often require learning new things.
Rather than focusing on a list of things other developers have learned, and targeting that list, I humbly propose that a leading indicator of acquiring this kind of knowledge is “hours per week spent in a state of intentional deep work”.
The above list of topics are lagging indicators of a high degree of technical knowledge. Someone acquires the knowledge, then, and only then, can demonstrate that they have it.
Leading indicators are “predictive”, in that if you can identify correctly those indicators, you can predict the outcome of the issue at hand.
In this case, the issue at hand is “become significantly more experienced in the domain of software development”.
I propose that a leading indicator of someone gaining these skills is the amount of time they spend in a state of deep work.
I’d encourage you to read Deep Work: Rules for Focused Success in a Distracted World. The author makes a case for deep work being a key role in the success of “knowledge workers” (which includes many types of work, including, of course, software development.)
If you’d rather not read the book, here’s the gist, from this summary of the book:
- In order to produce the absolute best stuff you’re capable of, you need to commit to deep work.
- The ability to quickly master hard things and the ability to produce at an elite level, in terms of both quality and speed, are two core abilities for thriving in today’s economy.
- “To learn hard things quickly, you must focus intensely without distraction.”
- “Your work is craft, and if you hone your ability and apply it with respect and care, then like the skilled wheelwright you can generate meaning in the daily efforts of your professional life.”
- “The key to developing a deep work habit is to move beyond good intentions and add routines and rituals to your working life designed to minimize the amount of your limited willpower necessary to transition into and maintain a state of unbroken concentration.”
- Imagine two equally knowledgeable early-career software developers. They have the exact same skills on January 1, 2020. If the first software developer spends four hours a week doing deep work, while the second software developer spends fifteen hours a week doing deep work, their trajectories will be quite different, and that second developer will quickly gain technical knowledge and proficiencies.
So, if you’re an early-career software developer, track the time you spend doing deep work. That has you focusing on a leading indicator of growing in your skills.
At that point, you’ll benefit from Peter Drucker’s assessment:
What is measured, improves.
You’ll track how many hours you spend doing deep work, and by tracking it, you’ll do more and more of it.
In conclusion #
Do more deep work, and over a year or two years, your skills will grow much faster than those doing less deep work. Eventually, you might find that you’re doing the work of a senior developer!
Good luck!
-Josh