Hacker News Reader

Comment by hinkley | Hacker News Reader

I probably spend 5-10% of my time on average, and more in bad situations, going through code trying to purge past mistakes. Part of why this takes so much time is that there’s always some special idiot who is writing new code in the bad way and won’t stop.

But they are typically lazy and copy and paste that code from existing places. If you can remove the last copy from the code, they will finally stop.

And now that special idiot is a piece of software that never sleeps, never eats, and never forgets? What could go wrong?

View on HN

I suppose I'm excited for the opposite reason:

It's much easier to get one model to change its behavior, than 1000 software engineers.

The whinging we hear is firmly anchored to the timeline on which humans improve, and the extent to which they improve.

What I’ll decline: Using LLMs to write more code

What I’ll buy: Using LLMs to write less code (maybe even delete a lot)

this

…or to do annoying refactorings!

I would not trust an non-deterministic system to do a refactor on a production system -- I would have to review the whole thing. Isn't it quicker to just do it myself with my regular deterministic tools?

I’m going to start calling all of my co-workers non-deterministic systems.

The difference is that your co-workers sign on their own work -- if it breaks, it's their responsibility. If you commit some code, and it breaks, it's on you, no matter which fancy tool you used to write it.

Generally if you write some code and it breaks, your whole team has some fault in its release mechanism, and that's group owned

I would absolutely trust a non-deterministic system to refactor a production system... if that system had a robust set of unit tests and I was willing to commit to reviewing the proposed changes.

Without thorough automated tests I wouldn't trust myself to be able to effectively review the code.

Some refactoring is at the block level, and so would generally not affect unit tests. But most refactoring is at a functional level, so only the integration and functional tests are ever safe, and even then sometimes not.

Shower thought: use AI to understand and evolve compact/clever code.

People write a lot of code because the alternatives usually have their own set of problems. Compact/clever code is hard to understand, debug and evolve. "Write only code" is only half a joke.

Languages like APL and K have some appeal due to their expressiveness but they are understandably rejected by most engineers because it's really hard to build a sustainable large scale system with many engineers

These are exactly my thoughts. This just sounds like a bot to regurgitate the same mistakes over and over again. I'm struggling to understand who at Google actually thought this was a good idea? Or is this just a novelty research project with no practical use?

"Did you say this is using an LLM? SHIP IT!!" is my guess.

Googler, opinions merely my own:

Google's monorepo and tooling for changes across the entire repo make it possible and common to fix entire classes of mistakes at once. Bad patterns lingering in copy/paste is not an issue in practice due to a combination of such changes and linter presubmits that identify and flag any recurrence in the future.

What I want is to write less code. I'd like automated analysis help with finding better more concise ways to render the logic. More code != better.

>More code != better.

>more concise ways to render the logic

This isn't better either.

Edit before the shitstorm:

This isn't necessarily better either.

When I'm looking at code, I don't want to read War and Peace.

But I also don't want to read Haiku either. All the burden is on the reader, and there are many readers.

Usually what I want is a short story. Long enough to be accurate, short enough to lose distracting and unnecessary information.

Not talking to you, just on the topic of DRY fundamentalism

I find people creating these DRY abstractions with a lot of knobs to be strange. End up with dryWithRain, drySpicy, dryStrict, dryTurbo

then the abstraction is a maze of confusion

When I find one bug I assume it is likely repeated all over the code and I search it out. I have been burned enough times to not consider it a must.

There's always a subtle difference in one of the 3 implementations. Less subtle when it's 5+. That's where the time adds up.

I also found during these kinds of sweeps large copy and pastes of code. It really lowered my opinion of those working on the same project.

It's taught me to worry about people who happily volunteer for difficult tasks. I used to think they were troopers, now I see more and more of them as having a high pain tolerance, and I don't mean that as a compliment.

Pain in information and they throw away a lot. It's a form of job security, and not a particularly benign kind.

Our job is to replace painful processes with code. If you can't do that you aren't fulfilling the basic premise of your profession.

Wisdom of the crowd is the hypothesis made here I guess.

"Think about how dumb the average person is, and then realize that half of them are dumber than that" -George Carlin

The wisdom of crowds, if it applies to teams, is in communication. I talk you out of cutting corners, and sometimes you talk me out of it. There's no communication in a training corpus. You just get the average of all of the code that wasn't so horrible that people stopped what they were doing to fix it. Which is to say, half of the code is barely tolerable.

Reply on news.ycombinator.com