Another side effect of optimism that you didn't mention is that it makes it far easier to fall for bad tooling, libraries and patterns. I find most devs default approach to new stuff is wildly optimistic ("X will solve our problem perfectly", "X is popular so it must be good") and only positive outcomes are really considered ("We need to use X, Y and Z to avoid falling behind").
There's a lack of skepticism in general when it comes to tooling. Every one of those points is void of information without context because they each have a pessimistic counterpart that could be equally true. "X will introduce more technical debt than the problem it solves would", "X solves too broad of a problem and will bog us down with a huge API surface area we don't need", "X, Y and Z will provide negative value and we will miss an opportunity to outskill our competition", etc.
A lot of people, even senior staff, seem to forget that their job is about weighing pros and cons, or costs and benefits. In a lot of work places, mentioning the costs is seen as pessimistic or defeatist. You can see the imbalance by looking at the kind of language that's in vogue. I have a fair sort of a repertoire for accusing someone of being too skeptical of tooling ("reinventing the wheel", "why don't we just build it in assembly?", "10,000 people starred it on GitHub for a reason"), but I find it much harder to come up with opposing examples. The ones that are used aren't as widespread, and are more used as attributes of a codebase rather than as an assessment of someone's approach ("overengineered", "npm salad", "wrong abstractions" etc).
Comments
Another side effect of optimism that you didn't mention is that it makes it far easier to fall for bad tooling, libraries and patterns. I find most devs default approach to new stuff is wildly optimistic ("X will solve our problem perfectly", "X is popular so it must be good") and only positive outcomes are really considered ("We need to use X, Y and Z to avoid falling behind").
There's a lack of skepticism in general when it comes to tooling. Every one of those points is void of information without context because they each have a pessimistic counterpart that could be equally true. "X will introduce more technical debt than the problem it solves would", "X solves too broad of a problem and will bog us down with a huge API surface area we don't need", "X, Y and Z will provide negative value and we will miss an opportunity to outskill our competition", etc.
A lot of people, even senior staff, seem to forget that their job is about weighing pros and cons, or costs and benefits. In a lot of work places, mentioning the costs is seen as pessimistic or defeatist. You can see the imbalance by looking at the kind of language that's in vogue. I have a fair sort of a repertoire for accusing someone of being too skeptical of tooling ("reinventing the wheel", "why don't we just build it in assembly?", "10,000 people starred it on GitHub for a reason"), but I find it much harder to come up with opposing examples. The ones that are used aren't as widespread, and are more used as attributes of a codebase rather than as an assessment of someone's approach ("overengineered", "npm salad", "wrong abstractions" etc).