Comment by ThePhysicist | Hacker News Reader

Comment by ThePhysicist | Hacker News Reader

Parent Full thread

Maybe those engineers that don't care about making their solution _good_ are actually the good engineers, have you ever thought about that??? There are exceptions where quality really matters but most software shops build CRUD web apps where it's not really a good characteristic to obsess over the cleanest and most elegant details, instead you need to get the stuff the customer wants done!

I for one tend to care less about the minutiae of solutions implemented by AI as long as it gets the job done, I do care about architecture and design decisions and correctness and I have ways to steer and verify these when working with LLMs but I couldn't care less about it writing "good" code. Bad engineers also produce better results with AI at least when they're working in established frameworks, AI doesn't really need a lot of high level architecture input when designing or building a web app with a common stack, so as long as you're not working on something that's completely novel I don't think it will make a strong difference.

Maybe designers think the same way about the AI generated web designs I have Claude Code do for me but to be honest I don't care, I just know that before this tool existed it would have taken me weeks or months to come up with a good design and I would have to rely on prefabricated UI libraries and stuff like that or pay a designer tens of thousands of USD to make one for me, now I can get a (for me and my customers) perfectly acceptable and professional design within a few hours. So maybe I'm also a bad designer that amplifies my bad design taste 10x in my company, but the fact is the stuff ships and makes money and the customer is happy! And I can tell you customers or users don't give a shit about how good your code is, they only care if the software works and does what they want!

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.

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.

Using context always means there's less for something else, whether you're a human or a machine. Abstractions that localize reasoning and help load the context into a human brain are ideal for machines and humans alike.

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

If you're writing CRUD, there's no excuse not to write it competently since you're not solving a new problem

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.

I tend to find that this perspective comes from people working on relatively small or isolated projects.

On a large system, the customer being happy today isn’t enough. You need other engineers to be able to understand the system.

Have you ever been on call and been woken up in the middle of the night to fix a production incident in a system you didn’t write?

If everything you build is small, isolated and easy to replace (basically fire-and-forget), then yeah... who cares? Ship the ugly thing, get paid and move on.

If you’re going to be working on something for the next 5+ years, you should definitely spend some time thinking about what you’re doing.

Reply on news.ycombinator.com