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

591–600 of 699 posts

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

#591

Post by TheTxT »

user34283 wrote: post #292
TheTxT wrote: post #268

Earlier quoted context omitted.

This approach sounds like a great way to get a lot of security holes into your code. Maybe your competitors will be faster at first, but it’s probably better to be a bit slower and not leaking all your users data.

I'm mostly thinking about the frontend. If I had a backend API that was serving user data, I'd of course check more carefully. This kind of mistake always seemed amateurish to me.

Fair enough. I would still personally feel uneasy about it, but I guess it’s alright if it works for others.

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

#593

Post by abustamam »

theshrike79 wrote: post #533
abustamam wrote: post #497

Earlier quoted context omitted.

Agreed. Meanwhile, many job postings out there looking for 10x full-stack developers who have deep experience in database, server, front end, devops, etc. I think the concept of Full-stack dev is fine, but expecting them to know each part of the stack deeply isn't feasible imo.

Expert Generalists are a thing: https://martinfowler.com/articles/expert-generalist.html BUT they're completely wasted if you just use them to turn JIRA tickets into end to end features =)

Haha agreed. Thanks for the link, will give it a read. I feel like expert generalists should be founders or CTOS, and they are probably not applying for the positions that claim to be wanting expert generalists.

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

#594

Post by farhanhubble »

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.

Ability is a combination of aptitude, skills, persistence, and exposure. More importantly, intention matters and it show up in the quality of your work. If the intention is to cut corners, no one can stop you from doing shoddy work. Number of years and titles do not matter much if the other parameters are low.

Aptitude paves the way for exploration: learning languages, paradigms, modeling techniques, discovering gotchas and so on. Skills follow from practice and practice requires a tough mindset where you don't give up easily.

So many software engineers learn to code just to pass exams and interviews. They claim they have strong logical reasoning. However, they have only been exposed to ideas and patterns from competitive programming rut. They have never even seen code more complex than a few hundred lines. They haven't seen problems being modeled in different languages. They haven't had the regret of building complex software without enough design. They have not had the disappointment of overengineering solutions. They have never reverse-engineered legacy code. They have never single-stepped in a debugger. All they have learned is to make random changes until "It works on my machine".

Yes, software is complex, disposable, ever-changing and often ugly but that is no excuse for keeping it that way.

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

#595

Post by farhanhubble »

ChrisMarshallNY wrote: post #534
theshrike79 wrote: post #532

Earlier quoted context omitted.

There are a definitely few ulcer-inducing events in my past that would've taken me an afternoon to fix with a current SOTA LLM vs 2+ weeks of swearing, crying and stressing out.

When I come upon an issue, I pretty much immediately copy/paste the code into an LLM, with a description of the context, symptoms, and desired outcome. It will usually home right in on the bug, or will give me a good starting point. It's also really good at letting me know if this behavior is a "commonly encountered" one, with a summary of ways it's addressed. I've probably done that at least a dozen times, today. I…

There's a gut feeling that comes from having gotten your hands dirty enough that tells you if the LLM is being smart or spitting out bullshit.

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

#596

Post by JohnBooty »

phito wrote: post #101
robgibbons wrote: post #26

For what it's worth, writing good PRs applies in more cases than just AI generated contributions. In my PR descriptions, I usually start by describing how things currently work, then a summary of what needs to change, and why. Then I go on to describe what exactly is changing with the PR. This high level summary serves to educate the reviewer, and acts as a historical record in the git log for the benefit of those wh…

I often write PR descriptions, in which I write a short explanation and try to anticipate some comments I might get. Well, every time I do, I will still get those exact comments because nobody bothers reading the description. Not to say you shouldn't write descriptions, I will keep doing it because it's my job. But a lot of people just don't care enough or are too distracted to read them.

Yeah, I've definitely found that nobody reads more than maybe 10 words of the PR description.

I've also never seen anybody but myself write substantial PR descriptions at my previous 4-5 jobs

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

#597

Post by ludicity »

teaearlgraycold wrote: post #493
theshrike79 wrote: post #395

Earlier quoted context omitted.

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.

When interviewing candidates I'm always shocked and a little depressed talking to someone with a pumped up resume and 15 years in the field when I realize they can't do much at all.

Yeah, I run into this a lot too, hah. It's depressing but also pretty funny when you've got enough distance from it. My favorite was an ex-girlfriend working in HR interviewed a candidate with 15 years of experience, and was told to ask him to solve FizzBuzz in a language of his choice.

(This is obviously a silly test for various reasons, but she was following orders.)

She called me later that day because the guy couldn't do it, so he instead blew the fuck up at HR and accused them of ambushing him with a super complex interview question. From his reaction, she thought that the company had tricked her into making totally unreasonable demands of someone who hasn't had a month to prepare.

God knows what the hell that guy did at his previous role.

PS: I have laughed every time I've seen your username for the past year, and can't remember if I've told you this before.

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

#598

Post by vrighter »

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.

and non-devs as well, nowadays

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

#599

Post by unsungNovelty »

Billions were spent in the last 5+ years saying AI can do coding. Increase speed. Reduce headcount. Remove processes. It's irritating to see that people are NOW changing the narrative of... You need to review the code... You need test it...

Devs already know this. Tell this to Managers, CEOs and non-engineers who believed billions worth of marketing BS. Cos devs don't have voice most of the time. They set the timelines. The want to push this end results to their team/company. So that is the constraints devs are working with. So to them, NOT to us Simon. WE KNOW! :)

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

#600

Post by necovek »

SoftTalker wrote: post #415
necovek wrote: post #392

Earlier quoted context omitted.

Wow, that's a very arbitrary practice: do you remember roughly when was that? I was in a team in 2006 where we did the regular, 2-approve-code-reviews-per-change-proposal (along with fully integrated CI/CD, some of it through signed email but not full diffs like Linux patchsets, but only "commands" what branch to merge where).

Around that time frame. We had CI and if you broke the build or tests failed it was your job to drop anything else you were doing and fix it. Nothing reached the review stage unless it could build and pass unit tests.

Right, we already had both: pre-review build & test runs, and pre-merge CI (this actually ran on a temp, merged branch).
Post reply on HN