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

621–630 of 699 posts

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

#621

Post by teaearlgraycold »

ludicity wrote: post #597
teaearlgraycold wrote: post #493

Earlier quoted context omitted.

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 cou…

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

You haven't but thanks :D

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

#622

Post by disgruntledphd2 »

theshrike79 wrote: post #531
BadCookie wrote: post #436

Earlier quoted context omitted.

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.

Depends a lot on the type of software you're doing. Startups will have hungry people willing to learn, more traditional companies won't in the same percentages. Not all people are curious, they go to school, learn to code and work their job like a normal 9-5 blue collar worker. They go to company trainings, but they don't read Hacker News, don't follow the latest language fads or do personal software projects during…

> ...and I just checked LinkedIn, the non-curious ones are still in the same company, managing the same piece of SaaS as a Software Developer. 20-26 years in the same company, straight from school.

And honestly, this should be OK. For a lot of people, they work to put food on the table and keep a roof over their head, and our society is structured like this for whatever reasons.

Not everyone needs to be learning and growing all the time. I personally like this, but I've worked with incredibly competent people who just had other interests outside of work, and had no desire to get promoted or work on different things.

Personally, I prefer (often) working with the learning and growing people, but sometimes you can learn a bunch from the stable people as they'll often have lots of hard won lessons caused by staying in the same place for a long time.

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

#623

Post by jmpeax »

tremon wrote: post #548
jmpeax wrote: post #416

Earlier quoted context omitted.

Don't get me started on "software architect".

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.

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

#624

Post by Muromec »

biglost wrote: post #577
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…

Our leader wrote himself a great prompt to fill up Tickets in jira with useless text too and our boss is happy like if he won the lottery. Now instead of ugly but short useful texts now i have yo read a fucking eassay!!!

You were supposed to feed it back into the lying machine to dustill the content from the vapor, not read it. You are not AI native worker and should be kicked out of the otherwise great performing team

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

#625

Post by andai »

biglost wrote: post #577
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…

Our leader wrote himself a great prompt to fill up Tickets in jira with useless text too and our boss is happy like if he won the lottery. Now instead of ugly but short useful texts now i have yo read a fucking eassay!!!

Nah, you know how it works? You're not supposed to read it!

Encoding Process

One sentence in -> Several paragraphs out

Decoding Process

Several paragraphs in -> One sentence out

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

#626

Post by wseqyrku »

joquarky wrote: post #403
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.

Experience is knowledge of what not to do.

True. I remember myself spending weeks just to figure out what not to do next because I can't afford a redo.

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

#627

Post by kubanczyk »

nothrabannosir wrote: post #612
phito wrote: post #101

Earlier quoted context omitted.

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.

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…

> Comments should not be answered in line, but by pushing updates to the code.

Hear, hear.

me: This unreadable, needs a comment.

them:

me: True, but I've meant a source code comment.

them:

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

#628

Post by necovek »

shiandow wrote: post #298
hnthrow0287345 wrote: post #153

Earlier quoted context omitted.

>It's even worse than that: non-junior devs are doing it as well. This might be unpopular, but that is seeming more like an opportunity if we want to continue allowing AI to generate code. One of the annoying things engineers have to deal with is stopping whatever they're doing and doing a review. Obviously this gets worse if more total code is being produced. We could eliminate that interruption by having someone do…

The best way I have of knowing code is correct on all levels is convincing myself I would write it the same way. Thr only way to be 100% sure is writing it myself. If I know some one reasonable managed to write the code I can usually take some shortcuts and only look at the code style, common gotchas etc. Of course it wouldn't be the first time I made some erroneous assumptions about how well considered the code was.…

With time and experience, reading code becomes much easier.

And well-written code is usually easy to read and understand too!

The purpose of a code review is, apart from ensuring correctness, to ensure that the code that gets merged is easy to understand! And to be honest, if it's easy to understand, it's easy to ensure correctness too!

The biggest challenge I had was to distinguish between explanations needed to understand the change, and explanations needed to understand the code after it was merged in. And making it clear in my code review questions that whatever question I have, I need code and comments in the code to answer them, not the author to explain it to me (I frequently have already figured out the why, but took me longer than needed): it's not because I did not get it, it's because it should be clearer (finding the right balance between asking explicitly, offering a suggestion, or pitting it as a question to prompt some thinking is non-trivial too).

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

#629

Post by necovek »

sodapopcan wrote: post #313
gaigalas wrote: post #235

Earlier quoted context omitted.

It does not eliminate code reviews. In practice, you should have at least one independent reviewer who did not actively worked on the PR. That reviewer should also download the entire code, run it, make tests fail and so on. In my experience, it's also good that this is not a fixed role "the reviewer", and a responsability everyone in the team shares (your next task should always be: review someone else's work, only…

> It does not eliminate code reviews. Yes it does. There are many ways to do things, of course, and you can institute that there must be an independent reviewer, but I see this is a colossal waste of time and takes away one of the many benefits of pairing. Switch pairs frequently, and by frequently I really mean "daily," and there is no need for review. This also covers "no fixed responsibilities" you mentioned (whic…

Pairing people together on a single task makes that task get done faster, with higher quality. However, when paired together, the people still pick up some of the same biases and hold the same assumptions and context, so it is really worse than having a single author + independent reviewer.

So:

  single author, no review

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

#630

Post by necovek »

tunesmith wrote: post #551
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.

As always, this requires nuance. Just yesterday and today, I did exactly that to my direct reports (I'm director-level). We had gotten a bug report, and the team had collectively looked into it and believed it was not our problem, but that of an external vendor. Reported it to the vendor, who looked into it, tested it, and then pushed back and said it was our problem. My team is still more LLM-averse than me, so I ha…

2 decades ago, so well before any LLMs, our CEO did that with a couple of huge code changes: he hacked together a few things, and threw it over the wall to us (10K lines). I was happy I did not get assigned to deal with that mess, but getting that into production quality code took more than a month!

"But I did it in a few days, how can it take so long for you guys?" was not received well by the team.

Sure, every case is its own, and maybe here it made sense if the fix was small and testing for it was simple. Personally (also in a director-level role today), I'd rather lead by example and do the full story, including testing, and especially writing automated tests (with LLM's help or not), especially if it is small (I actually did that to fix misuse of mutexes ~12 months ago in one of our platform libraries, when everybody else was stuck when our multi-threaded code behaved as single-threaded code).

Even so, I prefer to sit with them and loudly ask questions that I'd be asking myself on the path to a fix: let them learn how I get to a solution is even more valuable, IMO.

Post reply on HN