Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Write code like a human will maintain it

unstack.io

Post reply on HN
Print view View original

151–160 of 325 posts

Re: Write code like a human will maintain it

#151

Post by saghm »

geraldwhen wrote: post #106
saghm wrote: post #52

Earlier quoted context omitted.

How did you know you're not stuck at a local optimum where the AI could iterate even faster if you enforced higher quality on what it produced? To make up some hypothetical numbers in order to illustrate with math: if you ship bugfixes 10x faster but then have 11x more bugs you need to fix, that's not a net improvement. Even if it's only 5x more bugs, maybe you could reduce that to 2x if you changed how you worked to…

It’s a new form of development. The thing that the author didn’t state is that to work the code base at all, you must also use these tools and workflows. Manual edits literally aren’t possible. You can’t grok the code growth and the new patterns fast enough to be productive. This does work. I’ve seen it in real products. Nobody has a real mental model of the code flows. But with enough money in Claude credits it does…

I don't understand what anything you're saying has to do with what I said. My claim is that "groking the code" is not a binary, and you can balance between full vibe mode without ever reading it and requiring that you understand every single line, with the corollary that it's at least plausible that being on the far end of the spectrum where you never read it isn't safe to assume is the global optimum, and your rebuttal seems to be "well it's not the global minimum".

Re: Write code like a human will maintain it

#152

Post by willturman »

throwaw12 wrote: post #62
cadamsdotcom wrote: post #29

Write yourself a /review command. That is an empty markdown file at `.claude/commands/review.md`. In it, put a checklist of things the agent should look for. When you’re ready to have your agent review the code, type `/review`. The checklist will be examined and it’ll plan out some findings to ask you if you want them fixed. Mine starts with “Enter plan mode. Examine the differences on this branch vs. main. Consider:…

Can you share your list? I am curious what does it contain, for me a lot of times its a back and forth with agent until it "looks good to my eyes and taste", but haven't written any such list yet, because it is context dependant, in some projects I forgive minor issues, or allow magical numbers, but in other projects I force agent to use constants with meaningful names `SECONDS_IN_A_DAY = 24 * 60 * 60`

It is interesting that the output of code is associated with sight and taste, while the quality of the code itself is associated with smell.

https://en.wikipedia.org/wiki/Code_smell

*edit: that wikipedia page ^ itself is a pretty answer to your request for a list of things to avoid when writing maintainable code.

Re: Write code like a human will maintain it

#153

Post by hoppp »

danielbln wrote: post #147
hoppp wrote: post #139

Earlier quoted context omitted.

One reason to write by hand is to have intellectual property, since it was ruled that AI generated code is in the public domain by default, so licensing is hard. Another thing is competitive edge, if you use claude and your competitors use claude then nothing really gives you an edge. AI is a commodity, not competitive edge. The competitive pressure should drive human work because it's unique.

The competitive edge lies with the higher attraction layer, not the nitty gritty implementation detail (any more). Is that still software programming? The human work lies in the what and why and in broad strokes how

That's not always the case imho. Think about advances in running inference, any innovation will happen in the details. Higher layer can stack gpu's but the implementation can still be improved.

Often small technical changes like "making a service 5% faster" are worth millions for large companies. That's all implementation.

Re: Write code like a human will maintain it

#154

Post by wrs »

TimTheTinker wrote: post #71
alexpotato wrote: post #3

There is an old quote: "Add comments to your code under the assumption that the next person to maintain it is a homicidal maniac who knows where you live"

Right now the comments that upset me the most are LLM TMI-style comments that break encapsulation by talking about the behavior of specific current callers of a function right above the function definition . I recently reacted angrily in a PR review comment after encountering one for the umpteenth time... that caught me off guard. I didn't know I was capable of that.

Claude Code and Opus 4.8 love to describe changes in comments (perhaps because that’s what’s on its “mind” at the time), like “this used to do A but that did a bad thing so now it does B”. I’ve almost convinced it that changes go in the commit message, not the comments.

Re: Write code like a human will maintain it

#155

Post by xhrpost »

cadamsdotcom wrote: post #29

Write yourself a /review command. That is an empty markdown file at `.claude/commands/review.md`. In it, put a checklist of things the agent should look for. When you’re ready to have your agent review the code, type `/review`. The checklist will be examined and it’ll plan out some findings to ask you if you want them fixed. Mine starts with “Enter plan mode. Examine the differences on this branch vs. main. Consider:…

> Any time I notice something in code review and have to get the agent to fix it.. I throw it on the list! My list is like 200 items now.

This is a gripe I've had with AI tools for a while now. Though it's gotten somewhat better in time, but we don't really know what to expect from the tool in terms of quality. Ex. I'd expect a human engineer to probably not use a brand new assertion library for a new test when there are 200 tests using an existing one. But Claude has done this to me multiple times. So I have to add yet another item to the list, like you have, and tell it to look for testing conventions before writing. But, there is plenty we don't have to tell it, like what a function is or a test should probably cover the change in the diff. But we don't really have a list of what things are on each side so we're just left to sort of hunt and peck to build a viable solution.

Re: Write code like a human will maintain it

#156

Post by WillAdams »

SoftTalker wrote: post #100
alexpotato wrote: post #3

There is an old quote: "Add comments to your code under the assumption that the next person to maintain it is a homicidal maniac who knows where you live"

Used to work with a guy who would frequently say "a comment is an apology" i.e. the comment is there because the code itself is not clear. That can be the case, but I generally find more comments better than fewer, especially if they relate the code to actual business or functional requirements and don't just restate what the code is doing. Years ago I would often write comments first. I.e. start with describing the…

I really wish Literate Programming had caught on.

The big problem is folks misunderstood it as documentation (arguably plain.tex should have also been the sourcecode for _The TeXbook_ and that it wasn't is a big part of this) --- it could be, but usually that's better as a separate text/chapter....

I've been trying to collect books on Literate Program/notable Literate Programs published as books:

https://www.goodreads.com/review/list/21394355-william-adams...

and I will note that my own programming took a quantum leap forward when I purchased and read:

https://www.goodreads.com/book/show/39996759-a-philosophy-of...

and applied its principles one chapter at a time to a project which I was able (w/ a bit of help) to get into Literate Programming form:

https://github.com/WillAdams/gcodepreview/blob/main/literati...

Re: Write code like a human will maintain it

#157

Post by danielbln »

hoppp wrote: post #153
danielbln wrote: post #147

Earlier quoted context omitted.

The competitive edge lies with the higher attraction layer, not the nitty gritty implementation detail (any more). Is that still software programming? The human work lies in the what and why and in broad strokes how

That's not always the case imho. Think about advances in running inference, any innovation will happen in the details. Higher layer can stack gpu's but the implementation can still be improved. Often small technical changes like "making a service 5% faster" are worth millions for large companies. That's all implementation.

I don't see why a strong model wouldn't significantly outperform any human in this sort of low level optimization work. We don't hand optimize assembly either.

Re: Write code like a human will maintain it

#158

Post by WillAdams »

baptou12 wrote: post #122

I agree, but “write code like a human will maintain it” can also be limiting: if LLMs reduce the cost of maintaining more explicit or verbose code, we should use that to raise the standard, not preserve compromises made for human convenience.

However, an argument can be made that such Literate Programming code can be easier/better for an LLM to work with:

https://news.ycombinator.com/item?id=47300747

Re: Write code like a human will maintain it

#159

Post by yCombLinks »

vorticalbox wrote: post #148

> There's a much cleaner way to do this - a shared helper disagree, then you end up with something this this function checkAll(target, conditions) { return Object.entries(conditions).every(([path, expected]) => { const value = path.split('.').reduce((o, k) => o?.[k], target); return typeof expected === 'function' ? expected(value, target) : value === expected; }); } and const ok = checkAll({ user, account }, { 'user.…

No, you've created a generic condition checker, which is where all of your complexity comes from. Further, you've left the actual check to be duped in all callers.

Re: Write code like a human will maintain it

#160

Post by sheept »

fphilipe wrote: post #102
TimTheTinker wrote: post #71

Earlier quoted context omitted.

Right now the comments that upset me the most are LLM TMI-style comments that break encapsulation by talking about the behavior of specific current callers of a function right above the function definition . I recently reacted angrily in a PR review comment after encountering one for the umpteenth time... that caught me off guard. I didn't know I was capable of that.

This is what has been frustrating me most lately. Even though I have a rule in my global CLAUDE.md that says: > Only write comments to explain the why when it is not obvious from the code (rationale, gotchas, constraints). Do not comment on the what — well-named code already says it. Do not comment on how a framework works. It still keeps adding these bad comments. When I then ask it to review the comments based on m…

My hypothesis is that Claude is inclined to write so many comments as a way of doing additional thinking
Post reply on HN