Backend generalist. 10+ years coding professionally. Enjoys coming up with nuanced and thoughtful solutions to complex, thorny and ugly problems in old systems.
Interesting question. I don't have a short answer, only some observations.
Overall, I guess I'm in the camp of having user needs & business value be the guideposts for prioritization. I think I'd define business value more inclusively than many; paying down tech debt, for example, often provides business value by my standards. That said, my bar for some stereotypical enthusiasm projects ("let's rewrite our stable customer-facing backend in golang!!!11") is pretty high. They're fun to do for an engineer, and maybe address some benign but offensive code smells, but hard to justify the opportunity cost if they take time away from work that produces more direct value, especially if what they're fixing is "good enough" overall.
I think as we get more senior as engineers, we tend to do a better job of connecting things that we're enthusiastic about for our own reasons to business value/user needs/etc. For example, helping to justify a refactor or code cleanup by understanding the product roadmap, or identifying a business/user-facing gap that can be addressed with a new technology or product. Enthusiasm all by itself may not be given much of a role here, but arguably it doesn't need one; the business value it produces speaks for itself. Of course, this requires a rapport between engineering and the business that may be rare in practice.
As others have mentioned, enthusiastic engineers who feel like their enthusiasm is discouraged or shut down may leave for greener pastures. 20% time, internal tools that can tolerate some amount of churn/instability more readily than other projects, etc can all help provide outlets if they're not to be found in day-to-day work.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Interesting question. I don't have a short answer, only some observations.
Overall, I guess I'm in the camp of having user needs & business value be the guideposts for prioritization. I think I'd define business value more inclusively than many; paying down tech debt, for example, often provides business value by my standards. That said, my bar for some stereotypical enthusiasm projects ("let's rewrite our stable customer-facing backend in golang!!!11") is pretty high. They're fun to do for an engineer, and maybe address some benign but offensive code smells, but hard to justify the opportunity cost if they take time away from work that produces more direct value, especially if what they're fixing is "good enough" overall.
I think as we get more senior as engineers, we tend to do a better job of connecting things that we're enthusiastic about for our own reasons to business value/user needs/etc. For example, helping to justify a refactor or code cleanup by understanding the product roadmap, or identifying a business/user-facing gap that can be addressed with a new technology or product. Enthusiasm all by itself may not be given much of a role here, but arguably it doesn't need one; the business value it produces speaks for itself. Of course, this requires a rapport between engineering and the business that may be rare in practice.
As others have mentioned, enthusiastic engineers who feel like their enthusiasm is discouraged or shut down may leave for greener pastures. 20% time, internal tools that can tolerate some amount of churn/instability more readily than other projects, etc can all help provide outlets if they're not to be found in day-to-day work.