In one of my previous blog entries I explored a story of a talented engineer named Jan who, through a series of questionable decisions, found herself creating an environment which actively stifled growth. Through that story, I hoped to demonstrate how even well-intentioned engineers can succumb to pursuing their own interests, even if they ultimately conflict with the interest of the company/organization with which they are employed.
That blog post drew a lot of attention and sparked some great conversations. One of the recurring questions was, “how can I experiment with new technologies, while also providing value to my company an organization?” I think this is a great question, and exactly the type of dialogue I was hoping to generate.
Finding Balance
I think all work environments should encourage the enjoyment of the work and maybe even blur the lines between work and play. However, in doing the latter, there is a risk of cultivating engineers like Jan (as well-intentioned as they may be). Instead of finding ourselves on either side of an extreme, we need to find balance.
The balance that we’re looking for is between learning, experimenting, innovating while also providing tangible benefits and that coveted return on investment from your salary. Like it or not, you are beholden to your employer to produce value – that’s kind of the whole point (and why there are employment contracts).
So, how can we, as engineers, find balance between satisfying our own curiosities while also producing value? I won’t claim to have all of the answers. In fact, I hope this this blog post sparks more discussion. However, I can provide a few examples of tips and techniques that have worked for me.
Tips and Tricks
1. Open Source
One of the best ways to scratch the itch of experimenting with new code is to find an open source project that you use, and look for opportunities to contribute. Visit GitHub and find a project that’s hosted there. Typically projects will have lists of issues, some marked as “Help Wanted” or “Good First Issue”. These are ideal candidates to dip your toe into the world of open source contribution.
I do recommend you peruse the existing issues and pull requests and see what kind of community engagement exists. Some projects can be a bit less fun to interact with. Be sure to check out an CONTRIBUTING.md files, or developer guides to ensure that you are aware of the expectations of the maintainers. For a general guide to getting started, check out this repository.
2. Mentoring
A great way to re-invigorate your passion for software development is to engage in an mentor-mentee relationship. Regardless of which side of the mentoring you are on, you will certainly gain a new perspective. Everyone approaches problems differently, so working closely with someone else as you/they grow is a great opportunity.
There are tons of resources online about mentoring, so I won’t list any here. In fact, it doesn’t need to be a formal arrangement – just work with someone more junior/senior than yourself and see what you can learn! If this is someone in your company or organization, then you are providing value to the company in the form of knowledge sharing – win-win!
3. Community/Non-Profit Involvement
Depending on where you live, there may be a multitude of opportunities for helping your community by contributing your time toward a cause that you care about. When the COVID-19 pandemic started to spread rapidly in March of 2020, there were many organizations looking for help with statistical modeling and contact tracing.
In my area, there are several such non-profits, one in particular is Code For Philly – there are many more. A quick Google search turned up donate:code which seems to pair programmers with projects. I haven’t worked with this organization, but there are many like it. If you don’t find one that you like, start your own!
4. Tooling and Automation
I understand that not everyone has free time to devote to their craft. Perhaps you have other hobbies – that’s normal (and human). So, one of my favorite ways to learn new technologies, experiment, and satisfy my curiosity is through tooling. Every day we complete a series of tasks. Some of those tasks require us to do the same things over and over. This is “toil” and in the DevOps community, it is something that should be reduced to near-zero. Many engineers don’t think about reducing their own toil – they’ll happily type out the same git incantations over and over.
Find tasks that are repetitive and automate them. It could be as simple as creating a git alias that combines several commands, or a Bash alias that does the same. Like LISP/Scheme? Play with Emacs and add some extensions. Want to learn Python? Create an auto-complete utility for the command line. Want to play with Rust? Find something that’s currently running slowly (perhaps in an interpreted language) and rewrite all or part of it. An example of this can be seen in the powerline-go project.
Some tools are less obvious. If you have an existing project or service that requires support, maybe you can build a support bot. This doesn’t have to be complex; in fact, it’s better if it isn’t (at least at first). You can read a white paper that I co-authored which details the strategy and benefits of such an approach to automating support.
5. Enjoyment in the Process
Not everything that we do as engineers is fun or interesting. But within every project, there should be at least one or two interesting problems to solve. If you’re just banging out Angular or React web pages, maybe you can build some tooling around that to reduce the boilerplate. Maybe you need to add license headers to all of your javascript files – try writing that in a Bash script and get more acquainted with *nix tools (sed, awk, grep, etc.).
Even outside of the project, I suspect you’re using a defect/issue tracker. Does it have an API? Can you do anything there to make your job easier? Maybe it’s just changing the way that issues are tagged, so that reporting is easier. The solution doesn’t always need to be code. There are a myriad of problems that need solutions ranging from toil, to processes, to human interaction and psychology. Spread your wings, little bird; you may be surprised at what you find.
It’s Up to You
Ultimately, your happiness is your responsibility. Perhaps none of the options I presented work for you in your current role. To be clear, my list is far from exhaustive so don’t get discouraged. Hopefully a few of the techniques sparked some ideas and you can pursue your own options. Don’t forget to reach out to peers and network with fellow software engineers – there’s a wealth of options out there, you just need to find them.
Maybe you’re working in an environment that is stifling or in some other ways toxic. If so, I implore you to not simply accept that as your fate. The skills of a software engineer cross many disciplines and are generally always in demand (as of writing and before the robot apocalypse). Find an employer who values your work and your creativity.
In the end, you are in charge of your own happiness. Don’t let that candle of passion fizzle out. As unsolicited life advice: don’t stop looking until you find what makes you happy.