| In my own experience, the biggest "killer" is that it just gets boring and repetitive. I've been programming for 20 years and it is a struggle for me to find something "new" that isn't a mild variation of something I've used before.. There's only so many variations of an application that can bring something really new to the table that gives you that excitement of learning something new like the first time you "get" TDD or DDD, or that first time you successfully implement an efficient CQRS model, with eventually consistent events, or run a GraphQL API that swaps the challenges of REST for a new set of problems and so on. Switching industries doesn't help much either, as they are either just more of the same but with different vernacular, or so niche that you'll need to have really been there since day dot of your career anyway. There's only so many new libraries/frameworks that I can get excited about, and the rapid state of change in many ecosystems means that quota is pretty much full 100% of the time. Languages, too. That's before we even tackle the problem of getting _hired_ for languages I've not had any professional experience with, and with the added bonus of 0 personal time to implement side-projects, and a lot of companies never needing to stray from their current stack.. it's just not going to happen. So now the only thing left that tickles my fancy are the "abstract" problems. Instead of now focusing on implementing code to fix a problem, I'm asking and researching the questions like "How can the platform (and not just application) be more performant?" or "What is that the team can improve on?" and "how can I improve the learning culture?" etc. and using my experience to, at first, recognise these problems that are invisible to a lot of people, but also gauge which ones are actual problems or mild inconveniences. |