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

501–510 of 699 posts

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

#501

Post by abustamam »

xnx wrote: post #368
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.

I've job hopped a bit. I've gone from junior to senior to lead to mid-level to staff to senior. I have ten years experience.

My career trajectory is wild. At this rate I'll be CTO soon, then back to mid-level.

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

#502

Post by snarf21 »

teaearlgraycold wrote: post #492
snarf21 wrote: post #431

Earlier quoted context omitted.

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…

Your manager should be on their ass for wasting your time.

Worse yet, these were done by the managers of the Marketing team and the Mapping team. Plus, these are high profile issues that (somehow) required getting the CEO involved too! (Obviously there is a lot of dysfunction in our organization, lol.)

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

#503

Post by keeda »

The way I would phrase it is: software engineering is the craft of delivering the right code at the right time, where "right code" means it can be trusted to do the "right thing."

A bit clunky, but I think that can be scaled from individual lines of code to features or entire systems, whatever you are responsible for delivering, and encompasses all the processes that go around figuring what code is to be actually written and making sure it does what it's supposed to.

Trust and accountability are absolutely a critical aspect of software engineering and the code we deliver. Somehow that is missed in all the discussions around AI-based coding.

The whole phenomenon of AI "workslop" is not a problem with AI, it's a problem with lack of accountability. Ironically, blaming workslop on AI rather than organizational dysfunction is yet another instance of shirking accountability!

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

#504

Post by marwamc »

ok_dad wrote: post #388
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.

A senior dev should be mentoring and talking to a junior dev about a task well before it hits the review stage. You should discuss each task with them on a high level before assigning it, so they understand the task and its requirements first, then the review is more of a formality because you were involved at each step.

Also communal RFCs, RFPs, Roadmapping, Architecture/Design Proposals, Design Docs and/or Reviews help socialize/diffuse org standards and expectations.

I found these help ground the mentorship and discussions between junior-senior devs. And so even for the enterprising aka proactive junior devs who might start working on something in advance of plans/roadmaps, by the time they present that work for review, if the work followed org architectural and design patterns, the review and acceptance process flows smoothly.

In my juinior days I was taught: if the org doesn't have a design or architectural SOP for the thing you're doing, find a couple of respectable RFCs from the internet, pick the three you like, and implement one. It's so much easier to stand on the shoulders of giants than to try and be the giant yourself.

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

#505

Post by simonw »

mh- wrote: post #498
bob1029 wrote: post #198

Earlier quoted context omitted.

> I try to include at least a screenshot This is ~mandatory for me. Even if what I am working on is non-visual. I will take a screenshot of a new type in my IDE and put a red box around it. This conveys the focus of my attention and other important aspects of the work effort.

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".

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

#506

Post by coffeebeqn »

jennyholzer2 wrote: post #72
lm28469 wrote: post #64

Earlier quoted context omitted.

LLMs are tools that make mediocre devs 100x more "productive" and good devs 2x more productive

From my vantage I would argue LLMs make good devs around 0.65x more productive

I just spent a day trying to get Claude to write reasonable unit tests and then after sleeping on it, reverted everything and did it myself. I’m not gonna be using it for a while because it 0.5x’d me once again

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

#507

Post by osn9363739 »

postflopclarity wrote: post #337
bee_rider wrote: post #273

Earlier quoted context omitted.

Can we make an LLM do it? “You are a cranky senior software engineer who loves to nitpick change requests. Here are your coding standards. You only sign off of a change after you are sure it works; if you run out of compute credits before you can prove it to yourself, reject the change as too complex.” Balance things, pit the LLMs against each other.

I do this all the time. I pass my code into "you are a skeptic and hate all the code my student produces: here is their latest PR etc.. etc.."

I have devs that do this and we have CI AI code review. Problem is, it always finds something. So the devs that have been in the code base for a while know what to ignore, the new devs get bogged down by research. It's a net benefit as it forces them to learn, which they should be doing. It def slows them down though which goes against some of what I see about the productivity boost claims. A human reviewer with the codebase experience is still needed.

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

#508

Post by coffeebeqn »

fnands wrote: post #21
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...

A friend of mine is working for a small-ish startup (11 people) and he gets to work and sees the CTO push 10k loc changes straight to main at 3 am. Probs fine when you are still in the exploration phase of a startup, scary once you get to some kind of stability

I worked with a “CTO” who did that before LLMs - one of the worst jobs I have had in the last 10 years. I spent at least 50% of my time putting out fires or refactoring his garbage code

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

#509

Post by ozozozd »

I don't test my code because I think it's my duty. I test it because my personal motivation is to see it working! What's the point of writing code if I don't even get to see it run?!

If someone's not even interested and excited to see their code work, they are in the wrong profession.

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

#510

Post by abustamam »

snarf21 wrote: post #502
teaearlgraycold wrote: post #492

Earlier quoted context omitted.

Your manager should be on their ass for wasting your time.

Worse yet, these were done by the managers of the Marketing team and the Mapping team. Plus, these are high profile issues that (somehow) required getting the CEO involved too! (Obviously there is a lot of dysfunction in our organization, lol.)

I was going to joke to GP "jokes on you, management is in on it" but apparently it was no joke
Post reply on HN