upvote
Totally agree with your framing here, but that is also what I fundamentally consider "good" code -- it's code that solves the problem that your customers/business needs without making it _harder_ to solve the next problem.

There are valid situations where the best code you can write is code you never look at and throw out the next month; there are equally valid situations where the best code is well thought through and reasoned abstractions for an area you expect to become core to the business in the near future.

reply
Thanks for the wording on your first sentence there. I've been trying to figure out a way to get that thought expressed succinctly.

I think with AI coding, what we call "good" code changes. Lots of abstractions really only exist to help load the context into the human brain so that they can solve the next problem. If an agent can just search and find all the places to make a change, or to duplicate code with small changes for the next problem, is that bad? Does is just feel bad because that's not what we're used to?

We use structured looping instead of gotos because that makes sense to us, but the compiler still turns it into jumps in assembly. If our interaction is now at a higher layer, do we need good "code" or do we just need good "architecture"?

I don't know, but it's just something I've been thinking about lately.

reply
This is a great point. I find myself in the middle, where I appreciate and look up to past coworkers who were way better than me at attention-to-detail, but I have a tendency to focus on delivering actual results quickly with maintainable and easy to read code. A lot of engineering teams go into their own world on adhering to best practices with no eye on inefficiencies in the process that causes days of delay because it makes them feel better. I definitely believe in shift-left (findings bugs early saves a lot more time than finding them in production). I believe in balancing fast delivery with quality/process.
reply
If you're writing CRUD, there's no excuse not to write it competently since you're not solving a new problem
reply
In my experience, those that can’t understand design in the small (code level) don’t understand it in the large (sw or systems architecture) either.

Doing the right thing for the customer is independent from good design and good code. It’s a problem of requirements and project management. This is an excuse some poor programmers use, that they can’t write good code, but at least they fulfilled the customer requirements :D

reply