Growing Pains - Learning how to learn
Previously I discussed how your career path can be simplified into a series of paths that go from being a consumer of information, to being a producer of information. In this post, I’d like to think about how our learning patterns could also change depending on where we were along that path.
Sadly this isn’t a post that I have a definitive answer on myself, I’m actually torn between multiple ideas which I’ll share here; I’m genuinely unsure which is the best options so would love to hear any opinions that any readers of this post may have :)
Recently I was asked “What does it take to be a successful developer?”; my answer emphasised the importance of not skipping the basics and getting a deep understanding of the fundamentals. I stand by this advice (kind of). In the earlier stages of your career there is no substitute for going extremely deep into technical fundamentals and it is knowledge that will be invaluable to you throughout your career.
In fact, I would argue that as a beginner it’s more valuable sticking to 1 or 2 core technologies and really mastering them rather than spreading yourself too thin. Only then should you expand and look to grow your knowledge into other areas.
But…let’s skip ahead a few years now. If you’re anything like me, then your brain has a limit to how much information it can hold. Plus, there is probably also a limit to the amount of time you have to push that information into there. which leads to an interesting optimisation exercise:
you have limited capacity and limited time, what information do you prioritise storing?
There are 2 main ways you can approach this situation.
Low Breadth/High Depth
This is was I was advocating for earlier. Pick a topic, and go deep; understand it inside and out. The benefits of this (aside from the personal satisfaction of the skills and competency gained) are that you can become a go-to person for a certain skill. Growing specialist skills can make you invaluable, especially as a company reaches any sort of scale. For example here at carwow we’ve occasionally brought in a redshift expert when we’ve hit a wall with our data handling.
High Breadth/Low Depth
Pretty much the exact opposite of the above. Rather than going deep, spread yourself out and keep a basic understand of a bunch of different tools/technologies. The benefits being that you can become an effective advisor; while you may not have the in-depth knowledge to implement you’ll have an array of potential solutions that you can recommend and look into deeper when the need arises.
Which way to go?
There is no right or wrong answer here, but in typical fashion, the answer is ‘it depends’. It depends on where you’d like to go with your career; in my eyes there are 3 main routes you can take:
path of the developer
It’s a complete fallacy that growth as a developer means becoming a tech lead. You gain satisfaction from being a technical expert and want to focus on implementation. For this stick to High Depth learning; you’ll gain unparalleled knowledge and experience which will make you invaluable to teams.
path of the technical leader
The reality here is you’ll be spending less time in the codebase; but you should still be pretty close to it. Effectively you’ll need a middle of the road approach here. Go deep into the core tech you’re using, but also keep a broad view of what’s new / useful so you’ll able to advise the team.
path of the technical manager
Again, to be useful I believe a technical background is essential, as is the ability to dip in and work on features/fix bugs/review pull requests etc. However, this is secondary to your role, and so here you’ll want to go high breadth. You’re no longer the person the team looks to for deeper technical decisions but you should still be able to provide guidance and experience.
Your brain has limited capacity and you have limited time. Ensure you’re making a conscious decision about what things you’re putting in there, and how you’re doing it.