Legacy

Legacy is usually the last thing a software engineer wants to hear when they are evaluating to join a company, those green fields are always so much better they present you the opportunity of picking the latest and greatest tools of the season, so you can stay up-to-date and brag about on Linkedin.

But the reality is that everything, everywhere, has legacy. Some are slightly less horrible than others, but believe me, everyone has it.

Netflix? Yes. Even Google? Oh yes.

In some instances, it is just way worse than others. There are cases where the tech is so ancient that the knowledge required to operate is not transferable to other companies or it is simply too painful to work on it.

I've experienced both myself, it's not fun.

Harsh Truth

If we remove the extremes, legacy is just part of the job, because whatever you do will become legacy, even earlier than you might think.

The pace of the development of tools, frameworks, and languages is ever-increasing, which is good, but no company can provide you the environment to keep up with it.

Companies, generally, are using technology to solve problems, and in most cases, the tech is only a detail in a much larger picture. Usually, if it works no one cares about how well-designed or how clean your code is. And to a certain extent that is a good thing, hyper fixating on tooling is a dangerous and often disastrous path.

To strike the right balance of pros and cons when introducing new technologies is a skill honed throughout years of experience where a little bit of luck is also involved.

Often times the wrong move can be costly, even fatal. That is why most companies tend to stick to their tried and true set of tools.

The Work Never Ends

While this can be good for the company, a certain level of skepticism can save a lot of headaches. For the software engineers on the other hand can be frustrating, or even complicate the further steps on their career.

That is where side projects come into play, you control everything about it, and the focus can be whatever you want it to be, language, framework, OS, etc.

It is a playground for you to test new ideas, tools, or just practice. The more tedious or repetitive your day job is, the more important it becomes.

To some it might sound terrible: Just more work! I get it, in a way it is, but to stay competitive in software development you have to put in the extra hours to keep up with a rapidly changing environment.

You will not have this time at your day job, the company pays you to solve problems not be up-to-date, or make you technically fulfilled.

Ok, now what?

Once you decide to take on a side project, usually the first stop, and to some the last is: What to build?

Fair point, I struggled with this one so much that I created a list of ways to approach it.

Instead of giving a list of concrete ideas, here are some approaches that worked for me.

1. Copy

What tools are in my day-to-day that I enjoy using, and I know exactly how I want them to behave?

Music players, social networks, command line tools, wrappers to facilitate repetitive work, etc.

Spend a day or two paying close attention to the software that you use and love then pick one to replicate completely or partially.

2. Scratch your own itch

The good ol' strategy of trying to solve a need you already have.

Do you love Spotify but would prefer to control it via Neovim? Good one.

How about a nicer way to navigate your PRs? Great.

A good exercise in this case is to keep pen and paper at hand and every time you miss a feature or product, describe roughly what you want. Do that for a week, and you will probably be surprised by the amount of things you will come up with.

3. Tactical

If the above approaches left you empty handed you can do the analytical way. Pick the technologies you want to learn and research for trends that you can apply.

An awesome tool to play around and figure out trends is Google Trends.

Conclusion

Companies will not, and cannot keep up with the release of every new cool piece of tech out there, it's not what they are there for.

Despite what some might think, software development requires a lot of energy both in and out of work. But having a side project you enjoy, and have at hand to try out things and experiment might be the difference for getting your next job or even the next step in your current one.

That's why I strongly advocate for side projects, there are huge benefits when you invest those extra hours.

It can make you more fullfilled, sometimes happier, but always better at your craft.