Applying the science of skill acquisition to working in the tech industry

This #ComputerScienceEducationWeek, I've been thinking about the current conditions for soon-to-enter and recently-entered engineers in the workforce. As a knowledge industry, CS education doesn't stop with graduation or getting your first job. In fact, I would argue that is where it truly begins in earnest. Our industry is growing exponentially, or seems that way. Not just in total market value or people in tech and related fields, but in the vast amount of things there are to learn.

Those new things – programming languages, frameworks, libraries, protocols, techniques, tools, services, and more – outpace the rate at which a human can learn. So let's first start by abolishing the notion that there will ever be a day when we can think "I finally know everything." What this means for us, practically, is that we have to know how to learn effectively, and do so continuously, so we are positioned to take on that next project and beyond.

In the last few months I stumbled upon this Veritasium video: The 4 things it takes to be an expert. The video ticked a lot of boxes for me, drawing on my formal education as well as life and career experiences.

My path to the tech industry was through hobby programming as a child, and then an undergraduate Cognitive Science program with a concentration in Computer Science rather than a traditional Engineering degree. This video references many things that I learned when studying the other pillars of Cognitive Science, particularly cognition and the study of skill acquisition. Let's go through the points of the video and relate them to our field, so we can examine techniques that may help supercharge your studies or your career.

I encourage you to watch the video before completing this article, but here is my summary of the 5 requirements outlined (despite the title):

1. 10,000 hours of practice
2. Repeated practice with feedback
3. Valid environment -- feedback reflecting the quality of the practice
4. Timely feedback
5. Deliberate practice -- pushing out of your comfort zone

How do these 5 pillars of skill acquisition map to success in software development? 10,000 hours is the most self-explanatory of all the bullets. Unfortunately, 10,000 hours is a long time. Assuming 10 hours per week of programming as a student, and 16 week semesters, that's 1,280 hours after 4 years. In a work setting, if half of your day is programming, that's about 1,000 hours per year (and still only 2,000 per year if you're programming all day, every day, and no one does that). The good news is that this arbitrary number is controversial. Some might even say it's bunk, or a myth. Some quantity of practice is still going to be required, but the quality of practice is likely to be more important than hitting any specific number.

The first aspect of improving the quality of your practice is getting feedback. In college or bootcamp, hopefully TAs, professors, instructors, or even fellow students are providing this. In an industry setting, feedback can vary from pair programming practices, where you're constantly co-analyzing with a partner, to, sadly, little to no feedback at all. If you are not receiving feedback on your work in your position, seek it out. If that is still unsuccessful, I recommend finding a different position. (Hunter Strategy has explicit knowledge sharing and mentorship goals within its organization.) Feedback can, of course, be more than just human analysis – memory, CPU, network, or other resource utilization tests, performance tests, compiler warnings and errors, and code linters and analysis tools are some ways to get feedback in the absence of a mentor or collaborator.

This leads to the next point: a valid environment. That is, feedback should be reflective of the quality of your practice result. This may explain why, when job-hunting, work experience is usually preferred to side projects, as work products are reviewed directly or indirectly by many people and often vetted for fitness of purpose. By contrast, without discipline or experience to self-critique, many side projects are almost absent feedback. Or, side projects may use things that are of less interest to industry. The side project may have helped you become a better developer, but it may not help make the case that you are familiar with the specific things the hiring organization wants you to know. Side projects are also less likely to have the same needs for deployment methods, integrations, security, or other factors more typical to industry that represent a major (an usually less fun) part of the effort.

The fourth pillar, timely feedback, can come through many mechanisms in our industry, such as code reviews, but one of critical importance to both industry and our own efforts to learn, is the test cycle. There are many ways to phrase this, such as the "edit-compile-test cycle." Testing should be fast with accurate feedback, and encompass many facets, potentially even performance testing. The Go programming language, for example, has good built-in tools not to just run your tests, but also to show you the performance of your code. Doing the wrong thing and then correcting it is probably more powerful than just getting it right from the start, so the more you can fail, attempt to correct, and learn which corrections are effective, the more and better you will learn. Decreasing the total time of the cycle increases the density of your learning effort. So, if you join a project and it takes hours or days to test your changes, it might be time to get out of your comfort zone and push for structural improvements on your team.

And this brings us to the final point in the video, deliberate practice: knowing what is difficult and pushing yourself to do those specific things. Or, knowing where your gaps are and working deliberately on the things that will help you bridge those gaps. There is some science that suggests deliberate practice may be the most important facet of all. This can be more than programming: learning effective use of a programmer's editor such as Vim or Emacs; practicing big-O analysis of code you have written; reading code of other projects, even in languages you don't know; pushing to lower levels closer to the machine; reading research papers, documentation, and books, or watching lectures; and more. Since deliberate practice is so important, here are a few ideas for doing it.

For learning new languages, it may be beneficial to have a standard project (or two) of decent complexity, implemented to the best of your ability in the language you feel you know best. Then, port this project to the language you wish to learn. You won't be saddled with learning how to solve the specific problems of these projects – the core task will be learning how to express the solutions with the new language and its ecosystem. If possible, develop criteria, especially quantitative measures, that you can apply to evaluate these ported projects.

Challenge yourself with different types of projects, especially outside of the realm of what you do for work. What that means will vary by person. Maybe that is making and optimizing a game with an existing engine, or maybe it's writing a game engine – a new one, or cloning a classic like Doom. Embedded development with a microcontroller like the Raspberry Pi Pico may be a fun challenge. Dabble with TUIs, native GUIs, or different types of Web UIs. Draw fractals. Implement something non-trivial with a pure functional language. Set up a homelab. Try to penetration test something you made. Or whatever tickles your fancy.

Keep these ideas on quality of practice in mind throughout your education and career journey. If you take two points home from this video article - work on increasing the pace of iteration, and lean into deliberate practice. Learning how to more effectively "level up" is a skill that will pay dividends by itself. Whether you are coming through a traditional theoretical CS degree background and lack skill with things practical to the industry, or if you are going through a bootcamp and have practical skills but lack theoretical fundamentals of how things work, there is an enormous amount to practice and learn, and it will never end. There's way more to working in industry as a software developer than all of this, but hey. This is the fun part.