This post “Developing Talent in R&D” resonated with me and brought up a few thoughts/observations and suggestions.
A culture of learning has to be part of the DNA of the organization. As in, it needs to be reinforced from the top. In a bottom-up approach, you don’t have consistency in creating an environment that lets engineers know it’s okay (and important) to spend time learning. Without consistency, you rely on each engineering manager to believe in a culture of learning; but if it’s not part of your company values, you won’t hire for it — decreasing the likelihood of a consistent result.
Having certain technologies as an optional default stack is great, but you must (as the article suggests) document the “why.” It’s too easy to say “here’s what you should use and how to use it” without “here’s why we chose this tech and here’s what problem it’s solving/abstracting.” Otherwise, you end up with an abstraction where folks using it don’t understand what it abstracts, missing a core learning opportunity that could make engineers more well-rounded.
If you’re at a company that doesn’t have a consistent culture of learning, it’s your job as an engineer to drive your own learning. I recommend looking at each ticket or project and asking yourself “what might I learn by working on this?”
If the answer is not much, then think about how you can make the task harder — to force a situation where you’ll learn something. Do this responsibly, of course. Maybe you can try a different framework that seems better suited to the problem. Maybe you can try imposing a resource constraint on the implementation (I can only use X number of threads/processes, or I can only use up to Y MB of RAM). Again, be considerate here: don’t write crazy unreadable code because of this artificial constraint and end up passing off risk to future maintainers. Maybe instead of using an established client library, there’s an opportunity to write a small, possibly throwaway one that lets you learn about concurrency, communication protocols, caching, and/or some versioning best practices.
If you won’t learn anything by implementing the task, and you can’t come up with a reasonable way to make it harder, then consider passing the task to someone who is likely to learn something from it. This is also a good delegation hack if you find yourself taking on too much work.
My point is that if you care about getting better at the craft of engineering, drive your own learning. It reminds me of a saying: “you’re either a Senior engineer with 10 years of experience or a Senior engineer that did 1 year of experience 10 times.” I strive for the former and I hope you will too.
