And very often, it is. But sometimes it ends up being the type of problem that requires a much more involved architecture change to solve correctly. It's not just a one line change, but something the whole team will have to sign off on. Which will require at _least_ 100 times the work of the usual two line fix. By this point, I already 'know' how to solve the problem, and it could be very easy to lose interest. But the error emails keep on coming. And they're easy to ignore because "they're just those weird errors we get from that 3rd party API we use so there's nothing we can do about it."
But these emails are really annoying. So I find I have to reframe the problems from understanding how to fix the issue to how to get buy in and get the fix actually deployed, and I haven't run out of these types of problems at any company I've worked at, and that works for me to keep my attention.
So a new approach I am trying is the "GPU Pipeline of side projects". First, I choose to trim my list of side projects to a few important ones (4 is a number I like, so four). I work on them in a parallel pipelined fashion. So I have one that's more advanced, one that is being setup, one that is being fleshed out, one still in ideation phase (you get the idea).
Secondly, I realize that when building things, the novelty can come from "recursing down to the details". For example, setup a AWS pipeline for code deployment would mean, learning how to setup an Ec2 deployment, then a Chef or Puppet instance, then easy config management of them, best way to document our setup (gitbook etc) and so on.... So if we use our boundless curiosity, which is both a strength and a weakness, to look a little deeper, we will find enough novelty to keep going even in a "single" project.
What I realized is that one single project is like a LISP S-Expression. (project). You (eval project), and it returns (list sub-project1 sub-project2 interesting-research3 wonderful-idea4) All you have to do is keep eval'uating the sub-expressions till you hit an "atom" of truth to share with the world.
I would suggest you set up with a consulting firm - Thoughtworks for example tend to try out a lot of new things across the entire company. This means that getting from 0 to somewhere, quickly, is something they can really sell. The downside is the poor bastards like me who have to deal with no one wanting to throw out the 'prototype' version of the solution.
So, novelty seeking, I do this: - work part-time on something i'm passionate about as it's products that help others. Research based, which brings more novelty naturally. Also, passion for me was the most important thing to keep my focus, not "interesting" as "interesting" gets boring. - spend rest of the time mostly building random side-projects that won't be finished, but I don't care, that's not the point.
Seems to be working well.
With your generalist skills, you may make a great developer evangelist who can give overviews and demos of new technologies at developer talks, internal corporate trainings, or online trainings. They get paid well and I have come across some right here on HN.
My Java code: https://github.com/atemerev/pms/blob/master/src/main/java/co... (saved me probably man-years in my consulting projects).
Code samples for Javascript, Matlab, Haskell and Go available on demand. :)
If, by maintainability, you mean "looking at the mess I did some years ago in some large project and see how it turned out", then yes, I avoided such projects and large teams. Most of my code was written either by me alone or as a part of 2-3 persons team.
What's killing me is inability to stop learning and start focusing on doing, intensely and persistently. When I have a job, I can't focus on the job. When I try to run my business, I can't focus on administrative side and routine (and successful routine is the essence of every business). I only want to learn, even if it is self-destructive, even if there are many more urgent and important things to do.