Yes, for building something

But for building the right thing? Doubtful.

Most of a great engineer’s work isn’t writing code, but interrogating what people think their problems are, to find what the actual problems are.

In short: problem solving, not writing code.

Where's this delusion come from recently that great engineers didnt write code?

What a load of crap.

All you're doing is describing a different job role.

What you're talking about is BA work, and a subset of engineers are great at it, but most are just ok.

You're claiming a part of the job that was secondary, and not required, is now the whole job.

I never said great engineers didn’t write code. But writing the code was never the point.

The point has always been delivering the product to the customer, in any industry. Code is rarely the deliverable.

That’s my point.

And a horse breeder was important to transportation until the 1920s, but it doesn't mean their job was transportation.

They didn't magically become great truck drivers.

Programmers do not deliver products, they deliver code to make products.

If the code is no longer needed, nor is the job. A different job will replace it with different skills required.

> And a horse breeder was important to transportation until the 1920s, but it doesn't mean their job was transportation. They didn't magically become great truck drivers.

Again: unrelated and pointless analogy. The horse breeder would be analogous to chipmakers or companies that make computers. Turns out they have more of a job than ever. They don’t need to “become truck drivers.”

> Programmers do not deliver products, they deliver code to make products.

That’s not even a little bit true. Programmers deliver product every day: see every single startup on the planet, and most companies.

Moreover, you said programmer. I didn’t.

I said software engineer/architect, as that was what the parent comment asked.

I chose my words intentionally. I am referring to people who engage in the act of engineering or architecting software, which is definitely not limited to writing code.

Yes, a pure programmer (aka a researcher or a junior programmer) may not fare as well, for the reasons you mentioned.

But that was never who we were discussing.

If you still think the code is the point, I’m not sure we’re going to see eye to eye, and I’m going to just agree to disagree. And if that’s the case, then you’re right: you may be left behind, keyboard in hand.

> But writing the code was never the point.

Is that why most prestigious jobs grilled you like a devil on algos/system design?

> The point has always been delivering the product to the customer, in any industry. Code is rarely the deliverable.

That’s just nonsense. It’s like saying “delivering product was always the most important thing, not drinking water”.

It's well understood that programming interviews are a pretty shitty tool. They're a proxy for understanding if you have basic skills required to understand a computer. Notably, most companies don't rely on these alone, they have behavioral questions, architecture questions, etc. Have you ever done an interview at these companies you're talking about? They're 8 hours lol maybe 1 is spent programming.

But it's just very obvious to any software engineer worth anything that code is just one part of the job, and it's usually somewhere in the middle of a process. Understanding customer requirements, making technical decisions, maintaining the codebase, reviewing code changes/ providing feedback, responding on incidents, deciding what work to do or not to do, deciding when a constraint has to be broken, etc. There are a billion things that aren't "typing code" that an engineer does every day. To deny this is absurd to anyone who lives every day doing those things.

Gold luck passing Leetcode before you even get to all of these. Whether they’re shitty or not is irrelevant, they’re here and it’s a fact.

And what do you derive from that fact? The position is that coding is only one portion of the job. "But there's a coding interview" was used to rebut this position. I have pointed out that the coding interview is a fraction of the procses, once again indicating that the job involves much more than coding.

So you saying "but there's a coding interview" again... who cares? Why is that relevant?

Everybody who works for salary cares. You can lament how coding is just 1% of work, it’s irrelevant what percentage is “real” coding work when you can’t pass that coding round and you’re not hired.

I have literally no clue what point you're trying to string together. I tried to refocus things to the topic at hand but you're just saying completely irrelevant things. What is your point?

Yeah, this is precisely what I meant.

I'm genuinely blown away at the attitude lately that developers spend their time programming/ our primary value is code. I guess because we tend to be organizationally isolated people just have no idea? But like... it's so absurd to anyone who does the job. It's like thinking that PM's primary role is assigning tickets, just so obviously false.

I think there's some resentment. I've seen repeatedly now people essentially celebrating that "tech bros" are finally going to see their salaries crash or whatever, it's pretty sick but I've noticed this quite a lot.

> Is that why most prestigious jobs grilled you like a devil on algos/system design?

No. That’s because interviews have always sucked, and have always been terrible predictors of how you do on the job. We just never had a better way of deciding except paying for a project.

> That’s just nonsense. It’s like saying “delivering product was always the most important thing, not drinking water”.

That’s… not an argument? It’s not even a strawman, it’s just unrelated.

The thing a customer has always paid for was the end product. Not the code. This is absolutely trivial to see, since a customer has never asked to read the code.

> No. That’s because interviews have always sucked, and have always been terrible predictors of how you do on the job. We just never had a better way of deciding except paying for a project.

Who cares? They’re here, and they will stay here for foreseeable future.

> That’s… not an argument? It’s not even a strawman, it’s just unrelated. The thing a customer has always paid for was the end product. Not the code. This is absolutely trivial to see, since a customer has never asked to read the code.

Yeah, and they didn’t pay for the water that you drank. Without which, you know, you’ll fucking die. Code is part of the package, just like you eating and shitting in the process.