Comment by sl8r | Hacker News Reader

Comment by sl8r | Hacker News Reader

Parent Full thread

> Care to name some, besides banking and consulting, and possibly corporate law? I'd suggest that in most fields, you don't make significantly more money until you're managing a significant percentage of people, or tasked with making decisions that set the direction the company.

This is fair / you're right: I was mainly thinking of banking, consulting, law, and buy-side finance. As you say, though, there are plenty of highly-trained professionals who don't experience a 5x earnings increase over 10 years; functional medical roles (e.g., anesthesiologists) come to mind.

Something I was wondering when I wrote the original question -- and I may be way off here -- is whether there are cultural or structural effects in tech-industry programming that cause wage stagnation. For example, there is less wage stagnation for programmers in quant hedge funds than there is in the tech industry; part of this is the clear p&l, of course, but perhaps there is a cultural / structural component as well? I'm not a programmer, but I once heard something that stood out to me: A friend, who was a senior programmer, discovered an inefficient process where he worked. In brief, whenever a certain "event" occurred, the company lost money; the senior programmer noticed this, and built a fix -- no more "events", and hence lots of money saved. From what he told me, my back of the envelope was that by building this (which took him about a week), he saved the company more than $600k a year. I mentioned to him that if he had come in as an outside consultant with a black box solution and offered to charge $100k a year to save the company $600k per year, there was a nonzero chance they would have said "yes"; he laughed and shrugged. This made me wonder whether there is something intrinsically non-value-capturing going on; perhaps (1) tech-industry programming doesn't have a culture of individual-value-capturing, or (2) the role of a programmer doesn't have the structural leverage to reliably capture value. Of course, this story is just anec-data; there may be no conclusions here.

Isn't this just how employment works? If you build something and it turns out to have been a total waste of time and energy, you get paid all the same. If you build something and it turns out to save the company $600k a year, you also get paid, but the surplus value goes to the company in exchange for substantially reducing your financial risk. You can't have it both ways: if you want to capture more of the value, you need to share in more of the risk.

"whether there is something intrinsically non-value-capturing going on"

If you mean that it's hard to apply value to an individuals labour in programming you are correct, except in some rare circumstances where there is only one guy at work - then it becomes trivial.

Let's look this from the point of view of features and fixes for an individual software product.

For a car mechanic, an unserved issue means the single client may switch vendors (cost, say, 1 k).

For a software engineer, a botched feature may mean that a category of clients abandon the product (cost:1M+).

Ok, from the point of view of catastrophe recovery we know who can save more megabugs.

What about delivering value from new features? The car mechanic doesn't create anything new. Let's take the construction worker, then. This is really bad analogy but hold on.

The construction worker gets plans, builds the house, and moves on. Architecture, engineering and construction are split to separate people, all of whom have a known cost to their labour. Thus, we have a fixed project and a more or less transparent cost structure.

Software is nothing like building a house except in rare circumstances. Real world construction projects are mostly about creating linear combinations of known things.

Writing new software is like playing a combined game of sudoku and mastermind in a dark room - in the best circumstances. Sometimes the lights are on and the board is almost done, and you only need to put one piece down.

But - you can't really tell from outside what the situation is. Is the board ready? Did someone mess up the first steps and now they have to start over?

The whole thing is like a black box with input and output. The only measure of quality and value is that is the customer satisfied with the data coming out. There is no metric you can gauge the work reliably.

From the point of view of the organization the software project is like a black box, into which the team goes to do their work. They yell estimates to the project manager sitting patiently outside, who then writes project reports. After the team declares they are done, the deliverable can be tested.

You can send anyone inside the room, but only software engineers understand whats going on.

Sometimes a new programmer needs to meditate months inside the room before starting doing changes.

Sometimes the black box blows up.

Sometimes the team just goes into the box and cries all day without doing any porgress-for months - unknown to the org.

I'm sure this gets the imagination going - basically, anything that can happen with a black puzzle box and real people can happen.

I'm exaggerating to make a point, of course. But these unknowables make writing software a really risky proposition from the point of the view of the org. And individual can be incredibly productive, or a total failure, and it's really hard to point this out reliably if all are not specialists.

That's why, IMO, personal bonuses aren't really helpfull for software projects and fixed company wide bonuses are the only way reward without creating unfair situations. Any KPI based individual bonus system will at worst be destructive, and at best almost completely unfair.

> Software is nothing like building a house except in rare circumstances. Real world construction projects are mostly about creating linear combinations of known things.

Have you actually built a house before? The plans never quite match up to the reality. It always takes longer than you think, and costs more. No house is exactly the same as another. Every house has bespoke parts to it. Shoddy construction happens often, and fixing the issues that result can cost more than initial construction. And then the customer changes their mind, causing costly rework that never quite fits properly into the initial design. I would say building software is very much like building a house.

Yes, civil engineers use a 30% - 40% fudge factor to deal with those unforeseen costs. They often get the costs wrong, sometimes it's nearly twice more, but those times are rare.

Software developers normally apply a 200% - 500% fudge factor do deal with unforeseen costs. Problem is, they are usually wrong by an order of magnitude or two, at whatever direction.

I'd love to know where to find more information on this kind of thing.

"I would say building software is very much like building a house."

Yeah, it's good to remind that making anything new and not mass produced is always messy. I would still claim that software only goes more insane from that since there are very little constraints to the work and it's less understandable as a whole. House at least is bound to the basic laws of physics. One cannot mess up the local universe so that walking through any arbitrary door takes one suddenly to the toilet. In software, on the other hand, one needs to design the constraints oneself (I'm generalizing again, of course).

Reply on news.ycombinator.com