For many activities, we can intuitively imagine what practice looks like even if we’ve never participated in it. To practice basketball, we go through shooting and ball handling drills. To practice violin, we repeat scales and etudes. Although we might be hazy on the exact drills, generally, we know what to do. So why is it that when it comes to software engineering, (and most other professions for that matter), I, at least, find it hard to imagine what practice is? What does it mean to practice programming?
At the heart of any kind of practice is repetitive activity with feedback. Repetitive activity is what cements knowledge into skill while feedback ensures that the skills we’re cementing are “good” skills. Both are necessary. Repetitive activity without feedback is why some people have illegible handwriting even after decades of writing. And feedback without repetitive activity is just knowledge.[1] This means that to practice programming, you must not only continually code but you must also constantly get feedback either from others or from yourself.
In software, getting feedback from others often involves opening pull requests and having teammates review your code. But it can also mean pair programming, getting reviews on initial drafts of design docs, or asking a recent hire how easy it was to navigate through a particular section of code you wrote. Similarly, you can give yourself feedback by reflecting on past pull requests you merged or past technical decisions you made. Was it easy to extend or delete the code? Has it been reliable? Can you yourself easily re-understand the code?
As you may have noticed, none of this is new. We code and get feedback almost everyday. We just don’t think of it as practice, but it is because at the end of the day, we’re applying our skills and getting feedback in the process. The problem, though, is that we often get confusing or inconsistent feedback. This isn’t to say that most of our peers’ comments are confusing. Rather, most comments do make sense, but they make sense in that particular context and moment. Feedback becomes inconsistent and confusing when someone else says the opposite in a different pull request, when all the comments are questions and you aren’t sure what to do with them, and when you make the same “mistake” next time and no one comments on it.
To make matters worse, all of these things happen for legitimate reasons. For example, different people have different ideas on good engineering so naturally each person’s comments will differ. The business demands that reviewers pay most attention to the output and not feedback consistency. And there are almost never right or wrong answers in engineering, only trade-offs. This last point is particularly interesting because it explains why practicing sports is much easier to imagine: until you get to a very high level, feedback in a sport is about an objective outcome that happens nearly instantaneously. Did you get the ball in the basket or not? Did the tennis ball land in the court or not? Meanwhile, very little of engineering, is about whether the code runs correctly or not.[2]
All of these reasons are why good practice is so hard and why the number of hours spent coding doesn’t necessarily equate to skill level. We get the reps in, but we don’t always get the kind of feedback that leads us to become better.
Fortunately, though, there are places where good practice happens. In my experience, good practice tends to happen with individuals who reflect back on their past work and in places where there are strong senior engineers and mentors. In the former, reflection helps you course correct by judging past work against your own principles. And in the latter, senior engineers already have an opinion on what makes someone a good engineer so their feedback constantly points you in that direction. Of course, you might disagree with their opinion, but good practice is less about the destination itself and more about how efficiently you get to the destination.
Curiously enough, none of what I’ve written is inherent to engineering. These principles of practice apply to any profession whether it be teaching or an activity whose practice we are already familiar with (like basketball). The details may differ, but in the end, good practice is about repetitive activity with consistent feedback.
[1]: One critical distinction to make is that practice is different from learning. While practice cements skill, learning accumulates knowledge. This is why I don’t believe that reading blog posts or diving into open source projects is necessarily practice. It’s important in your development as an engineer and something I believe in doing, but it’s not practice.
[2]: This is why I hesitate to mention that going through interview questions is a form of practice. While it’s easy to repeatedly do, interview questions are typically about getting the right answer. As such, the feedback you get is very often one-dimensional. You judge yourself on if the program runs correctly, but good engineering is so much more than that.