Learn More by Doing Less
As software engineers, we’re constantly under pressure to deliver. The next ticket, the next PR, the next POC. Whether implicit or explicit, that pressure is never going away.
For many, myself included, that pressure leads us to go through periods of time where we work to dig our own graves. We spend day after day slogging along pushing out code that’s no better than the code we were already able to write six months ago.
Don’t get me wrong. There’s merit to being a finisher. And sometimes, in order to finish that product that is essential for the success of your team or company, you have no choice but to dig in and grind it out.
The problem is that we’re all prone to succumbing to this mindset for the long run. We’ll spend the entirety of our 40 or 60 or 80 or however many hours we’re working in a given week focusing on this task at hand. Our reward? We’ll be handed a similar task a week later.
Three years later, we get curious and start poking around the industry. Oh, I know how to write jQuery-based UI code for a desktop-only web application. But what is this growing DevOps thing? React? Functional programming?
Suddenly, I’m a dinosaur. Whoops.
The reality is that we’re probably putting most of that pressure to deliver on ourselves. No company will succeed (in the long run) by driving its engineers to the ground and affording them no flexibility to build their skillsets and careers.
Unfortunately, your manager probably isn’t going to proactively tell you “Hey you spend too much of your 9–5 working on our product; go take a break.”
So it’s on us to take responsibility and fix that. Not only that — but it’s our job to take responsibility and fix that. There’s a mountain of arguments for why becoming a better informed engineer is good for business.
Further: our number of daily hours of genuine productivity are limited. Cal Newport’s Deep Work details how we only have, at most, 4 hours of deep work in us per day.
It’s likely we’re fooling only ourselves by saying we got 10 hours of coding in on a given day, when in reality we spent 3 hours on reddit and 3 more gossiping with colleagues.
There’s little reason to not consider spending some of our workday learning instead of (trying to be) doing. That might be a tough sell if we work in an organization that glorifies the perception of doing work more so than actually doing work — and indeed, Ray Dalio in Principles claims that is the case for most organizations.
If that’s the case, we might be stuck shifting the learning over to our free time while we navigate political realities at the day job. Or, we can find a new job.
As a developer on a small team without a ton of experience to lean on, I’m constantly thinking about how to prevent myself from falling into a groove where I code only what I already know and stop learning.
Here’s a few of the ways I’m addressing that issue, strategies that can be used by anyone looking to level-up their technical skills. I try to spend at least an hour or two a day doing one of these activities — and I believe you can too.
Learning from mentors and more experienced developers
The most obvious way to learn is directly from others, whether through discussions or hands-on collaborating on code. Most people who successfully avoid the learning vs. doing trap probably do it this way as somebody more senior takes them under their wing, teaches them concepts, code reviews them, and helps guide what projects they get assigned to so that they’re useful for their development.
If you’re at a big company, take advantage of it. There’s so many smart people around you that love to talk software. Ask questions. Engage in discussions. Don’t make the mistake of just grinding away or trying to pretend you understand everything; be humble.
If all of this is already happening for you, that’s awesome. Maybe you don’t need most of the tips below, but I’d argue it could still leave you miles ahead of your similarly fortunate peers.
Reading books
Although reading technical books might be getting replaced by YouTube videos, I think they’re still a key cornerstone in technical skill development. As far as I know, industry legends like Uncle Bob or Martin Fowler have yet to make plans to translate their timeless books to videos.
Here are some of my personal favorites, perhaps too niche to be very broadly applicable; I’m happy to add to the list if anyone wants to contribute, keeping in mind the theme of this post.
- Clean Code by Robert Martin
- Domain Driven Design by Eric Evans
- Effective Python by Brett Slatkin
Reading Medium posts
You’re already here, so this probably barely needs to be said.
One caveat I’ll throw in — before you make any life-changing decisions or start pitching new technical approaches to your team, double check the believability of the author relative to what s/he’s trying to sell you.
I’ll defer a definition to Ray Dalio:
I define believable people as those who have repeatedly and successfully accomplished the thing in question — who have a strong track record with at least three successes — and have great explanations of their approach when probed.
I’d be lenient if you’re seeking ideas rather than answers, but it’s a factor to consider nonetheless.
Listening to podcasts
Technical podcasts keep our finger on the pulse of the industry. Any industry-wide breakthroughs will get mentioned, and we start to feel part of the greater technology community beyond your workplace.
Like the books above, I’m biased towards my favorite language — Python — so happy to throw up others that fit the theme as well.
- Software Engineering Daily: Interviews across the whole SE realm
- Talk Python to Me: Interviews with Python influencers
- Python Bytes: Weekly Python news updates
Attending meetups & conferences
These may be hit or miss depending on your geographic location and/or your or your company’s financial willingness. Meetup.com and conferences serve more or less the same purpose.
Conferences have the bonus of being the more immersive, thorough (and expensive) alternative of the two. The visual aspect to presentations along with the opportunity to meet other engineers in person is what makes these a step up from just podcasts.
Naturally, most software engineers are not the gregarious type to be walking around chatting up everyone at the conference.
But this presents an enormous opportunity: if you’re one of the few who’s capable of overcoming those social fears, you’re in prime position to bring home value like few others can.
Getting assigned work where you’re not an expert
Lastly, it’s certainly possible to be learning while doing. If the tickets coming our way push us slightly beyond our comfort zone, and our management is fortunate enough to keep the wheels turning without relegating us to far-too-long stints on stagnant, hopeless ventures, then maybe this learning will happen naturally.
Alas, even if we occasionally experience these useful work stints, they tend to not last forever —likely far longer than it can take you to master the relevant material — and that’s where the rest comes into play.
This is not a call to stop “doing.” It’s a call to prioritize learning at the expense of some of our “doing” time.
I hope we can learn to resist the temptation to measure ourselves by how many resolved tickets or LOC we’ve contributed. If we can be less concerned about raw output, least concerned about perception of output, and channel that energy to learning, we’ll have made a forever-compounding, valuable investment in our long term contributions and personal careers.