Deliberate practice techniques for software developers
When I’m solving competitive programming problems for practice, I follow a specific series of steps to help me get the most out of the process. My current process ends with submitting an accepted solution and recording my stop time (for measurement purposes). But there really should be another step: find someone else’s solution and compare it with mine.
A few weeks ago, K. Anders Ericsson of deliberate practice fame released a new book (which I haven’t yet read) called Peak: Secrets from the New Science of Expertise. The main challenge with reading these types of popular science/psychology books is taking action. They are written to be enjoyed, but there’s nothing forcing you to make any life changes once you finish the last page.
One way to avoid the passive reader trap is to maintain an idea list. Advice books are packed with words and stories, but are usually built around a few core ideas. Many of these ideas come up repeatedly in different books and articles. So as you come across them in your reading, maintain a master list of ideas that seem useful. The purpose of this list is to serve as a reminder of practices that you find effective. Try them out one at a time, and adjust as necessary to fit your work style.
Items on this list should be more actionable than guiding philosophies like “You don’t have to live your life the way others expect.” But they shouldn’t be too specific, or your list will get unwieldy. This isn’t the place for tiny life hacks about secret Gmail features. The goal is to make a list that will remind you to follow principles that you have found to be effective.
With that in mind, here’s my list:
When you’re solving competitive programming problems, it’s tempting to code as fast as possible. Once you have some idea about what the problem is asking for, just start coding and hack away until your solution passes. After all, these problems are written for timed contests, so why not solve them as if you’re racing the clock?
At some point in your competitive programming career, the “full speed ahead” approach might be the right one. If you want to do well in contests, you have to practice under contest-like conditions. But it may be a while before that’s the optimal practice strategy.
The problem with coding quickly is that you’ll end up with messy code that’s hard to debug. There’s nothing morally wrong with writing messy code that you’re going to throw away in an hour. If you’re getting correct solutions quickly, go for it. But if you’re spending a lot of time debugging code that’s incomprehensible a minute after you write it, maybe it would be more efficient to slow down.
Now, I’m not saying you should go to the other extreme and polish your code as if you were going to turn it into a product. Even if you have a lot of practice time, there’s a limit to how much learning benefit you can get out of one contest problem. Save your best coding style for code that you’re going to keep around.
[T]here are two things traditionally taught in universities as a part of a computer science curriculum which many people just never really fully comprehend: pointers and recursion. — Joel Spolsky
Let’s try to comprehend the basics of recursion using an example that comes up frequently in programming puzzles: generating all permutations of a set.
Software developers spend a lot of time in front of computers, obviously. It’s also a modern truism that a networked computer is both a productivity enhancer and the greatest time waster humanity has ever invented. The same devices that we use to make a living are also perfect for delivering endless cat videos.
But we can’t just stop using our computer and go back to the abacus. Even turning off the network is problematic, now that Stack Overflow is the de facto source of documentation for anything useful. (Turning off email while you work is recommended though).
So what’s the solution? One thing about computers, especially those that run desktop operating systems, is that they’re designed to be customized. So let’s try to solve a problem that technology has created (Internet distraction) by applying a technological solution: a time tracking app, customized for self-tracking 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?”