51–60 of 133 posts
Programmers are worth $0 because programming isn't a job. It's not even a skill; rather, it's more of an active literacy. Asking how much you should pay a programmer is like asking how much you should pay a telephone user, or how much you should pay a pencil user.
How did this guy get into YC with his startup? Hands down troll of the year with this comment.
"In the best case the programmer and the company will both think they are getting a good deal." IMO that is far from the best case. That allows "ignorance is bliss" and, at the other end of the malice spectrum, for one party to be taking advantage of the other. I once sold a rare trading card for $50. I thought I was getting a good deal, the other person knew it was worth much more than that and thought they were get…
What do you believe the best case is?
Edit: I should note that this assumes a somewhat unlimited self-interest on both sides. Real people might not take all they can get even if it's offered, and real companies might not mind paying more than necessary even if they're not asked.
Earlier quoted context omitted.
It does not matter whether programming is marketable or not. What matter is that the results of programming, such as Google Search or Facebook, are highly marketable. Mistake number one: never sell yourself. Only sell the result of your efforts, and preferable not to middlemen, but directly to the real buyer. That is how you create hundreds of billions of dollars in value.
You're flooding this comment thread with these posts. A single person didn't build any of these billion dollar companies you're referencing; at some point they had to hire more people, who in turn "sold themselves" by your confused logic, to build the company. Most of these halo companies have non-programmers who were brought in to monetize and grow the value in them. Sheryl Sandberg isn't a programmer nor I think th…
Earlier quoted context omitted.
That's an interesting comment. Do sources for those stats and numbers on how many people leave banking? What about programming? Just searching around doesn't show anything solid up.
In short, the "up or out" policy of banks and consultancies is notorious for having more "out" than "up": https://en.wikipedia.org/wiki/Up_or_out To put hard numbers on it, McKinsey is one of top management consulting firms. According to an employee, its average tenure among new consultants is 2.5 years. https://www.quora.com/Why-are-employees-loyal-to-McKinsey That's consistent with the staffing ratios within the fi…
Betz' law states that there is an upper limit to the amount of power that you can extract from a given mass of moving air (aka wind). The plainest explanation is that the wind has to go somewhere in order to be able to bring in fresh wind. If you extract all the energy then the air would have to pool around the windmill and then eventually the pressure differential would drop to 0 and there would be no more wind. So you give up some of the energy and use it to remove the air after you're done extracting energy from it.
The parallel is that if up-or-out wasn't a fact that these companies would sooner or later run out of room in their org chart to bring in fresh recruits at the bottom. This would stop them from hiring the occasional gem that they will promote to the top of that chart. So to be able to hire the really good people they have to create room at the bottom, they have to get rid of a certain percentage of their people at all levels every year to keep the machinery moving.
It's an expensive affair but in the longer term it makes good business sense. Both windmills and really big companies are extraction devices.
Incorrect. If your company were to pay you the same amount as they profit off of you, you wouldn't be sticking around for very long at that company. That's the basic requirement of your company's mode of production.
>If the ranges of acceptable don’t overlap, it’s worth stepping back and clarifying what glasses people are using to look at the numbers.
Consider my previous assertion. You may come to this conclusion: "it is unacceptable that I don't make as much money as the money I produce for my company." You may realize that the entire economic system is structured that way. Then, you're right that it's worth stepping back and clarifying what glasses people are using.
Programmers are worth $0 because programming isn't a job. It's not even a skill; rather, it's more of an active literacy. Asking how much you should pay a programmer is like asking how much you should pay a telephone user, or how much you should pay a pencil user.
And that skill has a lot of value to people that don't have that skill or are limited by their own time so we get paid for it. Probably a decent number of years will have to pass before we can call programming 'just a skill' akin to writing.
If you're going to put ideas out that are borderline detached from the current reality it would be great if you gave your thoughts a bit more foundation so you're easier to follow, it just so happens that I saw what you meant but I can also understand why someone who is currently a programmer by profession would in some subtle way feel offended if you called their profession (which is a hard one!) the equivalent of a telephone user or a pencil user.
>If I create $1M of value for the company, you can compare my price with $1M. Incorrect. If your company were to pay you the same amount as they profit off of you, you wouldn't be sticking around for very long at that company. That's the basic requirement of your company's mode of production. >If the ranges of acceptable don’t overlap, it’s worth stepping back and clarifying what glasses people are using to look at t…
That's not quite what he's saying.
From the post:
> You can never say a price is high or low without asking, “Compared to what?”
He's saying that his price can be compared to the value he creates, not that the price should be the same as that value. So in this case, if his price was $1M for $1M of value, then any reasonable person would say that the price is too high compared to the value.
Earlier quoted context omitted.
How did this guy get into YC with his startup? Hands down troll of the year with this comment.
Getting into YC doesn't guarantee someone isn't a douchebag.
Calling him a troll and a douchebag is exactly the opposite of what HN is all about. Attack the idea, not the man or downvote and let it go.
>If I create $1M of value for the company, you can compare my price with $1M. Incorrect. If your company were to pay you the same amount as they profit off of you, you wouldn't be sticking around for very long at that company. That's the basic requirement of your company's mode of production. >If the ranges of acceptable don’t overlap, it’s worth stepping back and clarifying what glasses people are using to look at t…
Why is this a basic requirement? Assuming by "amount they profit off" an employee, you refer to the economic profit (that is to say the profit after taking into account of all economic costs, including opportunity costs) rather than the nominal value, then I really don't see why this is a basic requirement.
This really perplexes me especially since the amount the company pays should be exactly equals the amount of economic profit you generate for the company, in a perfectly competitive labour market. Of course, reality is not always perfect, but for the average programmer it's pretty close (skills are quite homogeneous and programming jobs are less constrained by geography).
Earlier quoted context omitted.
> Labor does not receive (or insist on) percent-of-value or percent-of-transaction compensation. This is true of pretty much all engineering jobs, and more broadly, most non-sales jobs. Commission becomes feasible when you can directly attribute sales or billable hours to a specific person. > Initial salaries are good, but there is wage stagnation. This is true for all engineering jobs, and also most jobs in general.…
> 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 o…
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.