7 ms·

> If coding is easy, how come programmers were in high demand, and have demanded large salaries for years (even before ZIRP)? Because programmers have generall

• logicchains 3mo ago
  >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.
  • majormajor 3mo ago
    Writing code doesn't have a notably higher (if at all higher, vs lower!) IQ requirement compared to some of the basic components of EE or MechE work. Programmer salaries have been driven up by the ability to write-once-sell-globally and the dramatic profit margin difference between that and, say, producing chips where there's a much higher fixed cost due to the need for more real material, tooling, etc. Many of those roles require a much higher-than-baseline-skill, but it pulls up the compensation competition for almost everyone else too. (Though even then there are a lot of unglamorous, line-of-business, internal-tools-programming work that's not paid particularly well even in a lot of parts of the US far from the big tech companies.)
    • deleted 3mo ago
      [deleted]
    • Jblx2 3mo ago
      >Writing code doesn't have a notably higher (if at all higher, vs lower!) IQ requirement compared to some of the basic components of EE Average IQ of Electrical Engineers: 121 https://www.iqcareerlab.com/tools/iq-for-profession/electrical-engineer https://www.iqcareerlab.com/tools/iq-for-profession/electric... ...which is the top 10% of the population. https://www.desperateminds.com/blog/iq-120.html https://www.desperateminds.com/blog/iq-120.html
      • tptacek 3mo ago
        Do you believe these numbers? Is there a cite somewhere in the literature for valid, proctored IQ tests being given to representative samples of different professions for these kinds of comparisons? The link you've provided is to a company selling online IQ tests.
        • Jblx2 3mo ago
          Is the argument that electrical and mechanical engineers are not smarter than the average person? How about figure 8 (PDF page 86) of: https://web.archive.org/web/20120905095856/http://www.ssc.wisc.edu/cde/cdewp/98-07.pdf https://web.archive.org/web/20120905095856/http://www.ssc.wi...
          • tptacek 3mo ago
            Doesn't this basically make the argument I'm making, that there's no well-defined band of IQ test scores for different professions?
            • Jblx2 3mo ago
              I'm not seeing any other posts of yours on this comment thread. Maybe you forgot to hit the "reply" button (or accidently outed an alt?) My only point was that majormajor saying that programmers might only be roughly the same smartness as electrical or mechanical engineers would put them comfortably above the average person.
            • lakdjsadjsa 3mo ago
    • pendenthistory 3mo ago
      Salaries are a product of supply AND demand. Supply of good programmers and EE/MechE is low because it requires above average intelligence and a lot of education, while demand for software has been much higher than demand for EE/MechE. Now that the demand side might invert.
      • win311fwg 3mo ago
        While you are directionally accurate, the flaw in your thinking is revealed by the fact that bad programmers also have high salaries, and plenty of five year olds have no problem being bad programmers, so there is clearly no need for above average intelligence or education to be a bad programmer. As hard as it might be for this audience to comprehend, supply is limited simply because it is an undesirable profession. The majority of the population couldn't think of anything worse to spend their time doing. Much as the same reason why they don't want to go work on oil rigs and other such work that is high paying but what most people are unwilling to do. High compensation is actually not as strong as a motivator as you might think. It can tip the scales if someone is already on the fence, but it doesn't suddenly make someone who absolutely can't stand something to change their mind.
  • tripleee 3mo ago
    I've watched dozens of people try to learn to code and fail, some definitely not for a lack of trying. Of those that did learn, only a fraction had the IQ or passion to be genuinely good at it. The difficulty of it has absolutely been a bottleneck to the supply of good devs, keeping salaries high.
    • Jach 3mo ago
      We've also seen decades of effort, much of it successful, aimed at making it easier. Programming used to be harder. (Difficulty alone doesn't account for high salaries.) If it was never "the hard part", what motivation for all that effort? Books, pedagogy, tooling, languages, even the notion of publishing a library is an attempt to make coding a related task easier for others. There's been comparatively less effort in making "the other parts" easier. Though certainly things like software development methodologies count.
      • tripleee 3mo ago
        My hunch is that the difficulty has moved, not reduced in practice. We make one layer easier and then another mountain lies at the layer above, just as hard.
• criley2 3mo ago
  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.
  • necovek 3mo ago
    Product should, definitely, run user research along with Product Design. But what I find is that people in either have a problem imagining a solution that's a couple of orders of magnitude easier to build, but also much easier for our customers (usually boils down to making the right choices for customers — the savings are not in the common "choose good defaults", but in actually removing flexibility that's needed only in 1% of cases). Thus, I insist on engineering being involved early to put real world constraints on wild ideation ("it would take 3 months for 5 engineers" quickly changes what's a must-have :)) — sometimes, a curious, critical mind can expose things like these without having to do the research or user testing themselves. Now, throughout my 20 year career, it's been very rare to find a product person who will both understand customers deeply, tie their needs to business value, and be able to formalize the intersection of these in a form of good requirements for design and engineering to eventually build! So I really believe an engineer's (and design) role there is to serve as a sanity check as they dive into actual building — does this really make sense? If they do not, they run the risk of a project completely failing or perhaps not even shipping once someone else questions the value of continuing to invest in this 3 month project 9 months in. ;-)
    • criley2 3mo ago
      A business does need a small number of their most senior engineers doing high altitude work that can, at times, include helping sales estimate new features. But in my experience, it's not rocket science and a good product team can do this on their own with a quick async check over chat. At most, a single meeting is all it takes. I've heard of Sales Engineers as well, embedding programmers directly with sales teams. But the vast majority of programmers should not be spending any significant amount of their time on this. Their value is in building and scaling well-specified systems.
• deleted 3mo ago
  [deleted]
• hakunin 3mo ago
  > 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.
  • woodruffw 3mo ago
    How many programmers operate under that kind of regulatory and operational constraint regime? I think most don’t. (In interesting ways this is programming’s greatest boon and curse: if we treated it more like building bridges or cars, the world would be a very different place.)
    • skydhash 3mo ago
      I think most do. You often sees that OSS often provide a disclaimer that they’re not liable for damages. You can’t easily do that when you provide a paid service. B2B often have SLA contracts that usually keeps everyone on their toes and not sling bugs right and left.
    • pdhborges 3mo ago
      Touch billing, touch medical data, be at a B2B company that needs to catch all the ISOs to have a chance to land bigger contracts. I don't think it's uncommon.
      • woodruffw 3mo ago
        It might be an unpopular option, but I think the regulatory regimes that control medical and financial privacy as they interact with software are significantly lighter touch than e.g. the regimes that control material quality for bridges and tunnels, much less airplanes.
        • HeyLaughingBoy 3mo ago
          Not really. In those safety-critical areas, the code really is no different. What is significantly different is the surrounding process. I had to make some software changes to an old medical device this year. The overwhelming majority of the effort was understanding what the customer wanted and giving them feedback into how that would change the existing system and the risks associated. Then, creating a plan to follow the necessary standard (IEC62304) and creating the associated documentation and getting it reviewed and approved. The actual code that changed was probably only around 100 LOC but the project took several months. Heck, the code was simple enough that an intern could have done it.
• relaxing 3mo ago
  > 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.)
  • therealdrag0 3mo ago
    Agree. What a strange perspective. Engineering is what is hard, and that includes coding and non-coding activities but doesn’t require customer interrogation.
  • pjmlp 3mo ago
    Not in agency or consulting jobs.
  • beachy 3mo ago
    That job was often called a "business analyst" in "the old days".
  • HeyLaughingBoy 3mo ago
    That has only been true in the largest corporation I've worked for (around $4bn annually). Even then, we (devs) had to challenge inconsistencies in requirements or incomplete specifications. The only job I've ever had where I could just do exactly what I was told and get away with it was right after I got out of college.
  • mkehrt 3mo ago
    I think this is true when you realize "customer" means "coworker" or "person on the next team over" or "management" or "your intuition about the problem". Which all sort of have the same shape.
• ray_v 3mo ago
  > 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.
• bdangubic 3mo ago
  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.”
  • deleted 3mo ago
    [deleted]
  • turtlebits 3mo ago
    Understanding requirements means talking to customers. A customer can be anyone, even other devs that consume your code/product.
    • bdangubic 3mo ago
      “understanding requirements” is as much “wearing other hats” as having hands is “wearing other hats” for a carpenter. coding is always the hard part, always. whenever I was on any project and we had more work than resource we never hired “people to wear other hats” - we hired people to write code, that’s it. thats the fucking job. you ever see a leet-code-for-understanding-requirements? yea, me either…
      • necovek 3mo ago
        You actually do. All of those puzzle-style questions of the sort of "how many liters of water in Mediterranean" ask you to develop a solution with a vague requirement by leveraging what you know roughly to demonstrate you can specify requirements yourself (oh, Mediterranean is roughly 5000sqkm [-> I need surface area], on average 50m deep [-> I need average depth], this gives me A x B liters total) — I'd call these the leet-code version of requirement understanding/development. But really, any interview is really about giving you a requirement, and seeing _how_ you understand it, how you clarify it with your stakeholders (interviewers), and then how you address them.
        • bdangubic 3mo ago
• stouset 3mo ago
  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.
• closeparen 3mo ago
  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.
• dofm 3mo ago
  > 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.
  • dave_sid 3mo ago
    “The best code is the code you didn’t have to write” - a wise coder
  • OroPla 3mo ago
    The point of the OP in this case wasn't code that compiles, but code that does what the customer wants. If the customer orders an email client but really wants a chat application, coding a working email client is not "correct". And insisting that the customer ordered the wrong thing won't change the reality of the matter.
    • dofm 3mo ago
      "Correct" does not just mean "compiles" (syntactically correct), for one thing. Correct code is that which does what is required of it at whatever level of correctness you are examining, as was said. But it's the whole thing. There is no sensible distinction to be drawn between writing correct code and merely writing code. The former is the only definition of the job. We shouldn't define down competence.
• omiliyomami 3mo ago
  How can I downvote a comment
  • drdeca 3mo ago
    There’s a minimum karma requirement.
• ben_w 3mo ago
  > 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 > 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. 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?)
  • dofm 3mo ago
    > (Isn't that what sales is? Working with the customer to tease out the real thing they need solving?) For any product of any complexity you can can essentially never successfully delegate that process to a non-programmer. Indeed you can not that often even trust that the client employee doing the asking knows what it is they need. Almost certainly someone in the organisation who was not in the meeting is better placed to tell you what is actually required. This task needs an analyst; that analyst needs to have experience of writing meaningful code.
  • tommyage 2mo ago
    I want append: We have studied. We constantly educate ourselves (I have still not yet managed to work through the entire SICP on my own). Our tools are changing constantly. We are juggling information through devops, requirement engineers and customers. We advise daily. We get consolidated if something is complicated to summarize. We do forensics. Constantly under the pressure that some bit rot may open a new urgent bug we have to investigate. Money AND reputation on the line. It is a damn stressful job. So if we do our craft, we do it with incremental knowledge. Carefully. We build community of trust in our free time to get connected and improve. Any new member gets welcomed and onboarded. His knowledge im the future will supplement ours. So we mentor additionally. Now comes AI. Collects the knowledge and hands it over to anyone. And we know: It is UNSAFE. Don't get me wrong; I consolidate it now as well, just to keep up with the increasing pressure to investigate. But the thing is: While we did our craft so that we won't have to touch it in the next five years, the complexity increases every single day. And its out of our hands. If some junior comes in and starts writing decent code with ai it is nice. Until it breaks and AI won't help. Or worse: Gets applied on customer data in the wrong way. A new ticket for the greybeards (by no means, I am not such). I think we are on the wrong track. Using ai decreases my abilities. It increases the load. I think we should get twice the salaries. It has become unbearable. Could you imagine that your local file server for your family consists of a enterprise database, a key-value store, possibly multiple reverse-proxies, a vector database.... my point beeing: Complexity. Invariants, frameworks to get familiar with... And the tool to supplement the demand is intransparent (but probably deterministic? Idk). It feels just so wrong.
• zug_zug 3mo ago
  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.
• woopah 3mo ago
  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.
  • frgturpwd 2mo ago
    So you're saying a lead/manager that recognizes good programmers from bad programmers should be paid the most... rubs hands together
  • Valakas_ 2mo ago
    This is the correct answer. Of all the engineering fields, SWE is by far the one with highest salary compared to how difficult it is. SWE lucked out on the fact that we have been going through a technological revolution, and naturally the demand for the people who work in this field is huge. Hence the pay. In my university SWE bachelors + masters degree has been seen as the easiest one as far as i can remember. Mechanical, bio, aerospace and electrical as the most difficult. It's always been funny to see the arrogance of some SWE who think that since they're the highest paid, they are also the most difficult and most important jobs, while it has zero to do with either of these two. Just luck of supply/demand. Otherwise mathematicians and physics would be sitting at the top with the highest paid careers and they... are not even close to that. For this reason I don't really feel sorry for AI replacing programmers/SWE, at least the ones that were arrogant enough to think in the way i explained.
• neonstatic 3mo ago
  > interrogate the shit out of the customer until they finally reveal the true requirements. Or are forced to figure them out.
• jacquesm 3mo ago
  Knowing what to write in the first place is the hard for me, and always has been.
• zem 3mo ago
  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.
• Jach 3mo ago
  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/ 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.
• bluegatty 3mo ago
  "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.
  • cindyllm 3mo ago
    [dead]
  • vaylian 2mo ago
    They are real invisible hats. Those hats are invisible to outsiders, who don't understand that programmers do much more than just entering code on a computer.
    • bluegatty 2mo ago
      a shocking number of devs don't describe their jobs that way either. people who self learn will tend to focus on the code not the proecess
• jasonlotito 3mo ago
  > Writing code is not hard. Writing correct code is. Xing Y is not Z. Xing `additional adjective` Y is. Writing prose is not hard. Writing good prose is. Cooking food is not hard. Cooking good food is. ...