> Writing code is not hard. Writing correct code is. Knowing what is correct in a setting with paying customers generally involves interacting with those customers.

That's like saying "building a car is not hard, building a real car that you can use and that passes regulation is".

IOW, writing code is hard in every reasonable context.

> Writing code is not hard. Writing correct code is. Knowing what is correct in a setting with paying customers generally involves interacting with those customers.

  Invoice: $1000
  One bolt tightened: $1
  Knowing which bolt to tighten: $999

Bit of both probably. I've seen really awful code in my time, so would say "actually coding well" is indeed one of the hard parts.

But knowing what the real problem to be solved is, is indeed important. (Isn't that what sales is? Working with the customer to tease out the real thing they need solving?)

I think people also have a natural tendency to assume that the amount you are paid is correlated to how difficult the job is, which isn't quite true. The market value of a role has a lot of additional factors besides how intrinsically difficult the actual job is such as supply and demand and the funding source. Programmers may have been able to demand high salaries partially because the explosion in demand came faster than the explosion in supply.

While it is true that a programmer's job is a lot more than writing code, I also wonder to what extent that businesses will actually be able to tell a good programmer from a bad one. For example, a lot of folks at big companies can honestly get away with being a ticket-taking code monkey because so much of the responsibility has been abstracted away so that they don't actually get punished for not caring about the customer. It's sort of similar to how many schools realistically wouldn't care to distinguish between a teacher who puts in extra effort into their classroom versus one who clocks in and clocks out as long as some bare minimums were being met.

I think strong programmers will get rewarded in the right companies that need them, but it's still an open question as to how many companies exist that have their bottom lines actually depend on a programmer doing a good job at wearing all those extra hats.

Exactly. Writing code is easy. Junior developers do it all the time. Hell, they write far mode code and do it faster!

I go half the speed of a junior developer, but the code I write lasts five years to a decade with an order of magnitude or two fewer bugs and long-term maintenance burden.

"wear additional, invisible hats "

No ... those are not invisible hats ... those are the real hats.

Software is 'Knowledge Distillation' the code is the hieroglyphic artifacts.

Engineers Engineer, Scribes Scribe.

Just so happens developers do their own scribing.

nope, I've definitely worked on a lot of projects where knowing how to satisfy the requirements was not the challenge, writing the code was genuinely hard. complex data structures that had to have invariants maintained, distributed access to shared memory, dealing with various forms of fault tolerance, and above all getting some complex algorithms to run at an acceptable speed - all that really does get bottlenecked on the difficulty of the specific low level code you have to write. and then there are the architectural issues that make all the difference not when the code is first written but months later when you want to add another big feature and find out that fitting it into the existing code base is hampered by the early decisions you made. I'm honestly glad to have LLMs to help with a lot of that, though I'm also glad that I built up the skills to do them myself over the last few decades and am a little sad that programmers today will not build a lot of those skills up.

Knowing what to write in the first place is the hard for me, and always has been.

Building on this, as evidence:

If you have shop where you have the best product-owner in the world, and exact clarity on how you want to build something, how all failures are handled, all the tradeoffs, all the implementation details, all the risks, then product is simple, then your company absolutely can get away with hiring a less than top-tier engineer.

However if you're combining all of those skills/roles into one individual (a staff+ engineer) then of course it's going to be expensive.

In my experience the only people who get paid "well" to just code up well defined JIRA tickets are new grads, and this is essentially a training period until they grow into leading complex and ambiguous projects independently. You can't hang out there more than a few years.

> The gigantic salaries paid to the most prolific employees is not due to their ability to write code. It is due to their ability to interrogate the shit out of the customer until they finally reveal the true requirements.

That doesn’t describe any devs I know, especially not in the old days. Interrogating customers and bringing back requirements was the job of management (who got big salaries, too.)

> Either directly or worse.

Wow, some "the killer is calling from inside the house" vibes right there. But I totally agree that the game of telephone has always been _an_ issue - maybe not _the_ issue but certainly a big one.

I'm beginning to wonder if a lot of commenters have forgotten that waterfall is a failed methodology in part because you can't always just gather requirements by say introspection or interrogating the customer for them. In order to reveal the true, accurate requirements, you often need to write code. Not always, sure, just like some code is relatively easy to write, some requirements are easy to both accurately specify ahead of time and even satisfy. (An old XKCD hinting at this distinction: https://xkcd.com/1425/ Only nowadays we actually can easily satisfy a lot more of those old easy-to-specify-difficult-if-not-impossible-to-satisfy requirements. That's the way progress in the field often goes.) Decades of startups support the iterative approach, along with pivoting, the successful ones learning the lessons of writing less committal code and discovering requirements iteratively. And it's hard to actually pull that off -- so many companies have gone under or lost out significantly to competitors because they couldn't write code fast enough, or change code fast enough, either with the goal of discovering the real requirements or adequately satisfying those requirements once known. Code is hard in general.

> Writing code is not hard. Writing correct code is.

Dude.

Writing correct code is the whole process. If you're defining coding without care for correctness, of course you can write it off as not the hard part.

>Writing code is not hard.

Writing code has a minimum IQ requirement; a significant fraction of the population will essentially never be able to code by themselves. That labor supply limitation is what's kept programmer salaries relatively high.

I think you're confusing product and engineering. I get that programmers are smart so we just assume we can do every job, but it's a waste of your time and salary to talk extensively to customers and create product requirements. Let the PM's run the user research sessions, you can find more productive things to do.

However, where we agree, is that there is more to engineering than writing code. It's problem solving. Even if the product team, the c-suite, the board, the investors, et al, are all in on a product that they believe customers want, doesn't mean the real problem of bringing that idea to life at scale has been solved.

> interrogate the shit out of the customer until they finally reveal the true requirements.

Or are forced to figure them out.

How can I downvote a comment

After 30+ years in the industry the absolute best programmers I know never spoke to any customers, like ever. so bullshit comment all around. I’ve been coding for 30+, have obscene salary and do not wear any “additional hats” or talk to any “customers.”