[hehebbssjj]

I've worked with people like this - they're usually very dogmatic and won't defer to the status quo. This can be useful because they'll find low-hanging fruit like this that everyone else just accepts.

Long-term I find them annoying to work with because they seem to chase progressively higher cost/lower return changes. Especially in a startup context they're obsessed with being technically correct over building something people actually want. Green field stuff takes 10x as long as it needs to because they refuse to release something quickly and iterate.

[karmakaze]

I consider myself to be one of these people, but try to get along with most people--some people are just obstacles for no reason.

I took the time to reduce warnings from 10,000s to 10s slowly over the course of months in a legacy codebase that no one else thought could be done within reasonable time and effort.

I've worked with many people who overestimate the effort and underestimate the value of cleaning up code--for the sake of immediate velocity.

[choeger]

Long-term that startup mentality of "ship it once it seems to do something sensible" burns out your developers. So if you are into sustainable software development, you do as much static analysis as you can up front. And yes, that discounts languages like js or python for long-lived software projects.

If your software will be irrelevant after one or two years though, you can freely hack together whatever you want, I would say.

[hehebbssjj]

The kind of software I'm talking about should be thrown away after one or two years. Long-term you figure out what works and what the pain points are and you Ship of Theseus away all the bad shit.

> And yes, that discounts languages like js or python for long-lived software projects.

That's the kind of dogmatic statement that would be a red flag to me. The last company I was at was wildly successful using Ruby, JS and Python.