#4 - Training Wheel Coding
Hey everyone!
Things are weird right now. An absurd number of companies are doing things like layoffs and cancelling internships. People are protesting the lockdowns across various states.
And there are things like this:
I can’t tell you what’s going to happen next. The only certain thing is uncertainty.
Housekeeping
Given this backdrop, I’ve been trying to figure out what would be most useful to readers: Career advice? Job hunting tips? Technical topics?
Which led me to a couple ideas for experiments:
Build Together - An open source project open to readers where the goal is to get you some hands on experience and offer real code reviews. A resume booster - and educational too
Post Mortem Reviews - outages are compelling stories and serve as excellent case studies. I want to do write ups and analyses from some post mortem’s, such as this one from Square.
For Post Mortem Review, look out for a “bonus” post later this week 😉
For Build Together, there’s a lot of risks that need to be addressed first. To make sure there’s sufficient interest, I put together a tiny survey. Lmk if you’d be interested in contributing to a project like this! 👉 https://forms.gle/1AYvjiyj8FCG7uW18
Alright, let’s dive into this week’s topic.
Training Wheel Coding
This week I wanted to take a break from technical topics and talk about something that can stunt your growth.
When we’re learning to bike, we often start with training wheels. But some people rely on training wheels for far too long.
There are training wheels for software engineering as well. So what are they? I believe there are two major ones:
Over-reliance on experts
Copy pasta coding
In the early days, you need to do both of these. Skipping them could be disastrous. But if you rely on them too long, you might find yourself a few years in and feel extremely limited.
Let’s look into what these are and how to remove the training wheels.
Over-reliance on experts
When you’re starting out, you may not know much about testing, git, concurrency, security, authentication, databases, caches, load balancers, Redux, etc. So you’ll turn to the local expert.
The first time you go to the expert, you’ll likely need to implement a feature quickly. There’s not enough time for a deep lesson. So they’ll give you a fish: 🐟 “Just add the @Transactional annotation”
And then the next time, you’ll encounter something a little different, so you go back. Again, there’s not enough time to teach. So they’ll give you another fish: 🐠 “This time, add @Transactional(propagation = Propagation.REQUIRES_NEW)”
And now, from a few of these examples, you can actually handle 80% of issues that come up!
But one day, the expert leaves the company. And a few weeks later, something comes up “The database connections are all timing out!!!”. You wish you had learned how to fish: 🎣
The remedy: Learn concepts a little more deeply than you need to for the feature. I like to watch YouTube videos and then read a chapter from a book. Finally, I use the Feynman Technique to make sure I’ve got it.
Copy pasta coding
Early on in your career, you’re going to do a lot of copy pasting. Your first assignments will likely be to extend functionality in a way that resembles something that already exists.
Your first feature
Some people can get stuck in a world where all they know how to do is copy paste other examples. In fact, you can become pretty effective doing just this! Most of the code I write these days is a variant of something I’ve written in the past.
But the problem is, if you just copy paste, do you know if the code you were copying was any good? Do you know how to make that code better? Quite often, the code wasn’t all that great. And very frequently, you’ll be too scared to make big changes.
The remedy: Once in a while, start from blank files.
The benefits are twofold. First, blank files test your recall. Recall is important because it will speed up your implementation if you don’t need to reference something. But more importantly, it forces you to be deliberate about everything you type. Does it really make sense for this method to be static, or have you just been doing that because that’s what everyone else is doing?
The first time you try this, you’ll feel like you’ve been tossed in the deep end and will be gasping for the comfort of a reference file. But as you plug gaps in your mastery of your language - you will feel increasingly comfortable starting from scratch.
Wrapping Up
In your first few months or even your first year, you might feel really productive if you’re working on a codebase with plenty of examples to copy and are surrounded by a bunch of experts.
But that progress is being propped up by training wheels. You’re achieving more than your skill level.
It’s funny, the fix is really simple: practice recall. Use the Feynman Technique to make sure you understand concepts. Write features from blank files to test your mastery of your language.
I have to admit that I don’t do this all the time, but each time I do, I get a little better.
Alright, that’s it! A short post this week, but I hope it inspires a small sense of vigilance. (Perhaps I needed to add a few cautionary tales of engineers who never progressed 🤔)
Stay safe - and I’ll see you later this week, with a Post Mortem Review!
Phil