Some ok takes here and some weird ones. I understand this is supposed to be a simply written article but I think “clean” and “messy” are way too reductive in this type of discussion without more context.
While I do think many good developers are passionate, it does not take passion to adhere to good practices. I don’t expect a bridge designer to be passionate about bridges, I expect them to follow best practices and a good bridge will follow.
Accurate estimates are only possible when tasks are well defined and well scoped. A bad developer will still give you an estimate on a nebulous task, a good developer will tell you there needs to be more investigation.
All code will have bugs, a good developer isn’t someone who never makes bugs. This is why testable code is important.
Oooh. I know this one. Testing their code rather than chucking it over the fence and crossing their fingers. Of course that’s management’s fault.
Yes it’s managements fault. Get asked to rapidly prototype a feature/service. 80% chance the lift is too big, won’t meet requirements, is literally impossible without a quantum computer and 5.2 gig watts of power, not wasting time writing tests for a prototype that will most likely be trashed. When the 20% case happens, scope writing tests, but the customer has already seen the MVP work and is clamoring to get it out now! I explain we need unit and integration testing, proper CI/CD, need to implement logging and Datadog integration, build in Okta integration and with testing, etc… you get the point, these are necessary and non-trivial task, but most don’t understand why when you just had a working prototype. Customer screams at your manager to deploy what you have now, bugs inevitably introduced, you spend time debugging issues that would have been caught with unit/integration testing or just a little more time refining your service, don’t have time to iterate or improve because of fixing bugs. The cycle continues…
Most of the “qualities of a bad developer” are imposed by their management.