Seems obvious for the engineering community but hear me out:
I believe something that all levels of engineers can benefit from is looking at abstract problems they encounter in their (or their companies) everyday function and trying to solve them in code. Yes a given technology may already exist to solve this problem and it is certainly worth evaluating it’s suitability for your needs - but what if you find a use case that hasn’t been solved for?
Enter in hobby projects - the things we build for sake of building - that I would argue serve great benefit to your skills as an engineer. But also if you are a mission focused engineer - these are likely things that have a greater focus as well. You want to investigate trying something new for the sake of also having an informed opinion or greater situational awareness.
Existing solutions
I’m going to be quick here - as my freetime is often limited - my system for keeping tabs on gaps across missions and continually evaluating existing or new projects for suitability is also a very valuable process that I believe all engineers have to be accountable for - but that is not the topic today.
Identify a Problem
Say you keep stumbling upon a problem - take for example the availability of systems to end-users - and you want to contemplate how to solve that problem. To the above comment - definitely check out existing projects or solutions - but I’d argue it can be just as valuable to begin thinking about what you would build to solve for said problem.
The act of building allows you to break the gap or problem down into more granular subjects that can be further decomposed. This is a great way to begin to think about the problem and how you might approach it.
Build
My next steps are to created a blank repository on GitHub and simply start drafting a README.md for the idea. If nothing else this is a placeholder for your thoughts in such a way as to both not lose your frame of reference but also enable you to get others involved.
The biggest piece for writing this post that I wanted to build up to was the sheer value of the act of building. Given there are a number of considerations for languages - I often default to the ones that I am most likely to use in a my day-to-day. This means I’m stretching my skills to solve problems I don’t necessarily often solve for AND building a collection of code that may very well end up being used elsewhere.
When the time comes to accomplish a task for something I’ve similarly done on a hobby project elsewhere - I can easily recall where it is located and execute.
Keep building
I’ve got a number of repositories that have resulted from this exact system and all of various states that have eventually lead to inclusion in my daily work. Some never got passed the ideation phase while others were built and expanded upon and maybe even transferred into my company (willingly) to be used.
Nonetheless keep building - you’ll write code to solve for problems that you actually face versus the standard coding challenge problem. I enjoy a coding challenge question as much as the next - but a good mix of both will put your coding skills to more real-world use.