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

361–370 of 699 posts

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

#361

Post by nunez »

wizzwizz4 wrote: post #8
dfxm12 wrote: post #6

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. Is anyone else seeing this in their orgs? I'm not...

It's not a new phenomenon. Time was, people would copy-paste from blog posts with the same effect.

Yeah, but being able to produce nuclear-sized 10k+ LOC PRs to open-source projects in minutes with relatively-zero effort definitely is. At least you had to use your brain to know which blog posts/SO answers to copypasta from.

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

#363

Post by vernrVingingIt »

repeekad wrote: post #204
rcbdev wrote: post #154

Earlier quoted context omitted.

This sounds like the exact kind of profound pseudo-enlightenment that one gets from psychedelics. Of course, it's all electrons in the end. Trying to create a secure, reliable and scalable system that enables many people to work on one code base, share their code around with others and at the end of the day coordinate this dance of electrons across multiple computers, that's where all of these 'useless' layers of abs…

> pseudo-enlightenment one gets from psychedelics I like that, I’ve also heard it referred to as “unearned wisdom”

You all really believe PhDs and principle hardware engineers at Samsung, nVidia, etc have not worked around any abstract problem you all can come up with?

We need a layer of abstraction not endless layers.

Nothing says unearned wisdom than script kiddies who intentionally had money thrown at them to reinforce belief their mastery of RoR CRUD app dev is genius beyond all comprehension. Zomg you know Linux admin? Here's $10 million dollars!

This thread is nothing but appeals to banal social conservatism. The disruptors on the verge of being the disrupted lashing out; wait, I was the job killer! Now you say my job is dead! So unfair!

Us hardware engineers been having a good laugh at SWEs easily manipulated the last 20 years by Wall Street hype of copy-paste SaaS products constantly reimplemented in the latest JS framework.

Throwing money at you all was intentional manipulation of primate biology. Juice your egos, get you to fall in line with desired agency control goals of the political and old money cohort.

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

#364

Post by muzzio »

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…

Reviewing your own PR is underrated. I do this with most of my meaningful PRs, where I usually give a summary of what/why I'm doing things in the description field, and then reread my code and call out anything I'm unsure of, or explain why something is weird, or alternatives I considered, or anything that I would catch reviewing someone else's PR.

It makes it doubly annoying though whenever I go digging in `git blame` to find a commit with a terrible title, no description and an "LGTM" approval though.

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

#365

Post by vlowther »

kridsdale3 wrote: post #244
vernrVingingIt wrote: post #174

Earlier quoted context omitted.

Try almost 30 years in electrical engineering. I know exactly what those layers of abstraction are used for. Why so many? Jobs making layers of abstraction. But all of them are dev friendly means of modeling memory states for the CPU to watch and transform just so. They can all be compressed into a generic and generalized set of mathematical functions ridding ourselves of the various parser rules to manage each bespo…

Okay. Go write an operating system and suite of apps with global memory and no protections. Why are we wasting so much time on abstractions like processes and objects? Just let let everyone read and write from the giant turing machine.

DOS, early Windows, and early MacOS worked more or less exactly that way. Somehow, we all survived.

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

#366

Post by anthonypasq »

layer8 wrote: post #138

I’d go further and say while testing is necessary, it is not sufficient. You have to understand the code and convince yourself that it is logically correct under all relevant circumstances, by reasoning over the code. Testing only “proves” correctness for the specific state, environment, configuration, and inputs the code was tested with. In practice that only tests a tiny portion of possible circumstances, and omits…

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

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

#367

Post by gorjusborg »

Your actual job is to produce positive outcomes for your stakeholders. Code can be part of that, but doesn't have to be.

If you are dumping AI slop on your team to sort through, you are creating drag on the entire team's efforts toward those positive outcomes.

As someone getting dumped upon, you probably should make the decision (in line with the objective to producing positive outcomes) to not waste your time weeding through that stuff.

Review everything else, make it clear that the mess is not reviewable, and communicate that upward if needed.

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

#368

Post by xnx »

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.

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

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

#370

Post by [deleted] »

hostyle wrote: post #338
alphazard wrote: post #320

Earlier quoted context omitted.

This exactly. You have to be honest about why you are building something. If the answer is that you actually want to use it, then yes, quality and maintainability are important. It might even be a good idea to use no AI whatsoever. But if you are building it because doing so is in the long chain of cause and effect that leads to you being fed and having shelter, then you should minimize the amount of your time that i…

Most people spend maybe 1/4 of their working age life at a job working for someone else. Why would you deliberately sabotage that by checking out mentally and waste all that time on sub-standard work? How do you expect to earn a promotion? You can produce good code at work and even better code at home for yourself. Deliberately producing slop at work will not help anyone.

[deleted]
Post reply on HN