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

681–690 of 699 posts

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

#681

Post by nothrabannosir »

necovek wrote: post #640
nothrabannosir wrote: post #612

Earlier quoted context omitted.

This is a hill I’m going to die on, but I find 9/10 times people use the pr description for what should have been comments. “Git blame” and following a link to a pr is inferior ux to source code comments. The North Star of pr review is zero comment approvals. Comments should not be answered in line, but by pushing updates to the code. The next reader otherwise will have the exact same question and they won’t have the…

But there are really two types of things you need to describe in a change request: - What and why needs changing - What the code does after the change One should really try hard to keep the first one answered in a change request description, or comments in the tool for code reviews. Don't you love running into comments in the code of the type "// This performs better than sorting-after-load as the service offers buil…

Yes totally agree, I now see a crucial auto correct typo in my original comment wherei was trying to say the same but failed xD. “sod” = “diff”.

100% agree with your comment.

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

#682

Post by mh- »

simonw wrote: post #505
mh- wrote: post #498

Earlier quoted context omitted.

Please just use text for that. PR descriptions on GitHub sufficiently support formatting.

Text isn't good for things like "tighten up the spacing in this dialog".

Of course not. Perhaps you misread the comment I was replying to?

Quoting from it:

> I will take a screenshot of a new type in my IDE and put a red box around it.

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

#683

Post by throw1235435 »

SunshineTheCat wrote: post #247

I know this won't be popular, however, I think the idea of differentiating a "real developer" from one who relies mostly, or even solely on an LLM is coming to an end. Right now, I fully agree relying wholly upon an LLM and failing to test it is very irresponsible. LLMs do make mistakes. They do a sloppy job at times. But give it a year. Two years. five years. It seems unreasonable to assume they will hit a plateau t…

You will get downvoted but I unfortunately agree with you; also as a SWE of similar tenure. People assume there's other things to jump to and yes in the short term there may be. But the industry already has those things on its roadmap to disrupt (i.e. generate more economic useful work).

For better or worse the software career is wounded, and the AI wolves can smell blood. Its low hanging fruit that they understand and in its disruption can make a lot of money.

As an industry is dying of disruption the leftover money is made in disrupting it first, this will speed up engineering efforts to kill the profession like rats in a sinking ship. Corporate stakeholders will also be the first to spend big on anything that does; they in my experience prefer communicators, and people accountable, not people who deliver.

It was a good ride. I could never of imagined this trajectory 3 years ago.

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

#684

Post by throw1235435 »

xmodem wrote: post #283
SunshineTheCat wrote: post #247

I know this won't be popular, however, I think the idea of differentiating a "real developer" from one who relies mostly, or even solely on an LLM is coming to an end. Right now, I fully agree relying wholly upon an LLM and failing to test it is very irresponsible. LLMs do make mistakes. They do a sloppy job at times. But give it a year. Two years. five years. It seems unreasonable to assume they will hit a plateau t…

What's your point, though? Let's assume your hypothesis and 5 years from now everyone has access to an LLM that's as good as a typical staff engineer. Is it now acceptable for a junior engineer to submit LLM-generated PRs without having tested them? > It was thought impossible for a computer to reach the point of being able to beat a grandmaster at chess. This is oft-cited but it takes only some cursory research to s…

Its hard to imagine now but the code won't matter. We will have other methods of validating the product I think; like before tech. There are many ways to validate something; this is an easier problem than creation (which these AI models are somewhat solving right now)

All very demoralizing but I can see the trend. In the end all "creative" parts of the job will disappear; AI gets to do the fun stuff.

We invented something that devalues the human craft and contribution -> if you weren't skilled in that and/or saw it as a barrier you win and are excited by this (CEO types, sales/ideas people, influencers, etc). If you put the hard yards in and did the work to build hard skills and built product; you lose.

Be very clear: AI devalues intelligence and puts more value on what is still scarce (political capital, connections, nepotism, physical work, etc). It mostly destroys meritocracy.

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

#685

Post by sodapopcan »

necovek wrote: post #665
sodapopcan wrote: post #631

Earlier quoted context omitted.

Again, if you rotate pairs daily this doesn't happen. You could argue that creates a "team bias" but I call that cohesion.

Can you elaborate? Is this pairing on small tasks that get done in (less than) a day? Or do you also have longer-running implementations (a few days, a week, or maybe even more?) where you rotate the people who are on it (so one task might have had 5 or 10 people on it during the implementation)? If the latter, that sounds very curious and I'd love to learn more about how is that working, how do people feel about it,…

I do have a blog post about this sitting around along with all my other mostly completed posts. Finishing this one would be great as it's a topic I'm very passionate about!

Our stories were broken up to take worst-case-scenario 5 days, the ideal was 1-3, of course. Maybe would be multi-day stories so yes, if something ended up taking 5 days it was possible the whole team could have touched it (our team was only 6 devs so never more than 6).

In short, there are the usual hurdles with pairing, the first one being that it takes some time to catch your stride but once you do, things start flying. It is of course not perfect and you run into scenarios where something takes longer because as a new person joins the ticket, they want to tweak the implementation, and it can get pulled in different directions the longer it takes. But this also gets better the longer you keep at it.

There are lots of pros AFAIC but a couple I like: you develop shared ownership of the codebase (as well as a shared style which I think is neat), ie, every part of the app had at least a few people with lots of context so there was never any, "Oh, Alice knows the most about that part of so let's wait until she's back to fix it" kinda thing. There is no "junior work." When a junior joins the team they are always pairing so they ramp up really quickly (ideally they always drive for the first several months so they actually learn).

Another downside would be it's bad for resume-driven-development. You don't "own" as many projects so you have to get creative when you're asked about big projects you've led recently, especially if you're happily in an IC role.

And also yes, if there is a super small task that is too small to pair on, we'd have a reviewer, but often these were like literal one-line config changes.

We'd also have an independent reviewer whenever migrations were involved or anything risky task that needed to be run.

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

#686

Post by tremon »

jmpeax wrote: post #623
tremon wrote: post #548

Earlier quoted context omitted.

On classic big waterfall projects, you can find actual architects. Those are the ones drafting interfaces and delineating components/teams before the first source file is even committed.

Actual architects design buildings.

I'm sorry. My fault for engaging you, I guess.

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

#687

Post by KronisLV »

stephen_cagle wrote: post #429
lokar wrote: post #420

Earlier quoted context omitted.

You want the Dr who has done the operation 10 times, and learned something each time, and incorporated that into their future efforts. You probably don’t want a Dr who will do their 11th surgery on you exactly the way they did the first. This is what that saying is about

Fair enough. I guess I am making a bit of a straw-man in that I feel I just don't buy the idea that doing the same thing 10 times over the course of 10 years is somehow worse than doing different things over the course of 10 years. They are signals, and depending on what we are attempting, they just mean different expected outcomes. One isn't necessarily worse than another, but in this case it seems to be implying it…

> I just don't buy the idea that doing the same thing 10 times over the course of 10 years is somehow worse than doing different things over the course of 10 years.

I always read it as making the same mistakes as you initially did and either failing to learn from them or not even trying to improve. Maybe you haven’t even explored enough approaches to see what actually works and what doesn’t and most importantly, in which circumstances.

For example, someone might do CI/CD with manually created pipelines in Jenkins (the web UI variety) with stuff like JDK configured directly on the runner nodes. They might never have written a Jenkinsfile, or tried out Docker for builds and therefore are slow and have to deal with brittle plugins and environment configuration. They might also be unaware of how GitHub Actions could benefit them, or the more focused approach of GitLab CI or even how nice Woodpecker CI can be, especially for simpler setups.

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

#688

Post by wizzwizz4 »

fragmede wrote: post #673
wizzwizz4 wrote: post #663

Earlier quoted context omitted.

> so if it doesn't work then I have to figure out why. But it's built on top of things that are understood. If it doesn't work, then either: • You didn't understand the problem fully, so the approach you were using is wrong. • You didn't understand the language (library, etc) correctly, so the computer didn't grasp your meaning. • The code you wrote isn't the code you intended to write. This is a much more tractable…

Just like there are some easy "tells" with LLM generated English, vibecode has a certain smell to it. Parallel variables that do the same thing is probably the most common one I've seen in the hundreds of thousands of lines of vibecode I've generated and then reviewed (and fixed) by now. That's the philosophical Chinese room thought experiment though. It's a computer. Some sand that we melted into a special shape. Ca…

> but to claim that some because some artificial intelligence generated the code makes it incomprehensible to humans seems unsupported

That's not my claim. My claim is that AI-generated code is misleading to people familiar with human-written code. If you've grown up on AI-generated code, I wouldn't expect you to have this problem, much like how chess newbies don't find impossible board states much harder to process than possible ones.

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

#689

Post by necovek »

sodapopcan wrote: post #685
necovek wrote: post #665

Earlier quoted context omitted.

Can you elaborate? Is this pairing on small tasks that get done in (less than) a day? Or do you also have longer-running implementations (a few days, a week, or maybe even more?) where you rotate the people who are on it (so one task might have had 5 or 10 people on it during the implementation)? If the latter, that sounds very curious and I'd love to learn more about how is that working, how do people feel about it,…

I do have a blog post about this sitting around along with all my other mostly completed posts. Finishing this one would be great as it's a topic I'm very passionate about! Our stories were broken up to take worst-case-scenario 5 days, the ideal was 1-3, of course. Maybe would be multi-day stories so yes, if something ended up taking 5 days it was possible the whole team could have touched it (our team was only 6 dev…

Once you do publish the write-up (here's some encouragement!), hopefully it catches the attention of others so I don't miss it either :)

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

#690

Post by [deleted] »

wizzwizz4 wrote: post #672
lcnPylGDnU4H9OF wrote: post #667

Earlier quoted context omitted.

> "nobody knows what the code means, or has a mental model for how it's supposed to operate" > Believing you know how LLM-generated code works, and why it works, is not the same as that actually being the case This is a strawman argument which I'm not really interested to engage. You can assume competence. (In a scenario where one doesn't make these mistakes, what's left in your argument? It is a sufficiently strong…

I am assuming competence. Competent people make these mistakes. If "assume competence" means "assume that people do not make the mistakes they are observed to make", then why write tests? Wherefore bounds checking? Pilots are competent, so pre-flight checklists are a waste of time. Your doctor's competent: why seek a second opinion? Being mindful involves compensating for these things. It's possible that you're just…

[deleted]
Post reply on HN