Tech is a field of constant learning.
As programmers, our job is to figure out solutions—which means approaching problems we we don’t know exactly how to solve.
Tech is also a fast-moving field. The tools that we use—languages, frameworks libraries—turn over with such speed that an eight month hiatus from the industry could render our API-specific knowledge obsolete for the tools our teams need.
So we’re constantly updating, upgrading, broadening, and deepening our skill sets.
And for us, formal education is particularly inapplicable.
Modern computer science bachelors and master’s degrees, while valuable for background in fundamental hardware and software applications, are notoriously not adequate preparation for a software developer job. Many of them cover API design in only a cursory sort of way and do little for imparting application conventions, historical precedents for application architectures, or (god forbid) any sort of practice with testing, let alone test-driven development. Developers joke about the O(n) notation question in the Google phone screen being the only time they have used their CS degrees in a professional context. And that question, most likely, is the result of some Google Engineers sitting around thinking “How can we construct the interview to make sure people have CS degrees?” So even this application of the thing is rather tautological.
Some companies offer tests with certificates for languages and like C or Java and frameworks like Spring or Android. You pay (a lot, usually) to take these tests and to obtain the associated teaching materials, usually in the form of books. These tend to cover syntax, which is marginally helpful, and tangential information that is decidedly unhelpful. (Example from one of the Spring certifications: how many libraries are in the core Spring package? The answer to this question has nothing to do with anything you have to know to write a Spring app). They still tend not to cover subjects that are language-agnostic and nevertheless critical for professional programmers to know. You will not be tested on application architecture, refactoring, or programming for humans. And still, of course, nary a word about testing.
So to build and to rebuild the skills we need to do our jobs, we have to find the answers ourselves.
Googling is absolutely a skill. Choosing the best answer from a barrage of StackOverflow suggestions is also a skill. But these are scattershot skills: you use them in very specific circumstances, and any one bug fix does not necessarily level up your overall approach to building software.
In order to level up, we need habits and exercises that help us comprehensively improve our skills.
I should mention that level up has become a term of art among tech people. Evidently we got the term from role-playing games, in which leveling up means that your player character gets stronger stats and more abilities like hit points and spells.
For a long time, I did not know this.
I found out what people meant by level up about three and a half years into my programming career when I played my first game of Dungeons and Dragons. I had heard the term before, but I thought about it quite differently. And I’ll share my interpretation with you because I humbly submit that it is useful.
It sounds like most folks picture leveling up as a little avatar of themselves advancing up a ladder of 20 or 30 levels, moving up to the next rung incrementally as they gain experience. This creates this visual for us of our skills improving linearly with our time spent in tech. I’ll henceforth call this the ladder interpretation.
The ladder interpretation was new to me after three and a half years in tech.
I pictured, instead, what I will call the derivative interpretation. It comprises a series of maybe three levels.
Level One: Getting better, adding skills
Level Two: Improving at getting better/adding skills
Level Three: Getting better techniques for improving at getting better/adding skills
To me, each level represents the derivative of the level below it.
In mathematics, the derivative of a function describes how fast it changes.
So a flat line has a derivative of zero: if there is no improvement or adding skills, our skill level stays the same (skill development is zero).
A line that points upward has a derivative of some constant: the same ability to develop skills forever means that skill advances linearly.
A line whose derivative is some linear function, though, looks like this:
It’s a quadratic function, and as you can see, it gets steeper and steeper as we move to the right. So if our ability to get better and add skills is improving at a constant rate, then our actual skill set improves at a faster and faster rate.
All this time before I played Dungeons and Dragons, I thought “leveling up” meant focusing on the next level up of skill development. In the very beginning, you’re focused on learning the basics of a language. But then, with a little experience, you “level up” and focus instead on learning techniques for learning more about the language. Then later you “level up” again and focus in iteratively developing better strategies for learning more about the language.
And here’s why I think it’s useful: in the ladder interpretation, our skills improve linearly with our time in the game. But in the derivative interpretation, we create opportunities for our skills to improve faster and faster: by focusing on the next level up of skill improvement, we accelerate the rate at which our programming abilities change.
So, for three and a half years, this is exactly what I was trying to do.
I got a notebook and started experimenting with comprehensive, high-bandwidth techniques for improving my skills. In the process, I came up with some things that really, really accelerated my skill development. I would like to start sharing those techniques with you.
Whether you are a new programmer with just a little app development experience or a seasoned veteran looking to make a breakthrough that will forever bear your name, I think these techniques have a place in your repertoire. So this will be the start of a new series, and I’ll share each technique in its own post with examples.
Before we begin, I want to give you the opportunity to prepare the way that I prepared.
Consider Getting a Notebook
For almost all of the techniques I use, I have some accompanying exercises and record-keeping that I do in a college-ruled journal that I have carried to every day of my job for years. It has been the same journal the whole time because I write very, very tiny, so I get the privilege of looking back on my work from years ago and seeing how much I’ve grown. You could have that to look forward to!
But in the meantime, I recommend picking up a journal and pen that you will enjoy using. The next post in the series will cover our first technique for leveling up our programming skills.