Hacker News new | comments | show | ask | jobs | submit login
The Bulk of Software Engineering in 2018 Is Just Plumbing (karllhughes.com)
365 points by karlhughes 5 months ago | hide | past | web | favorite | 258 comments



When I was in college, one summer I worked up in Vermont putting together and maintaining trailer park homes. Plumbing was one of the best parts of the jobs in my opinion. I'd wager the person who wrote this article has never had to put a plumbing system together from scratch.

There is an art and a science to it. The guy I worked with put a lot of thought into the best way to design these things, often because he'd be the one who would then have to maintain them. He'd also get very upset when we go out to a trailer with a poor plumbing system. The main giveaway would be a mess of pipes going every which way without rhyme or reason. These systems were the ones that broke the most and were also the hardest to fix.

It might just be "plumbing" to someone that doesn't have to do it, but there is a whole lot that goes into it and you don't want a plumber who approaches his/her work with the catch phrase: "Well, it's just plumbing."


And plumbers get paid pretty well, just like programmers. I talked to the plumber who did my house and he loved his job. He was reluctantly retiring and handing over the day-to-day operations to his son, but if he had been physically able he'd keep doing it.

He also said he refused to do work on existing plumbing. He loved to build new systems but hated maintaining old ones. Where have I heard that before...?


In a previous professional life I hired an electrician to put in some outlets in my warehouse. Long to short, he said he mainly worked solo (read: didn't want to deal with employee bullshit), and tended to work for 4 to 6 weeks and then go on vacation with his wife for a week.

I think it's the only time I said "THAT is the kinda setup I want."


A plumber we had doing some work for us explained that electricians were always miserable because it was boring but plumbing was actually fun. Subjective of course, but he was a very jolly fellow so perhaps there’s something in it


That largely depends on the tasks. Putting down 2km of electrical cable each day is pretty boring, as much of new construction is, but troubleshooting why the ventilation stopped working at a restaurant and fixing it is pretty awesome.


We've been conditioned to believe that trades such as plumbing, carpentry, construction, etc. are beneath high IQ people so it's easy to see how this mentality carries through into software engineering.

Infrastructure, properly done, outlasts its own empires.


I've met people in the trades that are just as smart, or smarter than most white collar folk, including software engineers. A lot of these people may have dropped out of high school or college, but street smarts are real

Some of the successful ones that own their own businesses are able to make a lot of money (a consistent >500k/year). The downsides are that those businesses are difficult to scale since they are service oriented, and they depend on good physical health. Moreover, consistent quality is mostly the responsibility of the owners, and again, that can't always scale far either. You also get out what you put in, in most cases it seems like the pay is a linear function of productivity. It's definitely not easy or normal to make that much, but it's doable as a tradesman


Agree with everything you've mentioned. One thing I'll add about tradesmen is they're some of the wittiest people to hang out with. Makes sense considering half the time it's a bunch of folks riffing on each other on the job.


Aye, You reminer me of a funny story.

Before I was a programmer I was an industrial electrician and had worked on sites, after I was a programmer we where down on a site installing some equipment and a plumber walked past and said “your the guys who came 200 miles to turn on a switch right?” And I instantly replied “nah, we just heard there was a scouser doing some work so we had to come look!” the techie I was with looked like he was gonna shit himself but the other guys around fell about laughing.

The thing with work sites is you can’t take any shit but you won’t find funnier people either.


Sometimes I really do miss my old welding job in the shipyards, and the fun of the people I was working with is a big part of it.

(It was also the most meritocratic job I've ever had- your ability, or lack thereof, was on display for everyone to see. And working on teams where everyone is competent is a joy, virtually regardless of actual task.)


My father-in-law has two master's degrees and was a highly sought-after fiber optic design engineer back during the dot-com boom. He deeply enjoyed the stimulation of the R&D work but hated the severe work pressure. Now he works as a fiber optic field engineer installing new systems for telecom companies and he's incredibly happy. He loves to build a beautiful installation and his industry knowledge makes him extremely effective at his job.


My father is a pipefitter (he just hit his pension date and can now retire without any penalties whenever he's ready), and it always kind of felt that way.

He worked in the wrong field for him exactly, but his skill in his trade is somewhat rare.

The man was not properly educated in many fields, but if it has anything to do with welding, he's a complete wizard. You would never know what he knows about a subject, because he might not understand all of the context or language with which a question is asked with regard to chemistry or physics... yet he does know. He can perform complex calculations in his head, on the spot, and seamlessly weld two or more different types of metals of different thicknesses in the most inhumane physical positions, and that's a Tuesday for him.

I swear he should have been working on rocket engines and not in an oil refinery, but he was never exposed to the possibility.

He expresses sometimes how he wanted each of my siblings and I to have a trade each unto ourselves, yet fails to understand that what I do can factor into that as much as carpentry, welding/pipefitting, plumbing, or otherwise. It's funny... savant-like.

Anyway, in short, I agree. :)


> We've been conditioned to believe that trades such as plumbing, carpentry, construction, etc. are beneath high IQ people

This is a rational reaction, actually.

The problem with he "trades" is that they are often very physically demanding and take a great toll on your body over the years. They also often have a very high potential for debilitating injury.

A 70 year old programmer is no longer rare. A 70 year old tradesman is a unicorn.


But when you interviewed for this plumbing job, were you asked to explain in detail Bernoulli's principle of fluid dynamics? I think the author's point is ridiculous academically heavy interviews when the actual job is boring ass CRUD.


> Let’s go back to the plumbing example. Imagine you owned a small restaurant with one bathroom and 10 employees. You get a few hundred customers per week and maybe 10% of them use your bathroom. Obviously, you’ve got to have a working bathroom, but does it need to be anything fancier or more advanced than your home toilet? Do you need 10 stalls, motion-activated faucets, Dyson hand dryers, and marble counters? Probably not, unless you’re just trying to project some facade of success.

This gave me the impression he hasn't really thought through what he is saying.

> Just as a good small business owner should hire a humble plumber who knows the standard tools required for small bathrooms, and will pay him market rate, a good engineering manager should hire humble team players who use industry-standard tools to build reliable software, and pay them market rate.

This furthered my sense he hadn't thought through what he was saying.

> Part of the problem is that we over-engineer the software we work on. I am guilty of this as well.

I have no idea what he's getting at here.

> “Oh, so you’re building an app? Does it use AI? Blockchain? ? Take my money and do it!"

Unfortunately investors these days love to hear that. Devs who bring these skills are most definitely adding value, even if the author deems it largely superficial.

> Finally, don’t get comfortable. This isn’t a popular opinion among software engineers, but I believe that many in the field are overpaid relative to the difficulty of the work they do. Sometimes it’s because they are the only people who know some obscure corner of their field, sometimes it’s because their company’s gatekeepers are preventing full access to the talent market, and sometimes it’s because other engineers insisted they overbuild things such that junior devs will take a long time to understand it.

Should plumbers not get comfortable too? At this point I think the author forgot what he was writing about.

I'm not trying to be mean. I was just trying to add value to an analogy I had trouble distilling value from. I am speaking from frustration at seeing comparison here and there lately in developer communities.

To answer your question, I've never been asked in detail about complex algorithms for either plumbing or software work. Maybe I've been lucky or maybe I just exude an unnatural amount of competence (I'm guessing it's the former, I have resting dumb face).

Anyway, I don't think gauging someone's level of understanding is unheard of in the plumbing world. It probably depends if you're going for a junior or senior plumbing position.

Edit: some clarification


Yes I agree with what you are saying looking strictly at my own experience as a candidate and as a hiring manager. There's nothing wrong to get slowly to the point where you can ask candidates about complex algos, it just allows you to see how far one candidate can go. The new trands are not supported only buy young people that jump from trand to trand. That was a terrible thought, maybe showing some frustrations?... But I have to agree with the author, many times we have the tendency to overcomplicate a solution for the problem at hand. To keep it simple and stupid and smart it is close to an art. Especially when there pressure to get things done quickly and you havd to keep on improving an existing solution. Lots of levels touched by the ideas in this article.


There's a reason why parts of the Linux community has an event named: The Linux Plumbers Conference :-)

https://linuxplumbersconf.org

A reputed community conference, co-organized by contributors and maintainers of the Linux kernel and related low-level "plumbing" utilities and libraries.


In the valley to do comercial plumbing you need to join the union and go through an apprentice program( 5 years and 1080 hours of classes) plus there is a lot of plumbing done for hospitals and clean rooms which takes more training and class work. After all of that is ready the trades have to work together and organize their schedule to get a given project done.

I don't know if the people making the programing is like plumbing comment realize how highly skilled a plumber is.


You just made me feel inspired in a new way about the job I've been doing for many years. Thank you!


software development is "plumbing" now because many of the common problems have standard and high-quality solutions.

Plumbers don't have to craft their own pipes nowadays because the existing piping solutions are very well understood. It's not as important that the plumber knows exactly how the pipe is produced. They need to know how to set up the interface between the pipes.

Similarly in software, we have high quality solutions to many common problems ("the pipes"). While we do have some people focusing on designing the solutions, in 2018 people don't need to know how to make their own frameworks in order to use one. This reflects a maturity of the industry.


This comment (and the sibling one by eastbayjake) should be higher up responses, in my opinion. It seems like a lot of people in this thread are interpreting "most software is plumbing" to be pejorative. Plumbing is not a high status job, but I don't think that's a charitable interpretation of the comparison.

The other interpretation is that most software engineering work doesn't require significant theory or novel work. Implementing software solutions to theoretically resolved problems still requires skill. Likewise plumbers very rarely do novel design work, but that shouldn't be a judgement of their skill.

I think the statement, "most software is plumbing" is true insofar as most software developers need design novel solutions. There are existing frameworks, libraries and languages for the vast majority of business needs. That kind of maturity is a good thing.


Well to clarify my initial comment, the article uses the word "just" to qualify the comparison:

The Bulk of Software Engineering in 2018 is Just Plumbing

In my opinion it's a bit of a lazy analogy and the author doesn't show any real knowledge of what goes into plumbing or how this analogy provides any value.

Software development is full of analogies that are designed to aid understanding of a large array of abstract concepts. This is good! I just don't see why this "software development is just more and more like plumbing" analogy has become so popular in the dev community. I get what they're trying to say, but it says more about how they perceive/approach their work than it says about either field.

I feel like I could provide just as much value by taking all the points this author made, just replacing the word "plumbing" with "open-heart surgery", but everyone reading my article would be like what the heck? It's almost comical:

The Bulk of Software Engineering in 2018 is Just Open-Heart Surgery

Software is great because you tend to get out of it what you put in. The same is true about plumbing (please don't think about that too much ...). But that's not what these types of articles are getting at.


... but you would be very upset if you'd spent years doing graduate research in fluid mechanics, gone through several interviews where you discussed theory, accepted an offer believing your role would be technically groundbreaking and use your knowledge of fluid mechanics -- then realize on your first day you had been hired as a plumber.

I think this is less a denigration of software engineering in 2018 than it is a denigration of software engineer interviewing in 2018.


Nothing in real life is anything like your analogy. A typical 4-year CS degree is not research-oriented. Asking people to write code on a whiteboard is not "discussing theory".


Reminds me of when Paul Graham's "Hackers and Painters" was ripped apart by a real painter.

http://idlewords.com/2005/04/dabblers_and_blowhards.htm


> ripped apart

I see what you did there


> I believe that many in the field are overpaid relative to the difficulty of the work they do.

I believe that every programmer is overpaid relative to the difficulty of the work they do -- or, more accurately, that The Market doesn't pay based on difficulty of work. Software pays so well because the product scales so well.

Successful pop musicians don't do work that's 100 times more 'difficult' than software engineering. They do work that scales even better (copying digital music; playing to arenas; branding on merch).

Having worked outside the software world, I absolutely do not believe that software people are any smarter, on average, than anyone else. Ever see a plumbing or electrical or structural system fail spectacularly? Other types of workers absolutely need to understand interactions between multiple complex systems, deal with obsolete and incompatible systems, and deal with changing and conflicting requirements and regulations.

If software is any more complex to deal with than physical systems, it's only because the architects and implementors let it get that way.


I'm reading Thomas Sowell's "Intellectuals and Society," and while I disagree with a lot in his arguments and his view of the world, I think he nails a key point about the philosophy behind free market economies. He says that conservative intellectuals don't view inequality and other social tragedies as mainly the consequence of policy, but rather as an inherent part of the human condition. Markets may act as a mechanism that conveys those inequalities, but they are not necessarily their cause. Prices are his first example. Commanding a higher salary doesn't mean you're a harder or even more skilled worker, it just means that you produce something that is judged by buyers (employers) to have a higher positive impact on their well-being.


Funny, I was just reading that same example of his in his book “basic economics”, and it makes sense.

Still, couldn’t you say the same for a feudal structure? That nature has power imbalances, and the role of king only conveys that inequality?

Instead, we’ve intentionally built a more egalitarian system (and we’ve all prospered because of it), seemingly against nature.


That's kind of his point though: that we have managed to get this far, but we shouldn't take it for granted and expect that we can just "turn up the equality dial" and get more equality. These are complex systems and barbarism is always at the gate, because that's the default state. It's not that equality isn't a laudable goal or worth pursuing, it's that it's an extremely hard goal that must be approached thoughtfully and often indirectly.


Interesting point, and well put--thanks.

Maybe there's a distinction to be drawn between "inherent part of the human condition" and the "default state", as you have described it. Attempting to change something "inherent" seems worthless, but default is merely waiting to be overwritten with something better.

For ex: death is inherent in the human condition, we cannot avoid it and must deal with it. Nakedness is only the default state, and is pretty easily solved.

Back to economics: maybe scarcity is inherent, but "social tragedy" may be merely a very solvable default.


Not the best example :). Death seems inherent on the timescales of the lifetime of the universe, but on our timescales, it's merely a default. There's nothing in physics or biology saying we can't solve that; it's just an extremely difficult challenge that we didn't solve yet. I mention it because if we classify it as default, not inherent, it means we can and should be doing something about it.

But keeping appropriate timescales in mind, I agree with the conclusion - for given constraints, there are things that are inherent and not worth attacking, and then defaults that are merely attractors for the system state.


> I mention it because if we classify it as default, not inherent, it means we can and should be doing something about it.

Should? You're assuming that mortality is a problem. Extreme longevity or immortality would certainly change the human condition, but it's purely speculative to think it would be better in some objective, widely-accepted sense. Not every "default" is something waiting to be fixed.


Eliminating the biggest cause of sadness and suffering (not to mention, economic loss) sure sounds like something that would be widely accepted as good. There's a reason why almost every religion offers some kind of afterlife.

There's a good argument to be made that the assumption of mortality is baked into so many things in our economy that it would break down if people suddenly started to live much longer on average. But that, again, is a default - some state attractor. Something we can try to work around.


I respect your point of view, but I disagree with you. I suspect that people in general would be divided on the issue -- and the 'pro-death' faction (!) have not merely accepted, sheepishly, the limits of our existence without any reflection on the matter.

As a speculative anecdote, imagine spending ten thousand years missing a child who died in an irreversible accident. (Would childbirth even be permitted in such a future? How would overpopulation be addressed?) Or the dampening economic and sociological effects caused by a millegenerian population's entrenched resistance to change. Or the possibility that longevity is only available to the wealthy, or the drudgery of being stuck in a boring job for millenia...

Longevity doesn't necessarily solve sadness, suffering, and social ills -- it just shifts the goalposts.


Why do we have to take for granted that equality is even a worthy goal? Raising quality of life for everyone would be... Like if someone making 80K today has the quality of life of a millionaire from a few hundred years ago, then isn't that notable? Why would it even be reasonable to try to get the same outcome for everyone? It's like a function that concatenates diversity - what leftists claim to love - but their principles, like equality, don't produce it!


If you’re on the receiving end of a system that, systematically, hurts/kills you, your family, your community, and culture, storming the bastille or marching on washington or whatever for equality probably will suddenly make a lot of sense.


That's also equality of opportunity - which we have. Do you have evidence that we have no equality of opportunity, or that I am simply trying to pass-off equal opportunity with equal outcome? Acting like we don't have equality of opportunity, and then promoting equality of outcome is intellectually disingenuous.


You don't have to take it for granted, although I would suggest that equality of opportunity at least is fundamental to the American conception of liberty. That said there's not any reason you have to agree with it, though, or with any broader notion of equality. My point was simply that Sowell's arguments don't exclude it as a goal for those of us who do believe some form of equality is a laudable aim.


Did you purposefully parse my words incorrectly? It is very common to confabulate equal outcome with equal opportunity. Do you understand the difference? I was certainly talking about equal outcomes.


> we’ve intentionally built a more egalitarian system

More egalitarian in the sense of opportunities, yes. But that doesn't mean it will be more egalitarian in the sense of outcomes. The disparity in wealth between the poverty line and Bill Gates, for example, is probably larger than the disparity in wealth between a serf and a king in feudal times.


We represent a lot more power as money now. In the feudal system most power imbalances were not assigned a number


> We represent a lot more power as money now.

I'm not sure that's true. While, as I said, the disparity in wealth between Bill Gates and the poverty line is much greater than that between a king and a serf in feudal times, the power disparity between Bill Gates and a person at the poverty line is a lot less. A feudal king could command all sorts of things of serfs and exert all kinds of power over their lives that Bill Gates can't command or exert over anyone. So Bill Gates' money does not represent power the way a feudal king had power.


This is far too celebratory of markets. Markets pay for things that people of means want. If I make a useless toy that delights a rich person I am paid lavishly. If I make a useless toy that delights a poor person I get next to nothing.


> Markets pay for things that people of means want.

No, markets pay for things that are worth more than it costs to make them. Only a very small fraction of those things are useless toys that delight rich people.


This is a bit of hyperbole; desire and need are direct contributors to "worth" because you can extract more profit for it.

That being said, profit is a notoriously crude way of measuring utility, given that a lot of tragedy-of-the-commons type problems don't have "profitable" solutions without some type of government intervention. (See: pollution, public education and health, childcare, working week limits, etc.)


> profit is a notoriously crude way of measuring utility

There are no non-crude ways of measuring utility among different people with different, often incompatible, preferences.

> a lot of tragedy-of-the-commons type problems don't have "profitable" solutions without some type of government intervention.

They also don't have good solutions with government intervention, because the downsides of government intervention (regulatory capture, increasing power of the state, micromanagement of all aspects of people's lives, political power being used to benefit some instead of all) more than outweigh any increased benefit in a particular area.


> desire and need are direct contributors to "worth" because you can extract more profit for it.

Yes, but everyone's desires and needs count in a market. Only the politically powerful's desires and needs count when the government intervenes.


The word "worth" is muddying the waters here a bit. Markets pay for things that people of means will pay for more than it takes to create them.


> Markets pay for things that people of means will pay for more than it takes to create them.

Markets pay for things that people, period, will pay for more than it takes to create them. There's no restriction to "people of means". But yes, the word "worth" can be misleading if it's not understood to imply having something to trade (almost always money in today's economy) that the seller will accept in exchange.


The viewpoint, IIUIC, is that rich people and poor people will exist regardless of whether markets exist. There's pretty ample empirical evidence that this is true: rich people and poor people existed under feudalism, rich people and poor people existed under fascism, and rich people and poor people existed (de facto if not de jure) under communism.

What markets provide is an information-carrying mechanism to determine how you should allocate your efforts to get some of that wealth. If you're poor and want to be rich in a market economy, make a useless toy that delights a rich person. If you're poor and want to be rich in a communist economy, suck up to the party bosses. If you're poor and want to be rich in a feudal economy, you're fucked, because that useless toy that delights a rich person is his by divine right.

While all of these systems still have rich people and poor people, I would argue that the former leads to much more socially desirable outcomes than either of the latter, because at least the rules of the game for how to become rich are stable and well-known and the side-effects of the wealth-acquisition process are beneficial to humanity (or at least to that one rich person, but that's better than them being outright negative-sum, like when the way to get rich was by conquest).


If you’re poor and want to be rich in a feudal economy, get titled by participating in a war, seize property in a war, buy a minor peerage, marry a child into a peered family, become a merchant. This is all date- and location-dependent, of course.


This argument rests on the idea that inequality is equal across systems and that no system attempts to set a floor on how far you can fall or a ceiling on how far you can rise.


Are you talking about relative (ordinal) inequality, i.e. who is above whom" on the social strata? Or absolute (cardinal) inequality, i.e. how much more* do people above you have compared to you?

I would argue that the former is self-evidently equal across systems. By definition, if you're speaking in relative terms, for you to rise up the social strata someone else must fall.

I would not argue that this is true in absolute terms - measured in your country's currency, it seems empirically true that certain systems (in particular free-market corporate capitalism) lead to much wider disparities in wealth than others (say, communism). However, I'd argue that if you actually care about absolute wealth rather than relative wealth, this shouldn't matter to you, because the median person in corporate capitalism does far better than even the wealthy in communist countries (we discovered this in the early 90s).

There may be hybridized systems that can still generate adequate absolute wealth while capping relative disparities. I'm skeptical of many of the examples that are often cited, though. IMHO unionized capitalism actively failed during the 70s; people like to blame Reagan or Wall Street for the dismantling of unions & pension plans, but the competitive reality is that the companies that made up this system all went bankrupt because of foreign competition, not because of any particular policies. That's a failure to generate adequate absolute wealth; you can't ignore the existence of outsiders who follow a different system when judging the sustainability of your own system. European-style socialism is intriguing to me, but may suffer from a similar problem: it's unclear to me whether the EU can a.) hold together and b.) avoid getting conquered militarily by outside powers in the absence of the NATO security umbrella.


I didn't "celebrate" them at all, I just said that in a market system a purchaser of labor pays more when they determine some skill is worth more to them than another skill.


I don't think fidget spinner relied on the rich for it's success.


What do you think of cigarettes and other tobacco products?


>Inequality and other social tragedies

Poverty is a social tragedy. Inequality is an inevitable consequence of choice.


Perhaps not a direct consequence of choice, though. Certainly whatever poltical and economic system we choose has implications for inequality, but it's not simply a matter of "we choose to have less inequality –> less inequality." Redistributive choices have complex interactions and results.


I read that less as "inequality is a choice", but rather as "if we allow choice, there will be inequality".

So you can't easily choose to have less inequality, unless you also choose to eliminate almost all (other?) choice.


Exactly what I meant. I mean, you could still permit some choices, but they couldn’t meaningfully influence outcomes.


Right. Intuitively, it is obvious that political choices impact inequality, as does perusing world data sorted by GINI coefficient, or even just a review of the US over time.

I do find it darkly funny that so many folks seem to throw up their hands - it is obvious that inequality will always exist, so just live with however much we currently happen to have and shut up about it. (Inflation, however - we can totally micromanage that!) Humans have an innate sense of fairness that becomes offended at some point, and they start punishing even when doing so harms themselves. The peasants get restless at some point, the tumbrels come out, and there's your natural law in action.


Sure, people do that, but you're reading things into my post if you're implying that that attitude exists anywhere in it. I didn't say anything about throwing up our hands, and as far as I can tell neither does Sowell.


Apologies if I gave that impression - I wasn't trying to attribute that to you (or Sowell). Just riffing off your comment.


Some people are more influenced by fairness. Some people are more influenced by their desire to compete and win. Both are built into humans. Don't judge the whole humanity by your personal temperament.


Ironic bit of advice there, given how personal you're making things. I'm talking about behavioral phenomena that's not even specific to humans. But since we seem to be advising each other, don't personalize things so much; the world's bigger than both of us.


What I mean by choice is that as long as people can make decisions that affect their outcomes, people will experience different outcomes.


Which choices lead to inequality, and by whom?


Choices about what profession or business to go into, whether to buy things and how much to pay for them, what goods/services to provide and how to provide them, etc.


Or choices about the socioeconomic status of your parents, or your intelligence, or the country you are born into, etc. There is nothing unjust about inequality, because in a free market universe, everything is a choice and being left holding the shorter straw is due to your choices.


Sure, a variety of factors lead to inequality, some of them unjust. It is those unjust factors, not the inequality itself, that must be eliminated.


"Justice" is the ultimate social construct – that everybody constructs to his or her needs.


it just means that you produce something that is judged by buyers (employers) to have a higher positive impact on their well-being

My partner is a nurse, she gets payed peanuts while daily ensuring that people don't die. Literally.

What judgment exactly is exercised to have life saving jobs be payed order of magnitude less than "plumbing" jobs? The argument of "higher positive impact on their well-being" is laughably naive.


Your question here was one of the biggest open questions in political economy (now just economics) in the early 20th century. It motivates the modern foundation of the field, and earned itself the moniker the marginal revolution https://en.m.wikipedia.org/wiki/Marginal_Revolution

It resulted in an explosion of theoretical and empirical literature in microeconomics, and in many ways creates the field we know today.


Supply.


You are wrong - the supply of corporate software developers outstrips the supply if qualified nurses - in London at least.


Then it smells like an ineffective market, compared to software development. Let me guess, which one has more red tape, regulation and government involvement?


It's always those pesky free market saboteurs isn't it?

Consider this - it takes years of formal training to produce a qualified medical professional and pretty much nothing to produce a software developer.


The utility of the software engineer scales with the number of people using software vs the number of patients for the nurse.

If the software engineer is able to provide more utility, this roughly translates to more demand which means higher salary which means higher supply


Doesn't the government set the rates for nurses in the UK? Also you need to compare the supply to the demand. Perhaps more software developers are needed than nurses.


In the past, the ancient past, a great actor would have gotten a measly salary.

Today, Some actors(not necessarily the good ones), get lucky and become filthy rich.

So is their luck an inherent part of the human condition ? or is it the result of technology, TV/Cinema ?

And do we have a right, as a society, to choose how technology will shape us, or not ?


If you’re reading Sowell. I would recommend Wealth, Poverty and Politics. :)


I disagree on several points. A good chunk of why software engineers get paid well is because most people don't like writing code. It's not just because the businesses scale well, it's because it's an undesirable job for most.

Having worked many jobs I also disagree that it's easy, relatively. It's probably not due to IQ, it's because it requires constant thinking. Every other job I've worked is a light mental load compared to software and electrical engineering.

Most jobs you don't think about anything half the time. In hospitality you largely sit around waiting for people. Same with finance and sales in many cases. In HR most of your time is spent sending email, entering data on websites, and attending meetings. Or, your job is to talk to people most of the day, something many find more appealing.

Engineering is 6-8 hours of intense focus and fixing difficult to find bugs. As palatable as doing math homework for most people.

I disagree about intellectual difficulty as well. In school I was a teaching assistant and many, many students simply couldn't put working programs together. Even if you know all the constructs, software engineering is basically building something in your head then tanslating it. I've seen enough people try and fail to build any working programs for 6 months to believe that some people just aren't capable


A good chunk of why software engineers get paid well is because most people don't like writing code. It's not just because the businesses scale well, it's because it's an undesirable job for most.

By that logic, the cleaning staff in your local adult movie theater would be millionaires.


There's a limited supply of people with the education and life opportunity to become engineers, but still the vast majority of those don't despite the pay.


Keep in mind that it's easy to you because you're from that particular field. For a lot of people software development is still basically witchcraft.


So is plumbing.


I had a plumber over for some fixes about a month ago, and he saw me doing some coding on my laptop. He made a comment like "I have absolutely no clue how any of that works... it is wizardry to me". I said "I'm watching you fix plumbing issues around my house, and that is wizardry to me". I think we could probably learn each others' jobs if we really tried, but the point is that all things can seem like magic until you learn them.


In both cases, it probably boils down to shit ton of small and easy things. Each individual unit of knowledge would be trivial for a typical person to grasp, and also mostly useless. Only together they form this large lattice of interlinked concepts that can be used for "doing magic" - but also can't be easily explained.


A random person from the street would be able to fix a small plumbing problem. Water and pipes are well into the normal day to day experience.

A random person from the street would not be able to fix a trivial problem/bug in some software - let's say a missing runtime package on linux.


Having helped people with both software and plumbing problems I am not convinced that "a random person from the street" would be able to trivially tackle any plumbing problem. In my experience random people consider both software and plumbing to be black boxes they don't need to understand. Most people would have no idea what tools to buy to even approach the problem. I have no doubt that with the right documentation and a little handholding the average Joe could figure out a fix for both small plumbing leaks or trivial bugs in software, but it would take much more experience to design the plumbing system in a large building or to architect a new complicated software application.


The parent didn't say any plumbing problem.

I think you wildly overestimate the cleverness of the average Joe. I watch users struggle with basic GUI concepts. Add in learning a specialized language and support libraries? Joe can figure out a wrench by looking at it. He's not going to get very far with a shell prompt.


Sorry, I should have italicized any in my post. As in I don't think the average user can solve any plumbing problem or fix any software bugs without additional resources: documentation and/or assistance.

At least on a command line you can get somewhere with trial and error:

  $ ?
  ?: command not found
  $ what do I do?
  No command 'what' found, did you mean:
  (...)
  $ help me
  bash: help: no help topics match 'me'. Try 'help help' or 'man -k me' or 'info me'.
  $ help help
  (...)
A diy plumber who doesn't know of the existence of teflon tape is always going to have some leaky joints. However, as I asserted, I agree that most people can figure all this stuff out pretty easily, I just think most people are too intimidated or just not interested in trying in the first place.

To put it another way, I've found that the concepts of "hierarchical filesystems" and "drain waste vent stacks" are equally foreign and equally accessible to average laypeople.


I still think you're still off by two or three orders of magnitude of difficulty.

I have no background in plumbing - in fact, as a new homeowner, I just learned what a compression fitting is ($#@%!). I read https://en.wikipedia.org/wiki/Drain-waste-vent_system and... it seems pretty straightforward. I could build this, if perhaps with a few more trips to the hardware store than a professional might make.

On the other hand, I work with databases every day. I wrote ROLAP engines in the 90s. And yet this is probably the first time I've ever used the term hierarchical database in a sentence. If you said "here's this hierarchical database, generate a report for me", it would take me some hours to figure out what kind of db it is and how to actually use it. If you asked a layman I think you would get a blank stare.

Not to belittle the craft, but there's something intuitive about plumbing. Software is something different.


In my experience, most people are too afraid to enter the initial `?` in the command line for fear of breaking something. I imagine many would be afraid to do anything with the rench for the same reason.

Also, people new to programming and command lines are seemingly incapable of reading error messages.


> Also, people new to programming and command lines are seemingly incapable of reading error messages.

Aren't all people seemingly incapable of reading error messages? (ignoring the rouding-error-amount of people who do)


I agree. Plumbing is physical and real - you can touch it and easily observe it. There is no abstraction to it, there are only a few driving concepts (like gravity.) The fact that plumbing has been around for 4700 years and 'computing' less than a century speaks to their inherent complexities.


With respect to their normal, day-to-day experience, a random person - at least from my generation - would be as likely to be able to fix an equivalent small software problem, because they have experience with e.g. reinstalling software, installing missing drivers, etc. A missing runtime package on Linux is definitely not in daily experience of anyone non-technical. For regular people, try with Windows, or maybe macOS.


Parent was comparing software development with plumbing, not general computer maintenance.

Initially I wanted to give an example of fixing a missing include/import in the source code followed by building the binaries as a trivial software development task, but I think we can agree that regular random Joe has about 0% chance of figuring out that, so I toned it down to just a missing runtime package.


Does random person have mobile access to YouTube ? Good chance their is a YouTube video to show them how for both.


I would say the set of possible software bugs is much larger than that of plumbing bugs, not that the latter is trivial.


And plumping is not badly paid either. But it's a trade that you can learn in relative little time and it's a field that you don't constantly have to readapt your approach. someone who learned plumbing 20 years ago is not outdated. meaning that the supply of people who can fix your pipes is far larger than if it would be similar with IT.

and also there are a lot more people around who have the mental capabilities to learn plumbing than there are people around who are capable of consistently apply the abstract thinking patterns that involve software development.


Recently residents were displaced from their apartments for a month due to persistent flooding in their 5 year old building in Seattle. The manufacturer who developed the novel piping technology claims the plumbing system was incorrectly designed and installed.

https://www.seattletimes.com/business/real-estate/pricey-sea...


Wanted to edit this to be more clear.

I think it's just confusing different terms. I'd say the bulk of programming is similar to plumbing - maintaining, resolving issues, etc. But that software engineering is more similar to engineering in general.

A mechanic works on cars, a mechanical engineer would design the components. Much like IT consultants/administrators would maintain systems and do minor coding, but engineers would deal with architecture and new designs and more advanced solutions to common problems faced by IT.


Don't be so sure, Pex and the like wasn't on the scene 20 years ago.


It's also unfair because plumbers deal with buildings decades old - some even a century. They may have extremely old systems and knowledge of that is important.


Where I live in Los Angeles we recently acquired the USS Iowa, a WWII battleship built in the 1930's. One day I was there, going to the bathroom, and one of the maintenance workers happened to be there and we started chatting. Turns out he was a former SeaBee who was there to retrofit the very old saltwater-based plumbing system to connect to the civilian freshwater system so people could use the head in a normal way. A very non-trivial and specific skillset. If you have ever visited a museum ship you can be sure they had people who knew this stuff.


It's no surprise then that plumbing also pays pretty well.


I've done a bit of plumbing and I would say it is much easier than programming. Even basic "plumbing" programming.


I think there is a spectrum of difficulty in both arenas. For instance, I found writing some javascript code to toggle css around my personal website was far easier (and required less math) than sizing the pipes in the house I am designing. That said, I have also worked on much more complicated software projects that demanded more effort on my part. I assume there exist more complicated plumbing challenges as well.


It is easier, but it's physically more demanding (including being far more dangerous).


Well being physically more demanding than programming doesn't say a lot!


Really? Sh*t flows down hill seems to be about the crux of it!


Sometimes the shit flows uphill


And sometimes shit flows downhill but you need it to flow uphill. And sometimes shit that's flowing uphill suddenly flows downhill unexpectedly and in a dramatic fashion, necessitating emergency fixes before developing a better solution in a time crunch.


you don't happen to be a project manager?


"In obscurity lies opportunity"


Job security by obscurity? :)


> I believe that every programmer is overpaid relative to the difficulty of the work they do -- or, more accurately, that The Market doesn't pay based on difficulty of work. Software pays so well because the product scales so well.

...which is another way of saying that writing software is a good use of relatively smart people's time, which is why the market rewards it.


> I believe that every programmer is overpaid relative to the difficulty of the work they do

What?? :D

No and no. People get paid for working on things that take an effort. Nobody would pay you if there was no reason for it. Even the "window watchers" (or how they're called) are payed because they didn't change jobs for 40 years, were loyal to their bosses, colleagues and company.

And yes of course, some jobs take a higher amount of "problem crunching" (whatever that means) than others. In fact sometimes this is the reason certain jobs can only be performed by certain programmers. Most programmer jobs cannot be done by none-programmers.

> If software is any more complex to deal with than physical systems, it's only because the architects and implementors let it get that way.

There are not many fields that are purely abstract, namely that's mathematics, logic and theoretical computer science. Those fields are notoriously difficult, every school kid knows this for mathematics and eventually gets that logic is also a hard nut. This completely misses the point that reasoning about completely artificial entities is an effort by itself. It not only gets harder with complexity but also depending how abstract it gets.

In fact their are even weird limitations that you do not experience in the physical world like paradoxes.


Then any year now, the explosion of boot camps, nano-degrees, and general online courses should start to push the market to equilibrium with people looking to get a leg up, right? Any year now...


> I believe that every programmer is overpaid relative to the difficulty of the work they do -- or, more accurately, that The Market doesn't pay based on difficulty of work. Software pays so well because the product scales so well.

If that is the case then why not hire cheaper individuals to do the same job?


He's saying that it's not about difficulty it's about the value of the output.

There are many difficult things that are worthless in value.

You could be the greatest deep sea underwater basket weaver, that doesn't make your goods valuable. Nobody wants your damp baskets.

He's not saying that programming is easy: he's saying it has high value to difficulty, higher than other more difficult careers.


>Having worked outside the software world, I absolutely do not believe that software people are any smarter, on average, than anyone else

The average CS major has an IQ of around 125[1], meaning the average software engineer is somewhere around the top 5% of the population in terms of intelligence. The average IQ at the top tech companies is probably a standard deviation higher than that. Despite this, the consensus is that the majority of software developers are pretty terrible at what they do.

If you've ever tried to help people learn to code you would realize a good chunk of the population doesn't have what it takes to do anything beyond basic programming. If it was easy more people would do it and salaries would drop.

1. http://www.randalolson.com/2014/06/25/average-iq-of-students...


To use the plumbing analogy, even if most or all of the job will be maintenance, you still want engineers who knows the internals enough to build their own “plumbing” if/when needed. Maybe an apt comparison is how astronauts are trained heavily for the 1% of off script situations that might occur even if it doesn’t happen in the span of their careers.

Companies should feel able to innovate when appropriate by having hired engineers capable of doing so.


I’m not fully willing to accept the plumbing analogy myself. While I do agree that most of our work is CRUD over REST, I think there’s another element of skill that isn’t uncovered in the article. If we are humble plumbers, why does it take me six months to find engineers that understand basic concepts like cohesion and loose coupling beyond a text book level (and I live in a metropolitan area with several software schools!)?

Perhaps a more apt analogy is that we are more like home renovation specialists. If things go well, we can update your plumbing to get away from lead pipes, but if we have to route the new plumbing through a joist, we are going to have to educate you on why we should do something a certain way. If we find a water leak and rot that will put your home (business) as risk, count on us to tell you about the risk and let you decide if you want to address it.

I’d argue that we are simply doing plumbing when things are going really well, perhaps even when the house is small and was well built to start with. If plumbing was all we did, I’d argue that our field would be way more saturated than it is.


>why does it take me six months to find engineers that understand basic concepts like cohesion and loose coupling beyond a text book level

If it's so basic, just hire them and take a day to teach them those things.

WTF is with this trend of waiting 6 months for a hire vs. spending a day to fix the holes in someone's knowledge.


Because someone introduced the term "rockstar" to our profession and we've been addicted to the concept ever since.

An expert is someone experienced and well trained, a rockstar is some inherent quality that's selected.

Our industry needs more of the former.


Cohesion and loose coupling are hard to teach. You need big examples not just to understand what they are but more importantly why they matter. They specifically help you work on systems that you couldn't just read and understand in a few minutes.

If the examples have to be so big, they might as well be real systems. Then you're not being taught so much as learning on the job as you go.

It's accurate to call them basic concepts but you only learn them through extensive experience.


Because it takes way more than a day to fix those holes and instill new habits and ways of thinking and to demonstrate the value of them. In fact, it can take 6 months. Or a year. Or three. And in the meantime you have a developer with bad habits introducing debt that is going to cost even more time to fix down the line.


Because every company thinks they’re Google.


Because of Brooks's law. When you're already working overtime, you don't have a day to fix those holes.


And yet you can afford to wait 6 months to find someone who doesn’t have these holes?

I’d wager actively recruiting for 6 months takes a lot more effort than training someone for one day, for that matter.

As a manager, I find it more interesting to develop someone’s skills than hire a rockstar (and deal with ego issues). It’s more work, and you can’t always afford to do it, but at the end of the day you’ve contributed to fixing the long-term problem by adding one more resource to the talent pool. And it’s way more rewarding, and arguably one of the best uses of your time as a manager.


> And it’s way more rewarding, and arguably one of the best uses of your time as a manager.

I'd say it's also one of the best uses of the time of the more senior engineers who will act as (additional) teachers/mentors.

Having been in the position of needing to explain a concept or even just "show my work" has helped me not just better understand what I'm doing, but sometimes even catch fundamental mistakes in my thinking.

It's also why I like commenting on technical matters on HN. Sometimes forcing myself to articulate my thought to someone else will reveal the absurdity of a long-held assumption, or something similar.


Maybe you (meaning a garage-level bootstrapped startup) don't, but surely not every single firm that's out there is in such dire time constraints.


Agreed. I think the free market argument that "if advanced engineering skills were so unnecessary, some company would scoop up all the underpriced, underemployed junior engineers and make a killing" is a compelling response against the strong version of what the OP is saying.

That's not to say that tech screens are perfect, or even testing the right thing. But they do play an important role: they're an attempt by the company to not give too much responsibility to someone who will use it irresponsibly: whether by accruing technical debt, or dropping tables willy nilly, or by taking down the website.

99% of engineering isn't plumbing. It's pushing back on all the feature requests that can't be done responsibly in the amount of time allotted. It's using your intimacy with the code base and inner working of the company to anticipate problems. It's taking advantage of your prestige as "some smart wizard that makes crazy things happen" to slow down and fix problems before they occur.

Others in the company can't tell whether you're acting like a spoiled brat or doing your job. To them, it's literally indistinguishable. And that's why it's very important to not vest anyone with this amount of authority unless you're very sure that they're going to use it well.


> Others in the company can't tell whether you're acting like a spoiled brat or doing your job. To them, it's literally indistinguishable. And that's why it's very important to not vest anyone with this amount of authority unless you're very sure that they're going to use it well.

I agree with the rest of your comment, but I don't think you're giving non-engineers enough credit here. Sure, in lots of companies, the managers/executives are non-technical, and might as well be managing a packaged goods company. They think software development is wizardry and have no idea what you do. In most tech companies, non-engineer roles are somewhere on a spectrum of technical knowledge that might surprise you. Maybe they've been through dozens more software release cycles than you. Maybe they are currently practicing software engineers trying out a new role. Maybe they co-wrote the standard that you're now implementing. I've seen all of the above in actual companies. Careful about jumping to incorrect conclusions based on someone's title or the actions their role demands.


Ah, fair enough. I should've said "in many cases, the non-engineers will have trouble distinguishing between and engineer contributing to the business in a hidden way and over-engineering things."


Are you suggesting all plumbers should know how to make siphons, valves, or even water pipes from scratch, just in case they ever get into a situation where shops that sell them for peanuts aren’t available?

Yes, you’ll need some people who know how to make siphons and valves, but that some is only a few, and most of them won’t even be plumbers, but work on building machinery that builds siphons and valves.

I think that in most jobs in the modern world, there’s plenty of low-level details that one doesn’t need to know about to do the job.


If your company has 100 employees, how many of them do you think need to be able to handle the 1% situations? The current standard hiring practice is to aim for all 100.


Sure, but having only 1 gets you into the Bus factor.

https://en.wikipedia.org/wiki/Bus_factor


But surely there's a balance. 5 or 10 gives you a buffer and saves you money and time hiring the other 90-95.


Until you hit some weird production bug/issue and 2 out of those busy with other issues, one is working on project with tough deadlines, 1 went to a conference and one is on vacation. I don’t count sick days and other stuff.

Recently I had an issue at work which took a day for my colleague to research and I solved it in several minutes because of some low level TCP knowledge. So the broader/higher skills in your tream, the lower the risks. May be those people (who’s looking for a person for 6 months) are trying to lower the risks.

all edits are spelling, I’m terrible at it.


Obviously this is a bit silly to argue about in the abstract, but if there are a number of different domains where 1% problems threaten the business (AWS, security, random other service is down...) and a senior engineer isn't expected to know about all of them, then you'll need some multiple of 1% of the engineers to feel resilient.

Rough amount: number_of_domains * max(ceil(1% * workforce), bus_factor_min))

At small companies, that may be most engineers. At larger companies, it may (or may not?) level out to a more reasonable ratio.


Not to knock this comment, which makes a valid point, but I couldn’t help but smile at the implicit comparison of software engineers to astronauts when the article is preaching the value of developers thinking of themselves as the “humble plumber”.


You can never have people who actually build stuff think too highly of themselves, lest they start thinking about whether what they're building is actually useful or helpful at all...


Or that what they're building has value - otherwise they'd want a piece of that value in addition to having high self esteem.


The complexity, reliability, and user-friendliness (or technician-friendliness) of the kinds of software components you need to plug together to make a software solution are more like that of a space shuttle or fighter jet than, say, a car, let alone a plumbing fixture.

The glamour (and risk to life and limb) of doing so is that of plumbing.


>"This isn’t a popular opinion among software engineers, but I believe that many in the field are overpaid relative to the difficulty of the work they do."

But no one is paid relative to the difficulty of their job, dummy!


Or actual importance.

It's always a combination of what salary you can command (function of your soft skills) and how much money you can make the person paying you (function of market dynamics).


Good points, but it's also about how much would your replacement cost.


And if people were paid relative to the difficulty of their job no one would have an incentive to make things simple or easy.


People should be paid relative to their accountability.


Overcomplication is sometimes an issue. Remember Soylent, the hipster's Ensure? They were always talking about their overdesigned server infrastructure, even though you could calculate from their sales volume that they did only a few transactions per minute. They could have used low-end shared hosting and CGI to handle that. But no, they had to be a "tech" company. (It looks like they've finally accepted that they're in the food business and are selling by the pallet to WalMart.)

Plumbing has standard ways of doing things, and standard parts that rarely change. Web services need to settle down like that. Really, few sites are doing anything very interesting.


There can't be a similar process of standardization if there is no cooperation between supply actors, and there will not be cooperation if the market is completely open. There is a tradeoff between scalability and competitiveness. If your product can easily penetrate a market without any more than a few tweaks it means it is also easily replaceable, and you'll be competing through non-functional aspects.


He wants to make that case that software development is a more pedestrian affair than it might seem, without much of an argument. But it's not true.

Even a small shop needs to live up to pretty much a global standard, not least in terms of security. In the EU you must engineer with a security perspective in mind. The field is constantly moving. People come and go faster than most other industries.

I think there's an analogy to getting a better bike: it doesn't get easier, you just go faster.


Working at security related company even Fortune 500 are not really living up to "global standard" in terms of security. Smaller shops can't afford proper security solutions and def. can't afford a competent SOC.


Security is a valid counter-example, but, significantly, we are (collectively) very bad at it in practice, repeatedly re-implementing the same old mistakes in each new technology.


I recently got a better bicycle and it got easier and faster. Well lubricated bottom brackets and a new chain makes a massive difference in speed / resistance.


For most projects I've worked on in the past 10 years, the energy has majorly shifted towards front-end development. Building blocks have improved dramatically, but expectations have been rising even faster.

Backends are getting more and more homogenized. There's still a fair amount of work that goes into accurately implementing business rules and a much bigger focus on quality and maintainability than ever before. But there's not a ton of serious thinking involved. I can pretty much follow a script for implementing microservices that will scale up to millions of users. I somehow ended up with a high-paying enterprise architect job and when they ask how we can build a system that will have 1000 users, the answer is that you can do pretty much whatever the hell you want so long as the framework is less than 5 years old and it will be fine. Then I go get a coffee.


Not to be snarky, but this sounds like the viewpoint of a front end developer. One I disagree with. It would be like someone saying front end developers are unnecessary bc anyone can spin up a WordPress site and then go get a coffee.

Can you get a backend going for a thousand users fairly quickly and easily? Sure. But that's the WordPress equivalent of describing back end development. If you have any kind of process based workflow with varying parameters, integration with hardware, detailed reporting / analytics, hell, if you even deal with money or dates/ times / timezones, which is any non-trivial application, backend development gets real complex real fast.

It may be trivial to spin up a WordPress site, but it isn't too put together a solid, reliable React / Redux PWA with isomorphic rendering and offline support. It may be trivial to serve a few API endpoints straight out of the database, but it isn't when you have workflows and processes and states and have to deal with shit like GDPR.

> But there's not a ton of serious thinking involved.

Give a fucking break. The only way this could ever be true is if you only have experience working on extremely trivial applications with no complex functionality.


I'm strictly backend and I've myself becoming less and less useful. Complex requirements are one thing, but implementations just require diligence, not aptitude. I've built loads of apps and sites. Never needed a data structure or algo that wasn't in a standard lib. Most complexity is in integration. Most of my co-workers have no formal CS education and are at no obvious disadvantage.


>Never needed a data structure or algo that wasn't in the standard lib.

Either your definition of algorithm is absurdly narrow, or you are working on some very simplistic problems.


Little bit of both. But essentially the problems are getting simpler. All sorts of problems that used to occupy a lot of my time early in my career are now effectively "solved" and just need a library or SaaS to plug and play. CMS, e-comm, analytics, CRM are all pretty push-button at this point. Maybe some API calls to be made. I remember once needing 3 people spending a month trying to get SSL certs installed on a load balancer. Now it's a checkbox.


>But essentially the problems are getting simpler.

The same could be said about you and someone who started their career in the late 60s. You probably didn't have to write your own OS.

If you were building software that businesses expected in the 60s in the 80s, then your job in the 80s would have been a lot simpler than it was in the 60s. And If you are building the software now that businesses expected 20 years ago, then yes your job is much simpler.

That's generally not how it works though. As capabilities increase, expectations increase, and many times expectations increase even faster than capabilities.


Well, yeah, but my point is basically that work is being pushed up the stack, hence all the energy going into UI development. The biggest challenge for backend devs is usually API Design.


The biggest growth in expectations I've seen are in UI, Analytics, and Security/Data protection. 2 of those are primarily backend, and they aren't something you can just plug in unless you are solving very trivial problems.

And pulling requirements out of business people who don't really know what they want, then turning them into sensible data models that can produce reliable and actionable business intelligence is still where I spend most of my time.


“But there's not a ton of serious thinking involved.”

I guess it depends on what type of backend it is, but I wager the backend of Google, Amazon, eTrade and Twilio require some serious thinking. The backend of simple CRUDs? probably not much


This article has an interesting point. I think the corollary to the point made is that web software, which is what is providing most of the plumber-type jobs this article references, has reached a point of maturation where certain solutions have been accepted as best practices. This lowers costs for businesses and lowers the barrier to entry of the web software industry, which I think of as generally good, but it also cements the positions of certain organizations that are foundational to the infrastructure on which these best practices are built.

The saddest part about this for me is the realization that there is little room left for truly innovated web technologies that have real impact to businesses. Of course there are counter-examples to this (I would count WebRTC, WebSub, and a few others as having potential to impact some usecase specific best practices) but the majority of new software I see being hyped is either a new implementation of an old idea (React and Vue for FRP on the front end) or something touting decentralizing as the next major step which so far hasn't proved itself valuable in a commercial sense.


It also doesnt help that building valuable software these days requires lots of data, especially if you are doing any machine learning.

And most startups lack any data. its all owned by the monopolies of Google, facebook, Amazon and Apple. So the rich will just get richer, and the chances of startups succeeding in any field is as low as ever.


Makes me glad I work in a specialty (data storage) which provides the parts and tools the plumbers need. Sure, there's a shared grab-bag of techniques etc. that we all use, but it's far from plug and play. While the market for people like me will never grow anywhere near as big as the front-end plumbing stuff, demand and pay have been much more consistently good for the last couple of decades and are likely to remain so for a while.

My advice to new software engineers is to get into one of the more "boring" specialties. You might not be in the lottery for the really big bucks, but you probably weren't going to win anyway. There will still be plenty of interesting and fun challenges, with greater stability and (TBH IMO) more mature coworkers.


Genuinely curious - can you give me some examples of these specialities where one can go deeper? In am in this boat now where I have worked on pretty much on all layers of the software stack and I want to now narrow down my focus.


Some of these map to classes you might have taken in college - compilers, databases, AI, etc. I'd divide operating systems into more than one part:

* Core kernel (schedulers, memory management, virtualization) * Drivers * Filesystems * Networking

Then there are some specialties that cut across more than one of these - high performance computing, financial tech (not even counting blockchain stuff), security engineering, performance engineering. Then there's a whole world of embedded stuff, from teeny-tiny microcontrollers up to high-performance medical imaging or genomics, plus large distributed systems to control things like military equipment or nuclear power plants.

Really, there are so many different kinds of computing that we just never even hear of on a site like this. It's really the web/app/mobile front-end stuff that's a niche technology-wise. (On my less charitable days I'd call it a ghetto.) It's a hugely profitable niche, to be sure, but to me it still seems to get a disproportionate share of attention and funding compared to other stuff that's just as hard, just as fun, and just as important.


This is a good way to offend most developers since most like to see themselves as rocket scientists instead of plumbers. But I have to agree, it's MOSTLY plumbing. Thus the reason we see people argue, "Don't make me leetcode during an interview bro! Who ever implements their own algorithm these days?"


I asked that during my last interview but it turns out the job actually is a lot of new algorithm development, which is fun and challenging.


Lucky! What kind of role is it?


Helping to write a sort of compiler for a new chip architecture.

The previous job I had (I've only had two programming jobs - used to do engineering) also wasn't CRUD - it wasn't as algorithmic but it did involve lots of low level USB programming which was interesting.

Are non-CRUD jobs really that rare? Surely if you don't want a CRUD job just find a company that wouldn't need to write any...


I agree that most development doesn't require sophisticated research quality abilities. But that has little to do with what you're talking about.

Leetcode style questions are valuable for testing a recent graduate on his textbook knowledge, not for what you imply.


Beyond the ludicrous nature of the authors sttatement, a look at his Linkedin shows that he is a non-technical CTO. IE: A CTO who has has never really worked as an engineer for an extended period of time and din't come from that background. Thus, consider the source and move on...


I think the article is quite right, and David Graeber made a similar observation when he talks about bullshit jobs (companies would rather hire someone to tapeduct the system rather than redesign it).

But I feel part of the problem is that the companies want to rather hire a plumber (I mean, software engineer) than to buy an off-the-shelf solution. It seems to me that off-the-shelf solutions are very costly and many companies think they can do it cheaper if they build it themselves. Which to me sounds like that the market is not functioning properly, for whatever reason.


> But I feel part of the problem is that the companies want to rather hire a plumber (I mean, software engineer) than to buy an off-the-shelf solution.

Consider Rosenberg’s Law:

  Software is easy to make, except when you want it to do something new.
  The corollary is, The only software that’s worth making is software that does something new.


Never heard this before, and a quick Google around doesn't turn up anything - what's the origin of this? I dig it.


It's from Dreaming in Code [0] by Scott Rosenberg.

[0]: https://www.amazon.com/Dreaming-Code-Programmers-Transcenden...


Right on — thanks!


This is exactly the trap companies fall into. They see a solution ready to buy and think, "Oh we can build that ourselves for cheaper." The thing is, they can't. I worked in a niche of the medical industry and we saw this so much we made a white paper on it. The number of times people decided to build something themselves and came back to us in a year was amusing. They don't realize:

1. The amount of man hours necessary to build a reliable, effective system.

2. The expertise and insight needed to make it actually solve the problem.

3. The ongoing costs of maintenance, adding features, and support.

So, in my opinion, it's not that the market isn't functioning it's just that most companies are delusional about what it costs to build a complex software tool.


Well...yes and no. For example, page scraping is something I have been pricing recently. The companies I have spoken to cost WAY more than it would cost me to build...because I need one simple solution with limited accuracy...but their company is built around an advanced high accuracy solution. The off the shelf thing is rarely the simplest thing possible, because once they built that they had to keep adding features and engineers and costs :)


In the area I'm most family with, (business applications), many, many systems/applications are basically relatively simple CRUD apps with reporting and dashboard features, and maybe a bit of work flow management.

With the rise of low-code tools/platforms, building such apps is almost trivial. So, the make versus buy decision is not as straightforward as it once might have been, especially for companies who already might have developers on staff.

*Edit: typo and clarity


In many cases, for an off-the-shelf solution to work for you, you need control over it. You need to be able to change it. So it is required to be open source. I guess most off-the-shelf solutions aren't.

Also, to be able to change the solution, you need to find one with just about the required feature set. In other words, you need a solution with minimal complexity that fulfills your needs. Because otherwise changing quickly becomes too painful.

On top of that, trying existing solutions and finding out why they don't work for you is not fun. It's much more fun to explore the solution space on your own.


Open source isn’t a silver bullet - if the library isn’t updated frequently, or has some bugs in design, it can be tough to get them fixed. Maintainers tend to be very protective of the codebases they steward too.


Support is a big thing as well for business software. When you buy "off the shelf" package from commercial vendor a large chunk of the cost is usually in support contracts.

If you have a bespoke system built from open source components it can be difficult to find people able to support it.

I think there are pros and cons to both approaches. Sometimes it can be frustrating trying to shoehorn the vendor supplied peg into your business's particular hole.

I've heard a lot of people over the years complain to my manager "XYZ is crap I could write a better solution using ABC" the reply is usually along the lines of "Yeah but are you willing to spent the next 10 years supporting it."


Yes, I agree with GP that open source is often necessary. I agree with you that it is also not always sufficient.

So companies do what they can to have the necessary control and also sufficient support: build it themselves.


I see this a lot. Large companies buying large expensive solutions that do very little of what they need. Many would be better off building themselves.

Smaller companies leveraging existing products makes more sense in terms of budget and team size.


> many companies think they can do it cheaper if they build it themselves.

Sometimes it seems this is because someone who is more interested in building it themselves than doing more mundane work tells them so. They have no way to know for sure if it will be, and often it isn't, but the prospect of cheaper sounds good.


"Just Plumbing" is not really an apt analogy.

Because, judging from all the people I've been working with throughout the years, it's amazingly difficult to write a clean, cohesive, maintainable, scalable CRUD app that will actually satisfy your customers' demands.

Making things that work is easy. Making things that work well, that's another story. And it's the reason why there's so many open spots and high salaries for senior web devs who can deliver.


Installing a toilet is easy. Planning/creating the infastructure for a large building complex is another story :)


"The Bulk of Software Engineering in 1XXX is Just Plumbing"

When was it not?

What were these guys thinking?

The vast majority of software is taking real world applications and dealing with the 'kind of a mess' of situations that can arise.

Even login/credentials can be a minor pain.

Doing it clearly and succinctly is the challenge.

Though it's often more 'solving problems' than 'building something' we should maybe think of ourselves more as construction workers than research scientists.

Upon graduation my skills were filled with so many holes I suggest that every CS grad takes a 3-month long 'power course' wherein the get all the basics, best practices and common tooling down.


The writing has been on the wall for at least a decade. I remember hearing about how programmers would be more like plumbers all the way back in 2008. Sure enough, that really has come true for a lot of developers.

But I agree that this is good. The job is just changing. For example, maybe you wrote a custom DAL back in 2010. Now what you likely have is a mess that you have to pay several people a senior salary for because they are the only ones who understand how it works. Meanwhile a general purpose plug and play solution like entity framework is ubiquitously understood among .net developers. So now we don't need those "senior" DAL guys simply because they understand the mess they helped create a decade ago (also, about the last time they read any books).

I see it as more a levels of software development thing. low-level > medium-level > high-level > plumbing.


Yeah, in a way it is the curse of "open source": there are so many libraries and tools freely available that the only problem left is to tie them together.


I have no problem when getting paid engineer job when I'm just doing plumbing :-) but the problem is when I go look for a job or interview, there is literally no job ad for software plumber so I have to pretend to be engineer.


I constantly have this feeling: software development as a job, relative to the amount it pays, just feels ridiculously easy most of the time. Churn out some API that takes data from one place and exposes it in a slightly different form over here, write some unit tests and docs, done.

Then other days I'll spend an hour doing nothing but thinking, staring out the window, trying to figure out the best way to do solve some complex multi-threaded issue, before writing any code, and I feel like a real engineer again.


I have to be honest - I don't see this. Maybe I'm lucky.

My current company is basically creating Microsoft Office on the web - because for the targeted niche, Microsoft Office (Google sheets, Libre office) wasn't cutting it. There aren't libraries for that.

My previous company was applying machine learning to the twitter firehose, and present the results in real time. The existing libraries weren't up to the task (or the volume).

Before that, we built tooling to allow ten people to administrate 40 plus companies' on-premise databases. There were a few libraries and tools we used, but nothing that we could just "plumb together".

I saw in the Reddit thread that the "plumbing" argument applies mostly to backend developers who just put REST libraries on top of databases. OK, I can kinda see that, but it's not like the complexity of the programs has disappeared, it was just moved to the frontend. And in a way, that's a benefit to the company (and the employees) - the resources previously tied up in re-creating REST libraries before REST libraries existed can now do other things.

The value of programmers has never been in the movement of data from point A to point B, it's been in the application of business logic to that data.


> There aren't libraries for that.

Sure there is—textarea and http. The rest is just plumbing.

I’m only half-joking. I just don’t see a huge difference in difficulty between business logic and plumbing—they’re two sides of laying out the program, and neither one is more difficult than the other. Both lead to complexity and confusion if you lay out poorly.

I think that if you are good enough at googling, the vast majority of problems businesses are solving have already been solved (or the problems are well-mapped) and you just need to adapt the successful patterns to your domain.


If devs see their jobs as "plumbing" then that is a problem with their current culture & environment.

Most devs should be focused on delivering business/mission value. This means custom code, unique ip, algos, GUIs, etc.

However, the current state of devops has thrown all sorts of engineering challenges at devs that lose sight of the actual value that should be continuously delivered. It becomes plumbing when we get caught up in redundant tasks such as dependency management, tests, logging, containers, runtimes, integrations, cloud provider specifics for scaling/ha/sre, and connecting them all to create "the platform" that is supposed to enable true continuous delivery of value. We end up more focused on this internal platform development even though the tooling is pretty advanced. We still have to configure/orchestrate/manage that advanced tooling, and this, in turn, creates the plumping effect. We greatly underestimate the work involved with all of these things.

It is not plumbing when we are focused solely on the continuous delivery of value. We remain lean and agile, constantly testing a hypothesis and developing our "uniqueness".


Very few developers deliver direct business value or revenue.

For every rockstar dev who gets paid a lot of money to make unique solutions and use his brain, there’s dozens of unsung heroes who do the grunt work reading from docs and setting up plumbing so the rockstar can deliver his value effectively.

These developers are not working in cool languages or solving new problems, and many of them will never do so in their life. They are just expendable workers swinging hammers and writing JavaScript.


But isn't it a problem that most devs are setting up the plumbing vs already being enabled to deliver rockstar/valuable solutions?

i.e I've worked at a large enterprise and we all (product devs & ops) became so focused on our grand platform (continuous delivery, heavy integration with AWS, container orch, all using OSS) that product development stalled. Though we were doing "rockstar" things with cool tech and our resumes have a bunch of cool words, but it's true that most of that work was plumbing. In the end that tooling became a bch to manage and continually developing upon. The product continues to stall.

Wouldn't it be better for all if we weren't so caught up in the plumbing of these advance/cool tools? -- that's the thought that actually leads into something like building your own platform, vs something provided. Ops then become more like an overseer sre type of role, and most engineering shifts back to direct value.


> "This isn’t a popular opinion among software engineers, but I believe that many in the field are overpaid relative to the difficulty of the work they do."

This is straight up classism, period. Software devs want to pretend that their high (or even just decent) salaries are due to membership in an elite, highly skilled class. Software development isn't some brain dead job like burger flipping or some gross blue collar job like, ugh, plumbing, right? And there you see the classism raise its ugly head. The denigration of entire job fields. Forcing a separation between "true" developers and other workers also requires denigrating those other workers, how else can "true" developers be raised up higher without pushing lesser workers lower?

A lot of engineering is "just" plumbing. So what? A lot of real-engineering is also "just" plumbing (or the equivalent). So what? Does that mean it's valueless? Does that mean people who aren't in the elite should be treated like second class citizens or that they shouldn't make a decent living for their work? The truth is that people who do "just" plumbing work (whether in software development, in engineering, or actual plumbers) still do valuable, high quality work. Still do skilled work (not that that even matters or is a meaningful term). And still deserve to be compensated well for that work.

Let's stop shitting on burger flippers and plumbers, let's stop trying to define hard class boundaries between some hypothetical elite of "true" highly skilled knowledge workers and everyone else. Let's stop calling for people to be paid less for their work, almost everyone (even software devs) are being underpaid today. It's unhelpful, it's divisive, it's prejudicial, and it's just mean.


Kind of a cyclical theme... but this is why the job titles of "Developer" and "Engineer" were created.

"Engineers" design/build components that perform with repeatable results.

"Developers" work out the plumbing details between components in a system.

When hiring, don't mislead people into thinking they're interviewing for an Engineering role when you actually need a Developer.


I think people need to stop seeing software as punching coloured characters on a screen and start considering it as an occupation that varies widely in skills, wages, and status and distinguish between the blue collar "plumbing" and white collar "architecting" parts, with a smooth array of options between both.

This, of course, is hard if you don't program and it's not really meaningful to evangelise about, so I'll leave off this rant here.


For a recent home remodeling project I paid an Architect $90 hr and the Plumber $130.

There's nothing diminishing about being a Plumber.

"Software is eating the world" means there is more demand for developing systems than designing them.


Yes, I guess developing/architecting are largely orthogonal to paycheck, it's more about the current market forces than the position in this scale.

However, our lizard brain status system still associates directing and leading things with more status than just requirements implementation and there is no way around that yet. Also, less demand means that this more "abstract thought" type of positions are more prestigious by the virtue of scarcity.


eh, i don't know about that one. In most countries outside of America, "engineer" is a reserved word for licensed engineers and Software Engineers can not legally call themselves engineers, thus developers.


One of the greatest personal flaws your average engineer has (I can say this because I fall in this category), is the constant desire to do more engineering. We have a need to make newer, cleverer stuff ad infinitum, whether or not it's needed, whether or not it's even useful. This is why there are so many frameworks, this is why people make their systems scalable before they need to be and bloated beyond their use case. We like shiny toys and we like to use them to make more shiny toys. It's hard to be someone with that mentality when most of the major problems in your field are pretty much already solved.


The transformation of the software profession into law is progressing. As we engineer most moderate-difficulty tasks away, what remains is the trivial or the challenging, and these two classes of task correspond to the peaks of the new bimodal salary distribution. We have a glut of people in the field capable only of the former class of task, so that peak is going to rather low.

This dynamic isn't speculative. It's _exactly_ what happened to law. It's what happens to any field that goes through a boom and attracts a certain kind of person who's more motivated by immediate financial reward than talent or passion.


What exactly did happen in the field of law? Split into lawyers / paralegals?


The bulk of IT is certainly data plumbing. The question is what the engineering part is of the total. Compare with physcial logistics, you have the lorry drivers, the mechanics, and the engineers that develop the next lorry model. There will always be a need for tools and algorithms to work on the data in innovative ways. That is probably where the engineering skills are the most essential. But these jobs are likely fewer than there are people wanting to think of themselves as software engineers.


100%, we're Dell - we grab the bits from the different manufacturers, design a motherboard that connects it all in a way that ideally keeps them from falling down unexpectedly. Sometimes we make a custom doohickey. Probably not though. And if we do, maybe we shouldn't. That is, until you get to a certain scale. As you get bigger and bigger, it makes more and more sense to roll your own of everything to squeeze that last little bit of situational performance.


If what we do is plumbing, then what we're pumping is salt water. Some of us get to build better pipes.

Software in 2018 is better built than in 2008 for a lot of sectors. In 2028 I expect our pipes to be more robust. I also expect a single engineer to be able to do the plumbing 5 developers do now. At least with the right technologies.


After reading a number of comments...

I wonder if we in the tech sector tend to romanticize the trades. I don't necessarily disagree, but would only offer a caution: Look at their hands. I had a new screen door installed on my house, ordered it through Home Depot, and they contracted it to a father-son business. The father was not much older than me (mid 50s), but was broken and hobbling.

There's also a widespread view that we will always need tradespeople, e.g., to build houses. But the trades are being replaced by automation in subtle ways that could eat away at their livelihoods bit by bit. Examples include plumbing fittings where you just cut a plastic tube and squeeze it onto a fitting, rather than sweating it together with a torch. Another is the ability to design and order a "custom" house that's built in a factory and assembled on site.


I think it's a form of overcompensation. We all know deep down that we're pampered and privileged and frankly not contributing as much to the world as we're taking out of it. Thank you, supply and demand and barely-free-enough markets! But instead of just accepting that and making our peace with it, many of us try to make up for it with our choice of sports, hobbies, or accoutrements. There are way more techies obsessed with martial arts or brewing or sports cars than even other demographic factors such as income would predict.

I think it's the same with trade and craft knowledge. Any techie with any exposure at all to the more traditionally "manly" trades (I'd include things like military/police work or firefighting here) tends to flaunt it as a way to show that they're more worldly and "authentic" than all those other techies who have never known any other life. I used to do it myself, except that my "trade" was the simple one of actually being poor. Then I realized that it was just another kind of virtue signaling, and it lost its appeal.


Most people who buy SUVs don't drive off-road. Most people who buy diving watches don't dive. They do expect those things to perform if pushed to those lengths though.

It's possible the same mentality carries through when hiring programmers. I'm not sure it's a problem either.


If software started to become as reliable as PVC piping and standardized and regulated by a governing body like it is with plumbing, then all your problems are solved. Until then, keep learning and make sure your engineers aren't over-engineering the crap out of everything.


I don't feel the author is belittling plumbers or is saying software engineering in 2018 is less glamorous. I think the point he was getting at is that lots of software engineering recruiters and employees treat software like we are making the next PageRank Algorithm or inventing the next rocket. He is pointing out that today lots of what we do is using the already built software to create new things. This is ok, this is still hard, this is still worth a lot but we need to work on our perspective, both for hiring and also for job expectation.


But it's not just tech / engineer hiring that has this problem. Add on a manager that has peter principle'd out and there are plenty of opportunity to talent mismatches.

That aside, the truth is, the vast majority of what's asked to be done has been done before. Even the particlars are likely to be wheel reinvention.

Mind you, it hasn't happen yet, but an object driven drag & drop (or VR) driven solution / application builder is only a matter of time.

Splash on some AI and the role of engineers not in the top percentile is going to trend to zero


Visual drag and drop application builders have existed for some time. The problem is that as soon as your app needs to go "off rails" which all apps do at some point, you won't have the skills or knowledge to tweak your program with some visual editor tool. And I don't see AI doing anything remotely close to solving for that. You would need to be able to communicate with an AI on a deep level of understanding of business requirements and the AI would also need to understand all the layers of the software stack to be able to produce code with AI that even rivals average individuals. That's something akin to general AI and we are a long ways off if it's even possible.


Yes. There have been attempts.

I see AI as being the collection and resoltion tool. Imaging GitHub with a brain. The current problem is far too much wheel reinvention. Far too much language specific solutions when - ultimately - the language doesn't matter.


So for application development, I tend to agree. Interviewers should focus less on computer science questions and more on application development questions.

But ... with advances in AI / Machine learning, drone tech, and self-driving vehicles, I think there is a growing niche in software development for more serious science / data analysis. Investor expectations are being set more and more by this niche -- and causing regular application developers to have to push the envelope.


Isn't this a description of what IT people and operators are supposed to do? "A bunch of services, set up with a little glue and a lot of configuration," is exactly what ops is about. Customarily, programmers run the show and tell the operators what's needed, but perhaps for a small business it would be best for an operator to act as "software concierge," arranging for new software to be engineered only when necessary or helpful.


The "concierge" idea is a new one that I hadn't heard before. It helps describe a piece that I feel is missing from what it is I feel that I do, because, so often, perhaps because the terms "operations" or "system administrator" don't have the word "software" in them imply that I don't understand it or can't apply engineering to it.

Although I don't feel comfortable going as far as dictating the outcome of some version of the build vs buy decision, I agree that, when I happen to be on staff, tremendous value is lost by not at least consulting me as to what "buy" [1] alternatives are available. As an experienced technology (not just software!) concierge, I often know even more than one.

Unfortunately, by the time I'm hired, it's almost always too late. Especially at modern startups, programmers very much run the show, so the focus is very much on writing new software.

That said, I don't think this notion is unique to ops engineers. It can be extended to programmers, as well, in that very senior ones tend to follow similar models, of simpicity, code reuse, libraries, and, ultimately, eschewing actually writing (especially rewriting) new software unless necessary.

[1] quotes because it's often free-gratis, merely not custom-written there


I once wrote a class called SuperMario that did some plumbing between the database and the HTML template and people didn't think it was funny at all.

Contrary to a lot of comments, I still think the word "plumbing" fits well with connecting specific columns in the DB with specific holes in the template.

Like in real plumbing, you get shit when you connect the wrong things:-)


"Show me your flowchart and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won't usually need your flowchart; it'll be obvious." - Fred Brooks

Dug up this old HN thread about Data First if anyone else is interested: https://news.ycombinator.com/item?id=10291688


Right now anybody working in software (outside of startups) makes an extremely comfortable living. I think we're headed for a bubble-burst as the job market approaches saturation. The "bootcamps" are so successful because you don't have to be a genius to do the plumbing, but you get paid as if you are one. I've considered going back for a master's degree for this reason alone.


i frequently compare workaday web-dev to general contracting (a favorable description from my perspective). no issues with the article title.

here's my issue with the article text: it describes

    I came to the Graide Network and immediately started breaking our legacy app into microservices.
as "overengineering," and perhaps it was ... or perhaps it was just not-great planning. after all, the premise of the article is that the microservices are now incurring costs that can be described more like plumbing than engineering.

here's where some of my experience partially aligns with the article's complaints

    Investors are guilty of pushing it on us
this has happened to CEOs at startups i've been at: [some] investors asked for diagrams, etc., and we made decisions to build invisible fanciness instead of product for users.

here's where the author begins upon the path to enlightenment

    we can build more with less


My employer used to have devs from service based companies working on contracts. Later they started cutting the amount of vendors and hiring good talent with attractive wages. The amount of stupid code I encountered when I joined was ridiculous, now that we have smarter engineers over here, everything works like a breeze.


If you want to be better at building software, pick up one or more of the building trades. There is much to learn about building things from electricians, plumbers, carpenters, and masons. Working with tradesmen and seeing how teams of tradesmen work can be enlightening.

I can't believe this guy said "just plumbing".


Bullshit. Don’t trivialize software development or plumbing. Even a blog is not simple at all. Case in point: there’s numerous bugs on his own website! For example, on my mobile browser his “subscribe” button text is cutoff and misaligned from poor CSS work. But it’s “just plumbing” right?


Engineers are paid to solve business problems, not just "code things" and "create products". I am always perplexed as to how engineers see their own field. You are not there to create some novel framework, unless the situation absolutely calls for it.


"Just plumbing" which requires at times detailed detective work and/or the ability to prove that many invariants hold, all while communicating effectively with several people of different backgrounds.


Funny, I actually been using plumbing analogy all this time when talking to non tech people. Many people think too highly of what I actually did. I too feel like using the word engineer is sugar coating it.


The internet is a series of tubes meme aside, I've felt that a lot of modern engineering, at least tying together REST APIs with web/mobile GUIs to do CRUD, is really just data plumbing. We're just packaging and unpacking blobs of information. That's it.

And the difficulty involved is that we're not yet smart enough to build efficient, easily-adopted systems that use natural language and don't contain a million dependencies and hacky workarounds.


Blunt generalization incoming... it's naive to read this article (similar to the majority of others) as an info-piece. It's a marketing piece, any informational value is a by-product.


>other engineers insisted they overbuild things such that junior devs will take a long time to understand it

Anywhere that I've worked this will get your PRs or architectural ideals rejected.


These comments crack me up. Hacker News readers seem to have a lot of opinions about plumbing, the plumbing trade, the difficulty of plumbing tasks both intellectually and physically, pay scales of plumbers, personal experiences with plumbers, etc.

Did you get that "plumbing" was just, like, an analogy? The article wasn't really about plumbing.


It resonates for a reason. In plumbing everyone understands the difference between what's theoretical (flow rate equations, hydrodynamics, metallurgy) and what's practical (nearly everything else).

Computer science has always had this tension between being an actual "hard" science and an applied engineering discipline. A lot of otherwise intelligent people pretend to understand that distinction when they really don't and it leads to no end of problems.


> Computer science has always had this tension between being an actual "hard" science and an applied engineering discipline

I actually would go much further: I would say that the tension is between an applied engineering discipline and a vocational degree ala, well, plumbing.

I don't think there's much question that fields like quantum computing belong more in the "applied engineering" category (or even the "hard science" category). There's much more question about whether professional software development has any significant relation to the field of Computer Science other than the bare fundamentals.

My hunch in the future is that we'll see the field bifurcate into two very different professions, ala EE and electricians: "Computer Engineering" (or whatever it's called) will become a much more limited field that is overseen by the NSPE and has a licensure system, and "Software Development" will become a vocational degree (if that, even) and represent the vast majority of software development jobs we see today.

That obviously has problems, but I see it as an inevitable compromise that might eventually help resolve questions like, "this set of customer personal data was leaked because of a known but unpatched vulnerability, who signed off on this software release?" and also relives a lot of the pressure on regular software developers to understand these fundamental CS concepts that don't come up much in practice.


Problem is that it was a terrible analogy. Glueing things together can range from easy to extremely hard, plumbing can range from easy to extremely hard, the comparison doesn't tell us anything.

The conclusions he draws are questionable, too. Do you need AI powered search? Well, what if it's an elasticsearch plugin, takes 30 minutes to install, and increases your conversion rate by 5%? Should your engineers be required to know SQL and learn Redis on the job? Well, yes, they should.


Maybe plumbing is more interesting than its use as a metaphor for software.


Be careful with the word “just”. I’ve found that people who use it often are blissfully unaware of the details of things and the work involved.


I find this article interesting largely because it appears to tease out class & elitism.


...that argument has been around for as long as computing itself, and it's no more true today than it was at any point in history.

If the microcosm you're in is CRUD systems, that argument may be valid, but I think the author is overgeneralizing if he equates CRUD to the sum total of everything there is to Software Engineering.

There is a constant lifecycle in this: A new idea is born or first becomes technologically possible. At that point it's very difficult to put the idea into reality, but the demand is so pressing that the market will pay whatever it takes for individuals to live up to the challenge. Then, gradually, it becomes commoditized and, eventually, everything that's left to do is "plumbing". ...but at that point, a new idea will have been born or will have become technologically possible for the first time ELSEWHERE, and the REAL MEN will have moved on to that (leaving behind only the QUICHE EATERS to do the plumbing work).

So, if you've been in the field for a long time, your career path might have looked like:

Writing CRUD systems on IBM host systems in the 80s, when that was still an intellectually demanding job, because you wouldn't have learned programming at university as programming wasn't yet a thing, but you still managed to learn what bytestreams to send down some line to make an IBM terminal show a number in red or green, and you did it in PL/2, a programming language that hadn't yet had a chance to learn the lessons learned from several decades of software systems gone wrong.

Writing some of the first pieces of internet banking software in the 90s. Your employer, the bank, wanted to make damn sure they were not going to make fools of themselves by using this new and unproven technology in a way that would allow funds to be misappropriated. So they paid you handsomely to learn everything you could about telecommunication technology, security engineering, encryption, etc because you actually had to manually code all that as there were no frameworks or libraries for that just yet.

Doing algorithmic trading software in the 00s. Everyone else was ripping databases out of their systems because XML was the future, and the XML was processed by a java programme to run in a virtual machine to run in a container to run in a virtual machine to run on god knows what. Since you still knew how to do real programming for real machines in a way that didn't involve converting your data to XML and back, your software executed orders to buy and sell equity on the world's major exchanges faster than anyone else's, and you were paid handsomely for it!

Doing data science & data engineering in the 10s. Organizations had been run for several decades by numbers-driven people whose computing competence only reached as far as Excel. The numbers-driven mindset did not go away. But the data was now there in such quantities, and stored in such nonsensical ways, that everyone who was previously an Excel-guy now needed one or two of those data engineers at their side. Also, because it now became possible to use the data to answer some pretty complex questions, those questions were now seriously being asked for the first time, and everyone discovered that they had been asleep at university during the lecture where someone explained what a standard deviation was. So that's why you learned everything you could about statistics, machine-learning etc etc. You applied it, and you got paid very well.

So, what really sets you apart if you're not just a software engineer, but a GOOD and SUCCESSFUL one, is that the stuff you're working on is always the stuff that's NOT YET plumbing, because it's a major force right here and now despite the fact that nobody has seen it coming.

...I don't know what the future holds, but I think I'll be well equipped to deal with it, because THAT's what real software engineers do and there's no framework to do THAT.

On a side-note: Stack Overflow developer survey results routinely indicate that like half of the nation of software developers have been writing code for a ridiculously small number of years (like two? don't remember the number now). If you're one of them: The above argument does not include you. You're not a software engineer yet in the sense of the argument that I'm making, above. But don't feel bad about that. Next year, you'll probably switch to sales or become the pointy-haired boss of some REAL software engineers.


Last paragraph is inflammatory, elitist and rather 'Murica'.

Also what is that opinion based on?


It follows logically. The contention is "You're not a software engineer yet in the sense of the argument that I'm making". The "argument I'm making" is that software engineering is about adapting to change. If you've only been in the business for two years, no sufficiently meaningful change has happened yet that you've had to adapt to. I also don't see how it's elitist. Learning to code (from a book, for example) and sticking with it for more than two years is rather attainable and hardly the reserve of any elite. I'll have you know that I have not spent any extended period of my life in America and didn't know what "murica" even meant until looking it up just now.

More

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: