Deliberate practice techniques for software developers
“The relationship between deep work and collaboration is tricky,” writes Cal Newport in his recent book on focused productivity. That’s for sure. The goal of deep work is to expand your cognitive abilities in a distraction-free working environment. But many people don’t work alone. And as anyone who has worked on a team can attest, co-workers can be a source of distraction. How can we reconcile deep work goals with the need for collaboration?
To find a job you love, you can start by considering your career values, what specific job is compatible with those values, and what skills you need to do well at that job.
If you already have the job you want, you still need to decide what you want to work on. The job description that you might have perused before applying for the job could tell you something. For a programming job, that might include technologies you’ll be using, background you should have, and a general idea of the product you’ll be working on. But within those general boundaries, you have some control over your daily work. That allows you to customize a general job description to fit exactly what you want to do.
Over the past couple of weeks, I have been writing about software careers, including career values and characteristics of a good programming job. This week: types of skills used in a programming job.
Last week, I wrote about how to use career values to evaluate a programming job. This week, I’m going to follow up with some characteristics of a programming job you might find using a values-oriented approach.
In a 2005 interview, computer scientist Guy Steele Jr. recounts this story about applying for a programming job at MIT in the early 1970s:
I was naïve enough to go over there on the Fourth of July and put my head in Bill Martin‘s door and said, “I hear you’re looking for LISP programmers.” I wasn’t 18 yet. Bill looked at me seriously and said, “You’ll have to take my LISP quiz.” He reached in a file drawer and pulled out a three- or four-page quiz and sat me down in his office, and I spent an hour or two doing this quiz. He graded it and said, “You’re the first person who has ever gotten it 100 percent right. You’re hired.”
That’s a fun anecdote about a young computer whiz. It’s also an early example of the type of interview now familiar to every software developer. But what I wanted to know after hearing this story was the same thing that piqued the interviewer’s curiosity: “How did you know that much about LISP?”
For many years, Cal Newport has been writing about ways to get better at doing difficult things. His first three books were manuals for students, advice on learning techniques and where to focus one’s efforts during high school and college. In 2012, he wrote So Good They Can’t Ignore You, about building career capital by mastering valuable skills. While he was writing these four books, he also published the Study Hacks blog, which covers similar topics on a weekly basis.
Cal’s latest book, published last week, is Deep Work: Rules for Focused Success in a Distracted World. This one offers the following challenge: to improve your ability to do what is difficult, you first have to spend less time doing what is easy.
It’s impossible to measure developer productivity. At least, that’s what the experts say. Martin Fowler came to that conclusion over 10 years ago in a classic article, and the consensus hasn’t changed since then. My favorite recent article on the subject is by Jim Bird, a development manager and CTO.
So let’s take that as a given: Measuring developer productivity reliably and objectively is a hard problem, maybe an impossible one. But rather than rehash the standard arguments, I’m going to change the rules a bit.
In an earlier post, I mentioned a pilot course I took a couple of years ago on applying deliberate practice to various types of jobs. Well that original pilot, and a subsequent pilot in 2014, has resulted in a course called Top Performer (not an affiliate link). As part of the homework for the second pilot, I came up with the idea for Project 462 and this blog. So as people are considering the course this week, I thought I would add my thoughts to the mix.
In 2013, I took an experimental course on deliberate practice that Cal Newport and Scott Young were developing. In the email announcing the course, Cal warned: “If … you’re expecting guaranteed results, this pilot might not be a good fit.”
It’s a standard marketing technique for products and services to promise guaranteed results. But that’s not really what they’re promising. They may be willing to refund your money if you’re not satisfied, or even throw in a gift card. But that’s not really what you want. You want those results you were promised. Rather than relying on a guarantee that is limited to the purchase price, what if you could make your own guarantee?
It’s summertime here in the Pacific Northwest, and seven months into the first year of this blog. After thirty weekly posts, I thought it would be a good time to consider the themes that have come up so far this year. If you’re a new reader, I hope you’ll find this to be a useful primer.