Go broader to go further - leverage your learning chances

Introduction

This will be a short piece about how to grow in your career from a perspective of someone who has been around the industry for about 6 years. I believe this is neither too long nor too short, but, instead, just right, to be able to throw in some advice about what has been working for me recently in terms of growth. Obviously, as with all these types of blog posts, everyone's circumstances will be different, companies will be different and the combination of previous work experience that makes your own skillset a unique one, will also be different. So, what has worked for me, may not work for someone else. Nonetheless, I believe there is value in exploring the idea of going broader to go further. This can have several different meanings, depending on whether it's applied to your $DAYJOB or to some side-projects or ideas you might have, but, I will keep the list uniform for both contexts here.

1. Practice writing

Writing is at the core of what we do as developers: we write code, tests, tickets, outage reports, etc. Writing is ubiquitous in development work in many different forms.
However, what I mean here by practicing to write is a bit more specific. I mean, really write.

Nowadays, most companies do have some form of external blogging or even newsletters to share their updates with interested people, like, current customers, current/former/future employees or other developers who have an interest in learning about some particularly interesting technical solution for a problem. If your company doesn't do it, see if that's an area of opportunity you can explore.

This is the kind of thing that is usually non-technical, since, it mostly involves preparing and writing text, usually together with some marketing or copyrighting team, which is a great way for you to see different aspects of the large organization you are a part of.

When doing this for your own side-projects or explorations, it's a lot easier to produce much more written content, just like the current collection of these blog posts, for example. They can be more free-format and you can write about what you like. The important takeaway is that investing time in writing at a professional context can bring many benefits: visibility, improves overall cohesiveness of the codebase, facilitates onboarding new colleagues, and keeps a detailed record of architectural decisions, documentation, etc, which is invaluable in the long term.

1. Do something new when possible

It's easy to fall into a trap of only doing your "routine work". Same challenges, same pre-packaged solutions, time and time again. This is probably fine for a while, but, in the long run, it can become a bottleneck for how you perceive your own impact inside your company in terms of value delivered, as well as how much you can grow within a "familiar setting". So, when given the opportunity, try and "shake things up" a bit. This, again, can mean anything in different contexts: switch teams internally, give a talk about a topic you like, investigate that platform team bug to be familiar with the dark corners of your codebase, etc. These opportunities usually arise as a mix of things that are already in front of you and just need to be done, or, as things that you can create for yourself by being proactive and "championing" it to your team, department, company, etc.
It's both easy and hard to do, since it depends on your own style, the current workload you have, and other factors, but, it's a good thing to strive for.

1. Look into devOps, if you code, code, if you devOps - in other words : containers

Automation, batch processing, jobs, queues, pipelines, terraform, containers, etc, etc, etc.

The current landscape is combining code and infrastructure more and more, in ways not thought of before. This is great, because, its fertile grounds for innovation.
As a developer, you can now have a say in how to manage your deployments, your pipelines and even your own code, to better fit existing infrastructure, and, as a devOps person, you can now write code to automate a lot of stuff that was more on the configuration side before.

Containers make it look almost seamless in the way they "merge" both worlds so well, and, I believe that they have been the best innovation in the industry for product-based development companies within the last 5/6 year period since starting my career. Writing integration tests is now a breeze thanks to containers. Testing new language releases, handling deployments with tools like docker swarm or k8s is more and more becoming the norm.
If you really want to explore new possibilities for your own workflows, side-projects or simply to help move your company forward, I can safely recommend learning Docker as well as possible, and, delve a little bit into Kubernetes, as these tools are becoming pivotal for many, many companies. So it will pay off in both the short and the long term to learn them well.

1. Subscribe to dedicated newsletters or read blogs you like

I think this has helped be increasing my impact tremendously, in small ways that pay off in the long run: by reading and consuming information from newsletters and blog posts on topics like code quality, leadership, management and career paths, I've come to appreciate that there are many things that YOU as an individual contributor (IC) can do, in order to help your team and company grow: writing is very important, and, simultaneously, keeping an eye out for small process improvements, is a great combination that, when rallied around the right people, can really bring your impact to the next level through your interpersonal and soft skills, which, can be just as impactful as technical skills.

1. Stay on top of what's new in the industry

Somewhat linked to point 4 above, but, as a very concrete example: You're using Java 11 at work? Great. Java 17 was just released. What's a better weekend project than simply trying it out for yourself?
Even better, if you can scope down and/or recreate smaller snippets of code that would resemble a codebase you have to deal with at your job, you might discover a lot of benefits in thinking how that new release of your favourite language or framework would definitely improve areas A, B and C of the codebase. This is valid not only for very tangible things, like new languages or frameworks, but, also, for smaller updates on other productivity tools, like GitHub, Jira, Slack, etc. If you invest some time in learning what is new on these tools, you will often be surprised how many new tiny things can help you or your colleagues in a very tiny, almost too simple way. But, when you start compounding these small things over time, you can get some really nice benefits that you'd might not have even hoped for initially. So, if you can and are willing to, stay on top of your game. It's easier than you think when doing it for a living.

Conclusion

These are just five simple things that I've found myself doing, more and more, especially over the last year and a half, and, I can say that its combination has helped me grow as an engineer tremendously fast. Much faster than if I had simply stuck to do my normal 9-to-5 job and attempted to simply learn as I did things.
It's also something that does feel very natural to do, because it uses the "compound interest effect": I do a tiny bit every day, and try out a tiny thing here and there... and... After all these years so far, when I look back, I'm definitely reaping the benefits of doing these smaller things over time! Hopefully, this can inspire you to look into broader horizons as a way to power your learning chances!