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

421–430 of 699 posts

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

#421

Post by lokar »

CodeMage wrote: post #402
tensor wrote: post #381

Earlier quoted context omitted.

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

Yeah, the terminal level, whatever the title (they are just words) need to be the point at which you can handle moderately complex (multi-week) tasks with no supervision.

And honestly, this will depend on the environment and kind of work being done.

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

#422

Post by order-matters »

tete wrote: post #396
vladsh wrote: post #309

We should get back to the basic definition of the engineering job. An engineer understands requirements, translates them into logical flows that can be automated, communicates tradeoffs across the organization, and makes tradeoff calls on maintainability, extensibility, readability, and security. Most importantly, they’re accountable for the outcome, because many tradeoffs only reveal their cost once they hit reality…

Okay, then software engineers are not engineers. The whole reliability, etc. to many is not of much priority. Things got an absolutely shitshow and still everyone buys it. In other words the only outcome will be that people don't have or don't want to have engineers anymore. Companies are very much not interested in someone who does the above, but at most someone who sells or cosplays these things - if even. Cause th…

TBH I think Information Systems Engineering and Computer Engineering can just eat software engineers lunch at this point. the entire need for a separate engineering discipline on software was for low level coding. Custom hardware chips are easier to make for simple things and not a lot of need in low level coding anymore for more complex things means the focus is shifting back to either hardware choices or higher level system management

I'd argue the only places left you really need low level coding fall under computer science. If you are a computer or systems engineer who needs to work with a lot of code then youll benefit from having exposure to computer science, but an actual engineering discipline for just software seems silly now. Not to mention pretty much all engineers at this point are configuring software tools on their own to some degree

I think it's similar to how there used to be horse doctors as a separate profession from vets when horses were much more prominent in everyday life, but now they are all vets again and some of them specialize in horses

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

#423

Post by phito »

walthamstow wrote: post #142
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.

At my place nobody reads my descriptions because nobody writes them so they assume there isn't one!

Too real :(

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

#424

Post by immibis »

georgeburdell wrote: post #173
Aurornis wrote: post #147

Earlier quoted context omitted.

> while not really doing anything make sure people get rewarded for doing it. I don’t know about you, but I get paychecks twice a month for doing things included in my job description.

My manager asked me to disable CI and gating code owner reviews “for 2 weeks” 6 months ago so people could commit faster. Just because it is in your job description doesn’t mean it won’t get shoved aside when it’s perceived as the bottleneck for the core mission. Now we have nightly builds that nobody checks the result of and we’re finding out about bugs weeks later. Big company btw

That's his right. In capitalism, company owners have the power (which they delegate to managers) to fuck up the company as much as they see fit. On the upside, it means it's their responsibility and not yours.

Once you've said it's going to cause horrible problems, and they say do it anyway, and you have a paper trail of this and it's backed up onto your own storage medium, then you just do it and bring popcorn. If you think it'll bankrupt the company, then you have nothing to lose since you have no right to stop a company going bankrupt, so you might as well email your manager's manager's manager first and see if your manager gets fired.

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

#425

Post by lokar »

stephen_cagle wrote: post #412
jopsen wrote: post #274

Earlier quoted context omitted.

Doing only IRL code reviews would certainly improve quality in some projects :) It's probably also fairly expensive to do.

And yet... is it? Realtime means real discussion, and opportunity to align ever so slightly on a common standard (which we should write down!), and an opportunity to share tacit knowledge. It also increases the coverage area of code that each developer is at least somewhat familiar with. On a side note, I would love if the default was for these code reviews to be recorded. That way 2 years later when I am asked to mo…

IMO, a lot of what I think you are getting at should be worked out in design before work starts.

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

#426

Post by theshrike79 »

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…

I've had calls with Principal Architects who couldn't code themselves out of a wet paper bag.

And according to the company experience chart, they should've been a "thought leader" and "able to instruct senior engineers"

My title? Backend Programmer (20 years of experience). Our unit didn't care about titles because there was a "budget" for title upgrades per business unit and guess which team grabbed all of them =)

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

#427

Post by xmodem »

SunshineTheCat wrote: post #326
xmodem wrote: post #283

Earlier quoted context omitted.

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…

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.

Your post sent me down a rabbit hole reading about the history of computers playing chess. Notable to me is that AI advocates were claiming that a computer would be able to beat the best human chess players within 10 years as far back as the 1950s. It was so long ago they had to clarify they were talking about digital computers.

Today I learned that AI advocates being overly optimistic about its trajectory is actually not a new phenomenon - it's been happening for more than twice my lifetime.

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

#428

Post by 9rx »

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…

> If you reach "senior" after only two years and "principle" after 5, what is left for the next 20 years?

There is nothing left. Not everyone puts in the same dedication towards the craft, of course. It very well might take someone 30 years to reach "principle" (and maybe even never). But 5 years to have "seen it all" is more than reasonable for someone who has a keen interest in what they are doing. It is not like a job dependent on the season, where you only get one each year. In computing, you can see many different scenarios play out in milliseconds. It doesn't need years to go from no experience to having "seen it all".

That is why many in this industry seek management roles as a next step. It opens a new place to find scenarios one has never seen before; to get the start the process all over again.

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

#429

Post by stephen_cagle »

lokar wrote: post #420
stephen_cagle wrote: post #417

Earlier quoted context omitted.

You know, this is kind of a funny take at some level. Like, for any surgery, you want the doctor who has done the same operation 10 times, not the one who has 10 years of "many hat doctoring" experience. I'm not really arguing anything here, but it is interesting that we value breadth over (hopefully) depth/mastery of a specific thing in regards to what we view as "Senior" in software.

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 is the distinction between Midlevel and Senior.

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

#430

Post by lokar »

unbalancedevh wrote: post #300
rootusrootus wrote: post #249

Earlier quoted context omitted.

As someone else mentioned, the process is async. But I achieve a similar effect by requiring my team to review their own PRs before they expect a senior developer to review them and approve for merging. That solves some of the problem with people thinking it's okay to fire off a huge AI slop PR and make it the reviewer's responsibility to see how much the LLM hallucinated. No, you have to look at yourself first, beca…

> requiring my team to review their own PRs before they expect a senior developer to review them I'm having a hard time imagining the alternative. Do junior developers not take any pride in their work? I want to be sure my code works before I submit it for review. It's embarrassing to me if it fails basic requirements. And as a reviewer, what I want to see more than anything is how the developer assessed that their c…

It’s cultural. It always seemed natural to me, until I joined a team that treated review as some compliance checkbox that had nothing to do with the real work.

Things like real review as an important part of the work requires a culture that values it.

Post reply on HN