Completely agree.
It’s all about trade-offs. Which many developers don’t - or just refuse to - understand.
My point was that without some context this kind of conversations - about good and bad code and good and bad coders - are not very useful.
It’s all about trade-offs. Which many developers don’t - or just refuse to - understand.
My point was that without some context this kind of conversations - about good and bad code and good and bad coders - are not very useful.
Personally I believe good code is an reliable, maintainable, transparent and well designed solution for a problem (or a set of problems). And that means for a small problem aome ad hoc script can be good, while for a big complicated set of problems an elaborate well coded project with a build system can be good code.
But what I believe is that there are ideal solutions from an engineering standpoint, and there are ideal solutions from an business standpoint. And those sometimes don't align with each other. E.g. when you solve a core problem that should really be dealt with properly with a quick fix that might be a cheap way to reach the short term business goals, but it could shape a lot of engineering decisions in the future in a bad way and maybe even become a business problem in the long term.