Sustaining Interest

It’s a problem I’ve dealt with practically, but not one to which I’ve previously given any thought in a structured way. After all, I’ve been focused - quite explicitly - on working with Django web applications for more than a few years now. While still as productive as it was when I picked it up (okay, significantly more so) it’s not nearly as sexy.

Nor are web apps. There’s nothing “hot” about CRUD or SQL or solving business problems with the dead simplest, most straightforward solution possible. Which sometimes isn’t even a web app.

So the question is, how do you sustain interested, fight off boredom, and continue to learn and grow when your primary technology [stack] focus does not change?

Side projects

The first solution is the most obvious, which doesn’t make it any less valid. Side projects can include anything from working applications you share with the world to just picking up a book about a new technology (language, framework, etc.) and hacking on something to throw away.

This can be anything that doesn’t produce any direct “business” value, whether for you, your employer, customers, etc.

The fact that this doesn’t produce any direct business value means that it’s usually something you need to do on your own time. This is not equally practical for all people. The upside is that the lack-of-real-value means there’s very little pressure to succeed in meeting some outside constraint and you can just explore at your own pace.

That a side project dead ends is not a bad thing. You’re likely to learn something valuable from the process or from the subject matter, and it’s an intellectual exercise in and of itself.

Wholesale switch

The next common solution is to make a full switch to a different stack. Examples include PHP developers adopting Ruby on Rails, Python developers switching to work in Go, or Angular 2 developers switching to Angular 17.

There’s no denying the benefit of the wholesale switch. You get to experience the entire learning and growth curve all over again, and more’s the bonus if it’s a newer technology where there’s significant room to make a mark.

Yet if this is what someone’s after they’re setting themselves up to need to go through the same cycle again.

Go deeper

Better yet, at least as a start, is to dive deeper into your current stack. Explore the hidden nooks and crannies - hidden at least to you - and pursue a deeper level of expertise.

This looks less interesting at first because, well, it’s the same damn stack! But the highs that you experience picking up and working on a new stack have analogues exploring an entirely new one.

• How do you take advantage of a language to eek out faster performance?
• How can you apply different programming paradigms or patterns in your language of choice?
• What’s something that’s missing and how can you remedy that?

Going deeper can manifest itself in direct improvements in the quality your work (in ways you previously would not have anticipated), but also “pedagocical products” like blog posts and meetup/conference talks. These give you the opportunity to share what you’ve learned and force you to go deep enough to make sure you’re sharing somethign valuable.

Adopt different tools for new problems

When new problems - I won’t call them features - pop up, you have an opportunity to use and learn a new tool.

Maybe it’s critical that the system you work on adopts an image resizing service, but it must be self-hosted, and for argument’s sake nothing of the like exists and must be cusom developed. As a Python or Ruby shop you could easily accomplish this with either language, but it probably makes more sense to seek faster execution time. So now there’s not only an opportunity but a good business reason to look into writing part of the stack in Go, for example.

There are limits to how far you should take this; with a small team you may not want 15 different tools written in 15 different langauges, or even 5 tools in 5 different languages.

It may not be languages either, it could be deployment environments/tools, backing services, or libraries in your stack’s ecosystem you simply have not had a justification to use.

New problem/technology domain

By problem/technology domain I mean a domain that could be cross-stack and also cross-business domain.

In brief example:

• search
• data analysis
• geospatial

Each is built on a foundation that is by and large platform/stack agnostic. There may be winners in terms of languages and databases that better fits (for various reasons), but could puruse these with any language.

The examples I picked were the first that came to mind because I’ve had an opportunity to [briefly] pursue work in each area. And even though the stack I was working with was largely unchanged I still got all the enjoyment of learning a new problem domain.

“Web apps” should probably be on that list, too.

New business domain

Less obvious, and not equally practical for everyone, is finding a different business domain. If you’re committed to your stack - or even if you’re not - it could be that your boredom and decreased engagement comes from the underlying business domain.

That said, I think the superficial excitement of the business domain is less important than the ultimate value of the business domain. A rule of thumb I learned later in life than I’d have liked is that many of the subjects and domains that look boring are actually more engaging than the ones that superficially look exciting (the people I know who pursued statistics were far more intellectually engaged than most of the people I know who pursued law).