Some tooling red flags
Some general traits in dev tooling that should be red flags for the probability of producing reliable and maintainable software
- Is the code easy to read ?
- Can you tell what the code is doing by taking a part of it in isolation, or do you need to read wider implementation to see whats going on ?
- Can you tell by looking at the code where it grabs resources, and where it releases them (from file handles to memory allocation) ?
- Can you tell by looking at a function where it returns, or are there hidden control flow mechanics to jump out early ?
- Does the tooling make it so easy to pile on 3rd party libs as dependencies, that its idiomatic to just pull in a dependency rather than do a trivial implementation inline ?
- Is the tooling backed by a massive marketing machine that makes bullshit promises along the lines that "now anyone can produce perfect code without any experience or skill"
- Are the in-company people that promote these tools obnoxious and humourless assholes with personality defects that make it impossible for them to ingest any critique at all ?
- Are these same people even aware of better alternative tools, or do they dismiss them out of hand, because reasons ?
I don't know of many tools that tick a lot of those boxes. ... but if I did start to see one that scored highly on the above list being pushed into use in an organisation, it would be easy to predict that the product would be s**t, the company culture would be s**t, and the people who had to maintain the pile of s**t would have no work life balance, leading to a collapse of the product in the near term.