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

Your job is to deliver code you have proven to work

simonwillison.net

Post reply on HN
Print view View original

431–440 of 699 posts

Re: Your job is to deliver code you have proven to work

#431

Post by snarf21 »

endorphine wrote: post #104

> there’s one depressing anecdote that I keep on seeing: the junior engineer, empowered by some class of LLM tool, who deposits giant, untested PRs on their coworkers—or open source maintainers—and expects the “code review” process to handle the rest. It's even worse than that: non -junior devs are doing it as well.

Yeah, it is way worse than that. In the past two days, I have had two separate non-engineer team members ask some AI agent how some mobile bug should be fixed and posted the AI response in the ticket as the main content and context and acceptance criteria. I then had to waste my time reading this crap (because this is really all that is in the ticket) before starting my own efforts to understand what the real ask or change in behavior needed is.

Re: Your job is to deliver code you have proven to work

#432

Post by TexanFeller »

endorphine wrote: post #104

> there’s one depressing anecdote that I keep on seeing: the junior engineer, empowered by some class of LLM tool, who deposits giant, untested PRs on their coworkers—or open source maintainers—and expects the “code review” process to handle the rest. It's even worse than that: non -junior devs are doing it as well.

Even worse for me, some of my coworkers were doing that _before_ coding LLMs were a thing. Now LLMs are allowing them to create MRs with untested nonsense even faster which feels like a DDOS attack on my productivity.

Re: Your job is to deliver code you have proven to work

#433

Post by alexpotato »

cesarb wrote: post #373
rootusrootus wrote: post #253

Earlier quoted context omitted.

It could be a death-by-a-thousand-cuts situation and we don't have enough context. My company has spent the last few years really going 1000% on the capitalization of software expenses, and now we have to include a whole slew of unrelated attributes in every last Jira ticket. Then the "engineering team" (there is only one of these, somehow, in a 5K employee company) decrees all sorts of requirements about how we test…

> But putting the ticket number in the commit ... that's basically automatic, I don't know why it should be that big a concern. The branch itself gets created with the ticket number and everything follows from that, there's no extra effort. That poster said "attach a JIRA Ticket to the PR", so in their case, it's not that automatic.

If you are using the Atlassian Git clone then just putting the JIRA ticket in the title automagically links the PR to the ticket.

Re: Your job is to deliver code you have proven to work

#434

Post by theshrike79 »

rootusrootus wrote: post #249
analog31 wrote: post #208

Earlier quoted context omitted.

Where are the junior devs while their code is being reviewed? I'm not a software developer, but I'd be loath to review someone's work unless they have enough skin in the game to be present for the review.

As someone else mentioned, the process is async. But I achieve a similar effect by requiring my team to review their own PRs before they expect a senior developer to review them and approve for merging. That solves some of the problem with people thinking it's okay to fire off a huge AI slop PR and make it the reviewer's responsibility to see how much the LLM hallucinated. No, you have to look at yourself first, beca…

We have an AI doing the first pass PR review using company standards as a prompt.

It catches the worst slop in the first pass easily, as well as typos etc.

Re: Your job is to deliver code you have proven to work

#435

Post by theshrike79 »

lowkeyokay wrote: post #157
endorphine wrote: post #104

> there’s one depressing anecdote that I keep on seeing: the junior engineer, empowered by some class of LLM tool, who deposits giant, untested PRs on their coworkers—or open source maintainers—and expects the “code review” process to handle the rest. It's even worse than that: non -junior devs are doing it as well.

In the company I’m at this is beginning to happen. PM’s want to “prototype” new features and expect the engineers to finish up the work. With the expectation that it ‘just needs some polishing’. What would be your recommendation on how to handle this constructively? Flat out rejecting LLM as a prototyping tool is not an option.

"You can't polish a turd" =)

Re: Your job is to deliver code you have proven to work

#436

Post by BadCookie »

theshrike79 wrote: post #395
xnx wrote: post #368

Earlier quoted context omitted.

Unfortunately, junior behavior exists in many with "senior" titles. Especially since "senior" is often given to those 2 years out of school.

A coworker had this anecdote decades ago. There's a difference between 10 years of experience and 1 year of experience 10 times. YOE isn't always a measurement of quality, you can work the same dead-end coding job for 10 years and never get more than "1 year" of actual experience.

Maybe, but the typical person I have worked with in this industry is too smart to do something for 10 years and not learn much during that time.

I am afraid that this “1 year of experience 10 times” mantra gets trotted out to justify ageism more often than not.

Re: Your job is to deliver code you have proven to work

#437

Post by hinkley »

endorphine wrote: post #104

> there’s one depressing anecdote that I keep on seeing: the junior engineer, empowered by some class of LLM tool, who deposits giant, untested PRs on their coworkers—or open source maintainers—and expects the “code review” process to handle the rest. It's even worse than that: non -junior devs are doing it as well.

There’s a PR on a project I contribute to that is as bad/big as some PRs by problematic coworkers. I’m not saying it’s AI work, but I’m wondering.

Re: Your job is to deliver code you have proven to work

#438

Post by koinedad »

This is very helpful for a team and even though it takes a little time it actually speeds things up in the long run. Using PR templates can help. A general description of the problem including a screenshot or video go a long way.

I remember when I was working at a startup and a new engineer merged his code and it totally broke the service. I asked him if he ran his code locally first and he stared at me speechless.

Running the code locally is the easiest way to eliminate a whole series of silly bugs.

Like mentioned in the article adding a test and then reverting your change to make sure the test fails is really important, especially with LLMs writing tests. They are great at making things look like they work but completely don’t.

Re: Your job is to deliver code you have proven to work

#439

Post by SoftTalker »

lokar wrote: post #421
CodeMage wrote: post #402

Earlier quoted context omitted.

What makes this whole thing worse is the concept of "non-terminal" levels, i.e. levels that you're not allowed to stay at indefinitely, which means that you must either get promoted or fired. I can understand not wanting to let people stay in a junior position forever, but I've seen this taken to a ridiculous extreme, where the ladder starts at a junior level, then goes through intermediate and senior to settle on st…

Yeah, the terminal level, whatever the title (they are just words) need to be the point at which you can handle moderately complex (multi-week) tasks with no supervision. And honestly, this will depend on the environment and kind of work being done.

If that's what you're looking for you can find it in academia. Universities have no problem paying people to stay around forever without promotion.

Of course the pay won't be great, but the benefits are decent, PTO is usually excellent, and the work environment usually very low stress.

Re: Your job is to deliver code you have proven to work

#440

Post by otterley »

sunsetMurk wrote: post #377
anthonypasq wrote: post #366

Earlier quoted context omitted.

if your tests cover the acceptance criteria as defined in the ticket, why is all htat other stuff necessary?

Acceptance criteria are often buggy themselves, and require more context to interpret and develop a solution.

If you don't have sufficiently detailed acceptance criteria, how can anyone be expected to write code to satisfy them?

That's why you have to start with specifications. See, e.g., https://martinfowler.com/articles/exploring-gen-ai/sdd-3-too...

Post reply on HN