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

401–410 of 699 posts

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

#401

Post by jghn »

tensor wrote: post #381
SoftTalker wrote: post #374

Earlier quoted context omitted.

Title inflation?

IMO tech suffers pretty horrible title inflation. If you reach "senior" after only two years and "principle" after 5, what is left for the next 20 years? It's pretty ridiculous. But this sort of thing is really typical. The average tenure of someone in tech is probably about 2 years and each year the expectation is to see "big" career progression. Very often "When is my title going to change" is asked literally in th…

The important thing here is for people to understand that at best titles only indicate relative rank within a company. And even then that's tenuous. Titles are effectively meaningless when comparing outside of a company.

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

#402

Post by CodeMage »

tensor wrote: post #381
SoftTalker wrote: post #374

Earlier quoted context omitted.

Title inflation?

IMO tech suffers pretty horrible title inflation. If you reach "senior" after only two years and "principle" after 5, what is left for the next 20 years? It's pretty ridiculous. But this sort of thing is really typical. The average tenure of someone in tech is probably about 2 years and each year the expectation is to see "big" career progression. Very often "When is my title going to change" is asked literally in th…

What makes this whole thing worse is the concept of "non-terminal" levels, i.e. levels that you're not allowed to stay at indefinitely, which means that you must either get promoted or fired.

I can understand not wanting to let people stay in a junior position forever, but I've seen this taken to a ridiculous extreme, where the ladder starts at a junior level, then goes through intermediate and senior to settle on staff engineer as the first "terminal" position.

Someone should explain to the people who dream up these policies that the Peter Principle is not something we should aim for.

It's even worse when you combine this with age. I'm nearing 47 years old now and have 26 years of professional experience, and I'm not just tired, but exhausted by the relentless push to make me go higher up on the ladder. Let me settle down where I'm at my most competent and let me build shit instead of going to interminable meetings to figure out what we want to build and who should be responsible for it. I'm old enough to remember the time when managers were at least expected to be more useful in that regard.

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

#403

Post by joquarky »

theshrike79 wrote: post #395
xnx wrote: post #368

Earlier quoted context omitted.

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

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.

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

#404

Post by babarock »

simonw wrote: post #44
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…

100%. There's no difference at all in my mind between an AI-assisted PR and a regular PR: in both cases they should include proof that the change works and that the author has put the work in to test it.

You're not wrong, however the issue is that it's not always easy to detect if a PR includes proof that the change works. It requires that the reviewer interrupts what they're doing, switch context completely and look at the PR.

If you consider that reviewer bandwidth is very limited in most projects AND that the volume of low-effort-AI-assisted PR has grown incredibly over the past year, now we have a spam problem.

Some of my engineers refuse to review a patch if they detect that it's AI-assisted. They're wrong, but I understand their pain.

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

#405

Post by redwall_hp »

AlienRobot wrote: post #189
whattheheckheck wrote: post #150

Earlier quoted context omitted.

I woke up and had a thought the software engineering isn't a serious engineering field if they actually fully shipped llms and expect everyone to use them. What do you expect quality wise from a profession that says that this is okay?

Imagine if normal engineering did that. Engineers invent a "blobby" thing that glues things together. It has amazing properties that increase productivity but sometimes it just stops working for some reason and comes off. It's totally random and because of how blobby is produced there is no way to tell when it's going to work or not, contrary to the typical material. Anyway we're going to use blobby to build everythi…

And, don't forget, software makes its way into airplanes a medical equipment and such, and has directly killed people. Therac and Boeing come to mind.

I'm starting to be in favor of professional licensing for software engineering.

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

#406

Post by alexgotoi »

minimaxir wrote: post #333
alexgotoi wrote: post #227

[flagged]

Slightly off-topic: you've been advertising your newsletter with every comment you made over the past few days, and you've made a lot of comments. I get that marketing is hard, but that's spammy.

Appreciate the comment, will slow down.

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

#407

Post by SunshineTheCat »

asadotzler wrote: post #339
SunshineTheCat wrote: post #326

Earlier quoted context omitted.

In the scenario I'm hypothesizing, why would anyone need to "check" or "test" its work? What chess players are checking to make sure Stockfish made the "right" move? What determines whether or not it's "right" is if Stockfish made it.

There are clear win conditions in chess. There are not for most software engineering tasks. If you don't get this, it's probably a safe bet that you're not an engineer.

Right, which is why Deep Blue won in the early 90's and now years later, AI is moving on to far more complicated tasks, like engineering software.

The fact that you gave me the "you just don't understand, you're not a chess grandmaster" emotional response helps indicate that I'm pretty much right on target with this one.

FWIW I have been engineering software for over 15 years.

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

#408

Post by tete »

rnewme wrote: post #324
venturecruelty wrote: post #322

Earlier quoted context omitted.

How do you square that with "use AI and get this feature done in three days or have your 'performance reviewed' with HR in the room"? Because I'm having trouble bridging that gap. Edit: help, the new org said the same thing. :( Edit 2: you guys, seriously, the HR lady keeps looking up at me and shaking her head. I don't think this is good. I tried to be a real, bigboy engineer, but they just mumbled something about K…

Uptime x customer satisfaction vs. stack of cards. If they don't understand engineering prepare CV and head over to org that does.

I think people are getting used to stuff not working. People (like me) use crap like Teams, Slack, that web version of Office, Outlook, etc. on a daily basis and pour huge amounts money in. They use shit like Fortinet (the digital version of dream catchers) and so on.

Things break. A lot. Doctors successful or not also deal with the same shitty IT on a daily basis.

Nobody cares about engineering. It's about selling stuff, not about reliability, etc.

And to some degree one is forced to use that stuff anyways.

So sure you can go to a company understanding engineering, but if you do a job for salary you might lose out on quite a bit on it if you care for things like quality. We see this in so many different sectors.

Sure there is a unicorn here and there that makes it for a while. And they might even go big and then they sell the company or change to maximizing profits, because that's the only way up when you essentially already made it (on top of one of the big players).

For small projects/companies it depends if you have a way to still launch big, which you can usually do with enough capital. You can still make a big profit with a crappy product then, but essentially only once or twice. But then your goal also doesn't have to create quality.

Microsoft and Fortinet for example wouldn't profit from adding (much) quality. They profit from hypes. So they now both do "AI".

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

#409

Post by necovek »

JohnBooty wrote: post #213
marcosdumay wrote: post #183

Earlier quoted context omitted.

A full-time code reviewer will quickly lose touch with all practical matters and steer the codebase into some unmaintainable mess. This is not the first time somebody had that idea.

I've often thought this could work if the code reviewer was full-time, but rotated regularly. Just like a lot of jobs do with on-call weeks, or weeks spent as release manager - like if you have 10 engineers, and once every ten weeks it's your turn to be on call. That would definitely solve the "code reviewer loses touch with reality" issue. Whether it would be a net reduction in disruption, I don't know.

Doing code review as described (actually diving deep, testing etc) for 10 engineers producing code is likely not going to be feasible unless they are really slow.

In general, back in 2000s, a team I was on employed a simple rule to ensure reviews happen in a timely manner: once you ask for a review, you have an obligation to do 2 reviews (as we required 2 approvals on every change).

The biggest problem was when there wasn't stuff to review, so you carried "debt" over, and some never repaid it. But with a team of 15-30 people, it worked surprisingly well: no interrupts, quick response times.

It did require writing good change descriptions along with testing instructions. We also introduced diff size limits to encourage iterative development and small context when reviewing (as obviously not all 15-30 people had same deep knowledge of all the areas).

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

#410

Post by gardenhedge »

nrhrjrjrjtntbt wrote: post #386
trevor-e wrote: post #159

> Your job is to deliver code you have proven to work. Strong disagree here, your job is to deliver solutions that help the business solve a problem. In _most_ cases that means delivering code that you should be able to confidently prove satisfies the requirements like the OP mentioned, but I think this is an important nitpick distinction I didn't understand until later on in my career.

> Strong disagree here, your job is to deliver solutions that help the business solve a problem. Sure. That is every job though. It is interesting to muse on. Hard for us to solve a problem without a computer (or removing one!)

Yeah, more correctly, the description should be:

"Your job is to deliver technical solutions that help the business solve a problem"

Where the word technical does the work of representing your skill set. That means you won't be asked to create a marketing campaign (solution) to help the business sell more product (problem).

Post reply on HN