Why programmers are not paid in proportion to their productivity (2009)(johndcook.com)
johndcook.com
Why programmers are not paid in proportion to their productivity (2009)
https://www.johndcook.com/blog/2009/12/23/why-programmers-are-not-paid-in-proportion-to-their-productivity/
312 comments
People have put in further thought about this and had good insights. A couple examples would be Rao's essay on The Gervais Principle [0] and, much heavier, Bob Jackall's 1988 book "Moral Mazes." [1]
[0] https://www.ribbonfarm.com/2009/10/07/the-gervais-principle-...
[1] https://en.wikipedia.org/wiki/Moral_Mazes
[0] https://www.ribbonfarm.com/2009/10/07/the-gervais-principle-...
[1] https://en.wikipedia.org/wiki/Moral_Mazes
> most management is just bunch of morons busy optimizing for their own success, and no one worrying about any common sense good of the company
That might be true but unless you're the owner of the company or have a significant stake I don't see why you wouldn't do the same as an individual contributor?
The "company" is not some sentient being you owe some compassion to. It's a legal structure with profit as its sole goal. It won't shed a tear if it makes more profit at your expense, so you shouldn't either if you manage to turn it upside down.
That might be true but unless you're the owner of the company or have a significant stake I don't see why you wouldn't do the same as an individual contributor?
The "company" is not some sentient being you owe some compassion to. It's a legal structure with profit as its sole goal. It won't shed a tear if it makes more profit at your expense, so you shouldn't either if you manage to turn it upside down.
> That might be true but unless you're the owner of the company or have a significant stake I don't see why you wouldn't do the same as an individual contributor?
And here you hit on one of the core tenets of a good manager. How to align things so that what's good for the individual is good for the company? It starts with the owner/shareholders and cascades down the hierarchy.
It's a bit of a "tragedy of the commons"-type problem. If everyone optimizes what's best for themselves then the company likely goes out of business, which isn't good for most of the employees.
A good incentive structure isn't going to make a terrible manager into a good one but it can have a big impact around the edges. Including things like "employee retention" in the evaluation of a manager helps to align things - now if the manager wants her bonus she has to treat the employees well and help find a balance between what's good for the company & what's good for the employee individually.
And here you hit on one of the core tenets of a good manager. How to align things so that what's good for the individual is good for the company? It starts with the owner/shareholders and cascades down the hierarchy.
It's a bit of a "tragedy of the commons"-type problem. If everyone optimizes what's best for themselves then the company likely goes out of business, which isn't good for most of the employees.
A good incentive structure isn't going to make a terrible manager into a good one but it can have a big impact around the edges. Including things like "employee retention" in the evaluation of a manager helps to align things - now if the manager wants her bonus she has to treat the employees well and help find a balance between what's good for the company & what's good for the employee individually.
That's correct, but it has to come from top-down. It is unlikely you'll make any change from the bottom (especially as that change would negatively impact your superior who is also playing this game), so you're better off playing the game too.
+1 to this
I ageee managers optimize for their own success, at the expense of the company, but how does that make them morons?
Sure the company is hurt and work grinds to a halt, but are you saying the rational thing to do is take actions that don’t optimize for your own success?
I ageee managers optimize for their own success, at the expense of the company, but how does that make them morons?
Sure the company is hurt and work grinds to a halt, but are you saying the rational thing to do is take actions that don’t optimize for your own success?
I should have been more specific. A lot of them are morons, which is orthogonal and more of a problem than being self-serving. A competent self-serving manager is possibly not best for the company, but might be great to work with (under) and still way better than a moron.
That's a bold statement "most managers are morons". What evidence do you have for this? I've worked with some excellent managers.
It's amazing how often I talk to people with polar opposite views about managers. Some people insist that most managers are terrible. Other people recount bad managers as outliers throughout their career.
I have a suspicion that people who end up reporting to bad managers are more likely to get stuck in companies or career paths that put them under a sequence of bad managers. Perhaps bad management gets normalized in the formative early years of their career and they don't understand that they're in a bad situation or that they should (or even can) move to companies with better management practices.
Obviously, there are a lot of bad employees out there of all job types. Managers are no exception. But the idea that managers are "mostly morons" is a ridiculous, hyperbolic claim.
Whenever I mentor someone who has these ideas, I work hard to try to let them know that bad management is neither normal nor acceptable. Otherwise they just assume their bad situation is normal and that changing jobs wouldn't help, which is not the case with bad management.
I have a suspicion that people who end up reporting to bad managers are more likely to get stuck in companies or career paths that put them under a sequence of bad managers. Perhaps bad management gets normalized in the formative early years of their career and they don't understand that they're in a bad situation or that they should (or even can) move to companies with better management practices.
Obviously, there are a lot of bad employees out there of all job types. Managers are no exception. But the idea that managers are "mostly morons" is a ridiculous, hyperbolic claim.
Whenever I mentor someone who has these ideas, I work hard to try to let them know that bad management is neither normal nor acceptable. Otherwise they just assume their bad situation is normal and that changing jobs wouldn't help, which is not the case with bad management.
> Whenever I mentor someone who has these ideas, I work hard to try to let them know that bad management is neither normal nor acceptable.
A lot of the HR analyses I read on HN are coming from an extremely privileged position and are very US-centric. What you experience in the very few tech hubs in USA is absolutely not what you'd experience literally everywhere else in the world. This is an observable fact if you speak with a lot of non-US contractors. But it's also a fact that's usually not welcome on HN.
Most managers I had in my career were indeed morons in general: self-centered people optimizing only for their quarterly or annual bonus, very plain slave-drivers whose only difference with the real thing is the lack of actual whips, unable to understand simple concepts as "a good manager removes obstacles, they don't roast people", and never able to actually lead and not just cover their own bottom by shouting at people to not miss an impossible deadline, and always seeking to inflate their department's budgets out of fear for their budget to be not reduced the next fiscal period. All of that with very little regard for the actual product and success of the company.
Was it my fault for working with them? I suspect yes. But then again my formative years were filled with fear and dread to not end up living under a bridge (very rough and rocky start in life; don't ask). This has made me blind to my own negotiation power and I made many mistakes during most of my career. So strictly and mathematically speaking -- yeah it was my fault for tolerating morons. But once you control for fairly often-occurring human traits (like a beaten-down psyche) you can very easily see what a huge amount of programmers out there are either too afraid or too burned out to seek a better environment. This is often made even worse by them sticking to one market (country or a business area), too.
One truth that a lot of people hate hearing is: if somebody detects that you are vulnerable in any way, they'll make it their goal to turn that against you. There are plenty of such piece of sh1t people out there and many of them are HR or managers. I know this doesn't conform to the touchy-feely world view that many have and that's why it's not a popular thing to say.
Glad your own experience is the opposite. Wish mine was too because overcoming the negative inertia comes with a very real cost on your soul -- and you have to, every day, consciously and carefully, override your subconscious mechanisms. It's extremely tiring. Two years later I am just barely starting to have the right instincts during negotiations and have to measure every word to not put myself in a crappy situation. It started getting better, yes. Took a damn long time for it to even start happening though. Wish I met kind people who saw that in me and were willing to go out of their way to help me overcome it. I wish.
How you are brought up in your early periods (in this case: start of career, not literal childhood of course) makes much more difference than many are comfortable with admitting. Sure, at one point I inevitably realized this is exclusively my problem and it's me who has to fix it and reverse its negative effects -- and I do that. But it's not an overnight change, and the transitional period can be extremely hard. I know it was for me.
---
TL;DR -- yeah a lot of managers out there are morons. Can't claim a percentage obviously, but tons of personal anecdotal evidence combined can make for a decent statistical evidence IMO. And you can't counter one anecdotal evidence with another while claiming that yours is somehow the better source of truth. A lot of programmers out there will without hesitation say "most managers I ever worked with were morons". Your positive experience does not nullify theirs.
A lot of the HR analyses I read on HN are coming from an extremely privileged position and are very US-centric. What you experience in the very few tech hubs in USA is absolutely not what you'd experience literally everywhere else in the world. This is an observable fact if you speak with a lot of non-US contractors. But it's also a fact that's usually not welcome on HN.
Most managers I had in my career were indeed morons in general: self-centered people optimizing only for their quarterly or annual bonus, very plain slave-drivers whose only difference with the real thing is the lack of actual whips, unable to understand simple concepts as "a good manager removes obstacles, they don't roast people", and never able to actually lead and not just cover their own bottom by shouting at people to not miss an impossible deadline, and always seeking to inflate their department's budgets out of fear for their budget to be not reduced the next fiscal period. All of that with very little regard for the actual product and success of the company.
Was it my fault for working with them? I suspect yes. But then again my formative years were filled with fear and dread to not end up living under a bridge (very rough and rocky start in life; don't ask). This has made me blind to my own negotiation power and I made many mistakes during most of my career. So strictly and mathematically speaking -- yeah it was my fault for tolerating morons. But once you control for fairly often-occurring human traits (like a beaten-down psyche) you can very easily see what a huge amount of programmers out there are either too afraid or too burned out to seek a better environment. This is often made even worse by them sticking to one market (country or a business area), too.
One truth that a lot of people hate hearing is: if somebody detects that you are vulnerable in any way, they'll make it their goal to turn that against you. There are plenty of such piece of sh1t people out there and many of them are HR or managers. I know this doesn't conform to the touchy-feely world view that many have and that's why it's not a popular thing to say.
Glad your own experience is the opposite. Wish mine was too because overcoming the negative inertia comes with a very real cost on your soul -- and you have to, every day, consciously and carefully, override your subconscious mechanisms. It's extremely tiring. Two years later I am just barely starting to have the right instincts during negotiations and have to measure every word to not put myself in a crappy situation. It started getting better, yes. Took a damn long time for it to even start happening though. Wish I met kind people who saw that in me and were willing to go out of their way to help me overcome it. I wish.
How you are brought up in your early periods (in this case: start of career, not literal childhood of course) makes much more difference than many are comfortable with admitting. Sure, at one point I inevitably realized this is exclusively my problem and it's me who has to fix it and reverse its negative effects -- and I do that. But it's not an overnight change, and the transitional period can be extremely hard. I know it was for me.
---
TL;DR -- yeah a lot of managers out there are morons. Can't claim a percentage obviously, but tons of personal anecdotal evidence combined can make for a decent statistical evidence IMO. And you can't counter one anecdotal evidence with another while claiming that yours is somehow the better source of truth. A lot of programmers out there will without hesitation say "most managers I ever worked with were morons". Your positive experience does not nullify theirs.
> A lot of the HR analyses I read on HN are coming from an extremely privileged position and are very US-centric. What you experience in the very few tech hubs in USA is absolutely not what you'd experience literally everywhere else in the world. This is an observable fact if you speak with a lot of non-US contractors. But it's also a fact that's usually not welcome on HN.
I’ve worked internationally and many of the best managers I’ve worked with are from smaller European countries.
I think you’re just projecting your own bad experiences on to the rest of the world.
Also, HN and Internet forums where people go to vent anonymously are not good barometers for how managers perform. You’re collecting negative anecdotes that confirm your bias.
I’ve worked internationally and many of the best managers I’ve worked with are from smaller European countries.
I think you’re just projecting your own bad experiences on to the rest of the world.
Also, HN and Internet forums where people go to vent anonymously are not good barometers for how managers perform. You’re collecting negative anecdotes that confirm your bias.
I am simply listening to what people say when I ask them. You're free to do exactly what I predicted above: attempt to downplay my anecdotal evidence with yours. Not a convincing reply.
Shame that you think a random guy is on a crusade to prove that many (not all) managers are morons. Borderline conspiracy theories.
Shame that you think a random guy is on a crusade to prove that many (not all) managers are morons. Borderline conspiracy theories.
> What you experience in the very few tech hubs in USA is absolutely not what you'd experience literally everywhere else in the world.
I'd push back against this. I have worked for a few tech companies in pretty small midwest towns and found the culture much better than what I see and hear from FAANG experiences. I turned down an AWS position and ultimately declined to continue interviewing for an Apple position because of some management red flags.
Although I will freely admit my career and life goals are definitely not the average West Coast developer's.
I'd push back against this. I have worked for a few tech companies in pretty small midwest towns and found the culture much better than what I see and hear from FAANG experiences. I turned down an AWS position and ultimately declined to continue interviewing for an Apple position because of some management red flags.
Although I will freely admit my career and life goals are definitely not the average West Coast developer's.
Sure, I am not claiming it's only here or there. I am saying that the average HN poster is very likely to be much more privileged than many other tech workers.
> What evidence do you have for this?
Obviously there is no evidence for this subjective claim. However, the fact that you find it worthwhile to mention:
> I've worked with some excellent managers.
suggests you actually agree with me. If I've said "the sky is green most of the time" you would not find it worthwhile to say "I've seen some blue sky", would you? ;)
Obviously there is no evidence for this subjective claim. However, the fact that you find it worthwhile to mention:
> I've worked with some excellent managers.
suggests you actually agree with me. If I've said "the sky is green most of the time" you would not find it worthwhile to say "I've seen some blue sky", would you? ;)
Yes, "most <insert any large group of people> are morons" is only true if you also believe most people in general are morons, which is a different conversation
"Ninety percent of everything is crap"
https://en.wikipedia.org/wiki/Sturgeon%27s_law
https://en.wikipedia.org/wiki/Sturgeon%27s_law
I also worked with some excellent managers, but most were still bad.
I like how you think because largely correct. I believe it has probably gotten much worse in “inflation driven bubble growth” times we had the last ten years. Non productive individual contributors have proliferated … because why not hire and retain them if money is free?
Managers are 2nd or 3rd order derivatives of IC productivity. If you have over-hired and too many managers to the point where no one knows what productivity is or who is doing any work, then everyone would prefer to be management since no real work is getting done anyway, and any of the work you do as an IC often gets credited : stolen : reassigned to others to spread the credit around.
I categories managers in the following ways:
1. Truly awful or toxic, malicious
Actively interfere with you , fight with you, stop you from being productive. I have had several of these. They are the cancer of companies.
2. Leave you alone
This is one of my favorite types of manager. They just kind of hire you and let you survive and do whatever. Unless you run into political challenges requiring real management, or need resources or get lost. If you are highly self motivated and talented and can figure out what to do yourself, these are fine, mostly.
3. Enablers : Encouragers
These are the managers who really accelerated my career. I have literally only ever had 2 of them, after working for like 20 years.
My personal estimate is that out of 13 managers, 2 have been excellent.
That is a really bad ratio.
Of the 13, 3 have been the leave me alone kind which was ok for a bit.
4-5 have been actively malicious or completely incompetent to the point of making me leave. The rest in between somewhere.
Managers are 2nd or 3rd order derivatives of IC productivity. If you have over-hired and too many managers to the point where no one knows what productivity is or who is doing any work, then everyone would prefer to be management since no real work is getting done anyway, and any of the work you do as an IC often gets credited : stolen : reassigned to others to spread the credit around.
I categories managers in the following ways:
1. Truly awful or toxic, malicious
Actively interfere with you , fight with you, stop you from being productive. I have had several of these. They are the cancer of companies.
2. Leave you alone
This is one of my favorite types of manager. They just kind of hire you and let you survive and do whatever. Unless you run into political challenges requiring real management, or need resources or get lost. If you are highly self motivated and talented and can figure out what to do yourself, these are fine, mostly.
3. Enablers : Encouragers
These are the managers who really accelerated my career. I have literally only ever had 2 of them, after working for like 20 years.
My personal estimate is that out of 13 managers, 2 have been excellent.
That is a really bad ratio.
Of the 13, 3 have been the leave me alone kind which was ok for a bit.
4-5 have been actively malicious or completely incompetent to the point of making me leave. The rest in between somewhere.
Thank you! I wanted to tell you that I really needed to hear this today.
I’m not even sure you are right about evertything, and you are probably oversimplyfing a bit.
But lately I’ve been stuck on this projects with 2 developers (1 is me) and 5(!) managers/project managers assigned to it, plus 3 more on the client side.
The amount of emails exchanged where nothing is said is very funny.
And you know the drill, when it goes right the merit is of the managers (everyone wants the piece of the cake), while when something goes wrong, the fault is the developer’s.
It’s honesly been a shitshow, so it’s been really good for me to read this!
I’m not even sure you are right about evertything, and you are probably oversimplyfing a bit.
But lately I’ve been stuck on this projects with 2 developers (1 is me) and 5(!) managers/project managers assigned to it, plus 3 more on the client side.
The amount of emails exchanged where nothing is said is very funny.
And you know the drill, when it goes right the merit is of the managers (everyone wants the piece of the cake), while when something goes wrong, the fault is the developer’s.
It’s honesly been a shitshow, so it’s been really good for me to read this!
One of the skills as a lead dev that I need to exercise more is knowing when a project needs more people, and then making the case for it to management.
Management seems by default to assign according to bus factor not getting it done. So we have like the same six projects in flight for over a year.
Also, on failed projects, where an understaffed team never completed the assignment, they finally staff it properly the second time around. But, the project still takes a long time to finish having to make sense of what the previous team did and even more time sucking, purging the unnecessary bits, frequently being the majority of the work. It takes 2x the amount of time to delete something than it took to make it.
Management seems by default to assign according to bus factor not getting it done. So we have like the same six projects in flight for over a year.
Also, on failed projects, where an understaffed team never completed the assignment, they finally staff it properly the second time around. But, the project still takes a long time to finish having to make sense of what the previous team did and even more time sucking, purging the unnecessary bits, frequently being the majority of the work. It takes 2x the amount of time to delete something than it took to make it.
What you're saying about management is true, but there's another reason why ultra-productive engineers aren't paid accordingly. It's context-dependent which engineers get to go into that state; put a "10x" engineer on a 0.1x project, and he'll probably just end up failing and making a bunch of enemies.
Therefore, as the company sees it, they deserve the bulk of the rewards since they are (magnanimously) giving the opportunity to the 10x engineer. He'll still get his 10% bonus if he performs well, won't he? So why should they feel compelled to give him more?
Obviously, this is bad for workers and bad for society, but it makes sense from the corporate viewpoint.
Therefore, as the company sees it, they deserve the bulk of the rewards since they are (magnanimously) giving the opportunity to the 10x engineer. He'll still get his 10% bonus if he performs well, won't he? So why should they feel compelled to give him more?
Obviously, this is bad for workers and bad for society, but it makes sense from the corporate viewpoint.
> Therefore, as the company sees it, they deserve the bulk of the rewards since they are (magnanimously) giving the opportunity to the 10x engineer.
I think it's really two things.
1. The company provides the structure in which the engineer works. Code is not valuable on its own, it's valuable when it solves a business problem. The company structure converts business problems to engineering problems for the engineer to solve. That transmogrification has value and the ability to build & maintain the transmogrifier (aka the rest of the company) is a skill that gets rewarded. The transmogrifier also uses money as one of its inputs (salaries for the rest of the company) and so some of the "pure value" that the engineer creates can't be converted directly to money for the engineer, because it has to be used in the "business problem to engineering problem" conversion process.
It's similar to the argument about taxes. Why should I pay taxes for things I don't use? Well, even if I don't drive, the roads support other parts of society that benefit me.
2. The engineer effectively pays the company (meaning the owners or shareholders of the company) to reduce the engineer's risk. If an engineer wants to extract every cent of value they create then they need to also take the burden of all the risk. Otherwise the company owners will not make enough on the successes to cover the failures.
I think it's really two things.
1. The company provides the structure in which the engineer works. Code is not valuable on its own, it's valuable when it solves a business problem. The company structure converts business problems to engineering problems for the engineer to solve. That transmogrification has value and the ability to build & maintain the transmogrifier (aka the rest of the company) is a skill that gets rewarded. The transmogrifier also uses money as one of its inputs (salaries for the rest of the company) and so some of the "pure value" that the engineer creates can't be converted directly to money for the engineer, because it has to be used in the "business problem to engineering problem" conversion process.
It's similar to the argument about taxes. Why should I pay taxes for things I don't use? Well, even if I don't drive, the roads support other parts of society that benefit me.
2. The engineer effectively pays the company (meaning the owners or shareholders of the company) to reduce the engineer's risk. If an engineer wants to extract every cent of value they create then they need to also take the burden of all the risk. Otherwise the company owners will not make enough on the successes to cover the failures.
If an engineer wants to extract every cent of value they create then they need to also take the burden of all the risk.
This is, of course, the argument that capitalists use to justify their disproportionate take, but it doesn't hold water, because they don't really take on much risk. They risk capital they have. often in massive amounts; laborers have to work because they don't have capital to put at risk in the first place. The only thing the bosses are actually risking is becoming workers again, which they'll fight furiously to avoid, because they know how much it sucks, because they're the reason why it sucks.
This is, of course, the argument that capitalists use to justify their disproportionate take, but it doesn't hold water, because they don't really take on much risk. They risk capital they have. often in massive amounts; laborers have to work because they don't have capital to put at risk in the first place. The only thing the bosses are actually risking is becoming workers again, which they'll fight furiously to avoid, because they know how much it sucks, because they're the reason why it sucks.
If managers were just be a bunch of morons optimizing for their own success, then there would be no winners and losers, just losers.
But that's not the case. There are companies which are very definitively winners (in that they avoid managerial dead weight), and especially ones in technology that don't hire managers the way you describe. You often see this at quant funds (Two Sigma, HRT, etc). Of course, not everyone can or wants to work at a quant fund. But the truth is, there's no room for a ladder climbing mediocre manager at such a company, so the culture ends up being quite different.
I think the reason why you are wrong on the whole, is that you're not looking at the game that is being played. It is true that managers are busy optimizing for their own success, but if a company cannot align manager success with that of the broader company, whose fault is that, and who is wasting their resources? Leadership and investors. If you have only worked at companies with poor leadership and weak investors, it is easy to think that managers are always idiots optimizing for their own success at the expense of the company's. The truth is, there are many companies where managers get fired for just that, because the outputs are obvious and managers are looked at as intrinsic cost centers rather than profit centers. Why would I hire an ineffective layer of middle management when I could just fire all of them, hire one great leader, and have most of the team report to that great leader with strong senior ICs eventually becoming functional leads that help that single leader support the team at large?
The simple answer to avoid the problem you are raising is to not work at companies with poor leadership and investor bases. Poor management is a symptom of, not a cause of that root cause. I wonder if the reason you blame it on managers (rather than investors and leaders) is the same reason you think of managers as morons -- because you are not looking at the bigger picture.
But that's not the case. There are companies which are very definitively winners (in that they avoid managerial dead weight), and especially ones in technology that don't hire managers the way you describe. You often see this at quant funds (Two Sigma, HRT, etc). Of course, not everyone can or wants to work at a quant fund. But the truth is, there's no room for a ladder climbing mediocre manager at such a company, so the culture ends up being quite different.
I think the reason why you are wrong on the whole, is that you're not looking at the game that is being played. It is true that managers are busy optimizing for their own success, but if a company cannot align manager success with that of the broader company, whose fault is that, and who is wasting their resources? Leadership and investors. If you have only worked at companies with poor leadership and weak investors, it is easy to think that managers are always idiots optimizing for their own success at the expense of the company's. The truth is, there are many companies where managers get fired for just that, because the outputs are obvious and managers are looked at as intrinsic cost centers rather than profit centers. Why would I hire an ineffective layer of middle management when I could just fire all of them, hire one great leader, and have most of the team report to that great leader with strong senior ICs eventually becoming functional leads that help that single leader support the team at large?
The simple answer to avoid the problem you are raising is to not work at companies with poor leadership and investor bases. Poor management is a symptom of, not a cause of that root cause. I wonder if the reason you blame it on managers (rather than investors and leaders) is the same reason you think of managers as morons -- because you are not looking at the bigger picture.
Hmmm, I disagree. I also don't think that all managers are morons, but even if they were, the fact is that companies often succeed in spite of managerial issues. Sure, there's lots of people are optimizing for the wrong thing, but that doesn't mean it is affecting the final outcome. As long as managers and reports aren't being paid an exorbitant sum, the only loss is in the sanity of individual contributors.
In a large enough company, managers have to do a lot to compromise the success of a company. I'm not saying managers are completely unimportant, but they're not as important as you think.
In a large enough company, managers have to do a lot to compromise the success of a company. I'm not saying managers are completely unimportant, but they're not as important as you think.
Point taken; I think that you are correct that things vary significantly based on the overall size and shape of the org.
Poor management can contribute significantly to OpEx. Compared to ICs, managers have a disproportionate ability to destroy value. Of course, even that is not unlimited. It is true that companies often succeed in spite of managerial issues, but it is only to a point. Once certain lines are crossed from the legal or HR side, the potential collateral damage compared to the average value add can be massive.
With that said, I don't disagree with you that in large enough companies, managers have to do a lot to compromise the success of a company. In practice, there is often enough vertical pressure from and sideways pressures from competing fiefdoms to prevent a single rogue manager from going hog wild. And from the other end, so long as managers are adding (or able to sell the perception of adding) just enough efficiency to the overall organization to support their paycheck, it is true that the only loss is of sanity to ICs, who necessarily must become fungible to a company of that size.
Poor management can contribute significantly to OpEx. Compared to ICs, managers have a disproportionate ability to destroy value. Of course, even that is not unlimited. It is true that companies often succeed in spite of managerial issues, but it is only to a point. Once certain lines are crossed from the legal or HR side, the potential collateral damage compared to the average value add can be massive.
With that said, I don't disagree with you that in large enough companies, managers have to do a lot to compromise the success of a company. In practice, there is often enough vertical pressure from and sideways pressures from competing fiefdoms to prevent a single rogue manager from going hog wild. And from the other end, so long as managers are adding (or able to sell the perception of adding) just enough efficiency to the overall organization to support their paycheck, it is true that the only loss is of sanity to ICs, who necessarily must become fungible to a company of that size.
Yep, agreed. Good observation about operational expenses: management can really fuck things up when it comes to it. But with a large enough company, this might not affect the success. I agree about the "collateral damages" part. And I'd like to rectify my previous post and say it does also affect innovation, culture, long-term-growth, etc., alongside with the sanity of individual collaborators.
[deleted]
That’s a phenomenon I have observed mostly only in US-based companies I have worked for.
AFAICT, smaller, privately owned software companies are more popular in Europe, and they are often much more competently managed (because the owners actually care). Easy access to funding in US makes building large, collectively owned companies more popular, and these while usually very poorly managed can dominate global markets due to better funding, better initial market (one language, more people, richer users, whole world knows English anyway).
I know, I am European and am the CTO for a US-based institution these days. Of course the same mechanisms of management exist here also, but in no way, shape or form in the same way they do in the US. It’s still like night and day on average. After talking with the CEO a lot, he had some sort of realization himself and almost seemed like he began questioning his whole reality. Some of my (subjective) impressions after working for small- and medium-sized (=< 500) European companies for over a decade and now being in US executive management:
Generally employees in the US tend do not have a sense of responsibility for the bigger picture, honestly, most just don’t give a shit. There’s no sense of belonging to a bigger cause. This is not meant as some sort of accusation, because I can understand 100% why that is. There's no reason for anyone to be actually motivated. People are treated like slaves, the general mindset is one of extreme superficiality, and even the most self-motivated and ambitious thought leaders end up being drained and exhausted and then dumped.
US work environments have brutal and insane administrative and technical overhead, are extremely inefficient and there is an abhorrent amount of parasitic middlemen ventures that have penetrated deep into even the most simple tasks and concepts. The environment itself is hostile towards efficiency and creativity.
US workers work more hours than in almost any developed country, yet efficiency is lower than anywhere else. It’s a common theme apparently, same shit with healthcare. Most expensive, least efficient and worst health outcomes in the developed world. Decreasing life expectancy, more infant deaths than in Russia and for some parts of the US, lower life expectancy than in Bangladesh. Sounds absolutely wonderful, and is a perfect example of exactly what’s wrong with the general work culture as well. It’s not about reaching some sort of long-term goal together, it’s just splitting the 3 step way up into 30 pieces and leeching and draining money out of every single one no matter the outcome. Short-term profit over anything else, fuck the future, fuck the new debt and fuck everyone else.
Personally, I had to distance myself from getting too invested and attached as well (so, in a sense, also giving less of a shit) because I got seriously depressed after a while.
But yeah, socialism is “evil”. Tell that to anyone of the happy, healthy and wealthy people in Europe enjoying their paid vacation after taking pride in their work, doing it efficiently and being respected as human beings. I guarantee you they’ll know you’re an American. We must have different definitions of freedom over here.
Generally employees in the US tend do not have a sense of responsibility for the bigger picture, honestly, most just don’t give a shit. There’s no sense of belonging to a bigger cause. This is not meant as some sort of accusation, because I can understand 100% why that is. There's no reason for anyone to be actually motivated. People are treated like slaves, the general mindset is one of extreme superficiality, and even the most self-motivated and ambitious thought leaders end up being drained and exhausted and then dumped.
US work environments have brutal and insane administrative and technical overhead, are extremely inefficient and there is an abhorrent amount of parasitic middlemen ventures that have penetrated deep into even the most simple tasks and concepts. The environment itself is hostile towards efficiency and creativity.
US workers work more hours than in almost any developed country, yet efficiency is lower than anywhere else. It’s a common theme apparently, same shit with healthcare. Most expensive, least efficient and worst health outcomes in the developed world. Decreasing life expectancy, more infant deaths than in Russia and for some parts of the US, lower life expectancy than in Bangladesh. Sounds absolutely wonderful, and is a perfect example of exactly what’s wrong with the general work culture as well. It’s not about reaching some sort of long-term goal together, it’s just splitting the 3 step way up into 30 pieces and leeching and draining money out of every single one no matter the outcome. Short-term profit over anything else, fuck the future, fuck the new debt and fuck everyone else.
Personally, I had to distance myself from getting too invested and attached as well (so, in a sense, also giving less of a shit) because I got seriously depressed after a while.
But yeah, socialism is “evil”. Tell that to anyone of the happy, healthy and wealthy people in Europe enjoying their paid vacation after taking pride in their work, doing it efficiently and being respected as human beings. I guarantee you they’ll know you’re an American. We must have different definitions of freedom over here.
You sound like you're working at a dysfunctional company. The people I've worked with at high performing companies have greater productivity than any F500 company I've seen. The trick is to hire few high performers, pay them a lot, and pay them according to their impact on the business. Go work in HFT some time and you'll see what I mean. No X years of experience required to be Y level bureaucracy.
There's a reason that every European car company has failed to compete with Tesla on software.
There's a reason that every European car company has failed to compete with Tesla on software.
Of course its dysfunctional, that’s what I’m saying, but a dysfunctional company like this would go bankrupt in Europe while it is almost (besides the examples mentioned by you) the norm in the US. And then, consider how many of your awesome HFT ventures actually produce anything of value instead of being parasitic and you’ll come to some good conclusions on why even some third world countries have a dramatically higher living and work standard.
Who cares about Tesla in the bigger picture? Guess where most of the good cars come from - it’s also not the US. Tesla has first movers advantage, but I would strongly disagree that their software is in any way exceptionally better than other software - unless we’re not talking about the same software that powers autopilot killing people left and right. If you’re referring to the general concept of advanced autopilot and so on, sure, they toot their horn a lot, but I’d argue that having stable and reliable software (that inherently takes longer to develop and test) is still the best long term strategy. But it makes sense in the perspective of short term profit over anything…
Give it a few years and Tesla will be overtaken by a mile by even Ford and then another mile by VW and Hyundai.
Who cares about Tesla in the bigger picture? Guess where most of the good cars come from - it’s also not the US. Tesla has first movers advantage, but I would strongly disagree that their software is in any way exceptionally better than other software - unless we’re not talking about the same software that powers autopilot killing people left and right. If you’re referring to the general concept of advanced autopilot and so on, sure, they toot their horn a lot, but I’d argue that having stable and reliable software (that inherently takes longer to develop and test) is still the best long term strategy. But it makes sense in the perspective of short term profit over anything…
Give it a few years and Tesla will be overtaken by a mile by even Ford and then another mile by VW and Hyundai.
> a dysfunctional company like this would go bankrupt in Europe
Is that because of higher government overhead (taxes, regulations) or is it because of some other reason? I doubt it's because of competition, because US companies compete in Europe just fine.
> consider how many of your awesome HFT ventures actually produce anything of value instead of being parasitic and you’ll come to some good conclusions on why even some third world countries have a dramatically higher living and work standard
Two things here: first, I could have mentioned any number of startups which are having real impacts on the world - not the Ubers and WeWorks but the Commonwealth Fusion and the Databricks types. It doesn't need to be HFT - my experience just comes from HFT (also, your European paradise also has HFTs - check out job postings in Amsterdam). Second, maybe by your definition of work standard (lower hours, lots of PTO), other countries have better work standards, but the US has by far the highest salaries for skilled workers. Healthcare costs are not even a consideration when your work pays for excellent insurance. And I would hazard a guess that US companies are closer to the leading edge of tech and therefore more fulfilling to work at. You certainly won't find the breadth of opportunities in Silicon Valley or NYC in any European city, not even London.
Obviously if you are an unskilled worker, Europe is better, but if all the high paid skilled workers start leaving Europe (as they have been for the past 20 years) then you won't have a tax base to pay for the benefits of the unskilled workers.
> but I would strongly disagree that their software is in any way exceptionally better than other software - unless we’re not talking about the same software that powers autopilot killing people left and right
We are not talking about Autopilot but the rest of the car. Take a look at this WSJ article about VW's software development failures [1]. That's from 2021 by the way, very recent. Europeans treat software engineers like factory workers while Silicon Valley treats them like impact makers. That extends to pay, work routines, and everything else. You'd never see a picture like the one in the article where an executive in a suit is presenting to a bunch of other executives in a room.
> Give it a few years and Tesla will be overtaken by a mile by even Ford and then another mile by VW and Hyundai.
Ford, perhaps in trucks. VW and Hyundai, doubtful. If Toyota or Honda had competent EV programs then the conversation would be different.
[1] https://www.wsj.com/articles/how-volkswagens-50-billion-plan...
Is that because of higher government overhead (taxes, regulations) or is it because of some other reason? I doubt it's because of competition, because US companies compete in Europe just fine.
> consider how many of your awesome HFT ventures actually produce anything of value instead of being parasitic and you’ll come to some good conclusions on why even some third world countries have a dramatically higher living and work standard
Two things here: first, I could have mentioned any number of startups which are having real impacts on the world - not the Ubers and WeWorks but the Commonwealth Fusion and the Databricks types. It doesn't need to be HFT - my experience just comes from HFT (also, your European paradise also has HFTs - check out job postings in Amsterdam). Second, maybe by your definition of work standard (lower hours, lots of PTO), other countries have better work standards, but the US has by far the highest salaries for skilled workers. Healthcare costs are not even a consideration when your work pays for excellent insurance. And I would hazard a guess that US companies are closer to the leading edge of tech and therefore more fulfilling to work at. You certainly won't find the breadth of opportunities in Silicon Valley or NYC in any European city, not even London.
Obviously if you are an unskilled worker, Europe is better, but if all the high paid skilled workers start leaving Europe (as they have been for the past 20 years) then you won't have a tax base to pay for the benefits of the unskilled workers.
> but I would strongly disagree that their software is in any way exceptionally better than other software - unless we’re not talking about the same software that powers autopilot killing people left and right
We are not talking about Autopilot but the rest of the car. Take a look at this WSJ article about VW's software development failures [1]. That's from 2021 by the way, very recent. Europeans treat software engineers like factory workers while Silicon Valley treats them like impact makers. That extends to pay, work routines, and everything else. You'd never see a picture like the one in the article where an executive in a suit is presenting to a bunch of other executives in a room.
> Give it a few years and Tesla will be overtaken by a mile by even Ford and then another mile by VW and Hyundai.
Ford, perhaps in trucks. VW and Hyundai, doubtful. If Toyota or Honda had competent EV programs then the conversation would be different.
[1] https://www.wsj.com/articles/how-volkswagens-50-billion-plan...
> Is that because of higher government overhead (taxes, regulations) or is it because of some other reason? I doubt it's because of competition, because US companies compete in Europe just fine.
I assume it's simply because we produce value with more efficiency and less initial funding.
By the way, on the matter of personal taxes, US citizens are paying, if you take local, state, sales, etc tax and healthcare premiums into account, the same or in some cases even more taxes than Europeans do. They just get absolutely nil in return.
This also extends to companies to some degree, vice versa. There is no real regulation that says you have to shut your unprofitable business down, but you're not going to be in business for very long if you have to treat your employees fairly, which is by regulation.
> your European paradise also has HFTs - check out job postings in Amsterdam
So.. this is pretty much what I'm on about. And I can guarantee you that they have dramatically less expense, overhead and a dramatically higher standard of work.
> That's from 2021 by the way, very recent. Europeans treat software engineers like factory workers while Silicon Valley treats them like impact makers.
The thing is, our "factory workers" are getting, BY DEFAULT, better benefits than even the most highly advanced Silicon Valley "impact makers". Even the fucking janitor gets by law almost a month of mandatory paid vacation, unlimited sick days, complete and utter unlimited job protection in addition to ±80% of his salary in the case of illness, forever, has to be paid, if not (likely) more, a living wage that is on average twice as high as the US minimum wage, has complete and utter protection if he turns out unemployed at some point and he will be taken care of at old age. He will also not be working more than 40 hours per week and especially not unpaid.
THE JANITOR. Everyone.
Yes, our wages for highly skilled workers are not as high as some insane 300k FAANG jobs, but I'd rather have it this way and the janitor happy as well. When you hear about “factory workers” here it is not what you think it is.
> VW and Hyundai, doubtful.
I cannot share much here due to my field of work, but I think you're going to be very surprised.
I assume it's simply because we produce value with more efficiency and less initial funding.
By the way, on the matter of personal taxes, US citizens are paying, if you take local, state, sales, etc tax and healthcare premiums into account, the same or in some cases even more taxes than Europeans do. They just get absolutely nil in return.
This also extends to companies to some degree, vice versa. There is no real regulation that says you have to shut your unprofitable business down, but you're not going to be in business for very long if you have to treat your employees fairly, which is by regulation.
> your European paradise also has HFTs - check out job postings in Amsterdam
So.. this is pretty much what I'm on about. And I can guarantee you that they have dramatically less expense, overhead and a dramatically higher standard of work.
> That's from 2021 by the way, very recent. Europeans treat software engineers like factory workers while Silicon Valley treats them like impact makers.
The thing is, our "factory workers" are getting, BY DEFAULT, better benefits than even the most highly advanced Silicon Valley "impact makers". Even the fucking janitor gets by law almost a month of mandatory paid vacation, unlimited sick days, complete and utter unlimited job protection in addition to ±80% of his salary in the case of illness, forever, has to be paid, if not (likely) more, a living wage that is on average twice as high as the US minimum wage, has complete and utter protection if he turns out unemployed at some point and he will be taken care of at old age. He will also not be working more than 40 hours per week and especially not unpaid.
THE JANITOR. Everyone.
Yes, our wages for highly skilled workers are not as high as some insane 300k FAANG jobs, but I'd rather have it this way and the janitor happy as well. When you hear about “factory workers” here it is not what you think it is.
> VW and Hyundai, doubtful.
I cannot share much here due to my field of work, but I think you're going to be very surprised.
> I assume it's simply because we produce value with more efficiency and less initial funding.
But the data doesn't back that up. According to the EU, the US has 40% higher GDP per capita [1] compared to the EU. And that's according to the EU, which has to be the most biased source possible.
> US citizens are paying, if you take local, state, sales, etc tax and healthcare premiums into account, the same or in some cases even more taxes than Europeans do
That isn't true, at least for me and many other software engineers. Sales tax is definitely lower in the US because we don't have VAT - typical rates are 7-10% vs. 12-20% in EU. Income tax is also lower in the US. According to this calculator [2] I would pay about 10% lower income tax effective rate on my current income in the US vs. Berlin, Germany. My health insurance costs <$2000/year for a high tier plan so that cost is negligible. Payroll tax for companies is lower. Gas tax is lower, by a substantial margin.
> So.. this is pretty much what I'm on about. And I can guarantee you that they have dramatically less expense, overhead and a dramatically higher standard of work.
What's your point - that EU does have parasitic companies which produce no value or does not? You seem to be flip flopping. And I can tell you the only reason the EU has dramatically less expense is the workers make less. A lot less. I make double what my counterparts in the EU are making. They definitely don't have a higher standard of work either.
> The thing is, our "factory workers" are getting, BY DEFAULT, better benefits than even the most highly advanced Silicon Valley "impact makers"
Are they? Your factory workers get free breakfast, lunch, dinner, multi-thousand dollar offsites and dinners, and the ability to invest your salary in the (private) company? You consider things like guaranteed job protection as benefits, but I see them as lowering my pay and reducing the number of jobs available. There's a reason why European unemployment is 300 basis points higher than US and why far more startups are started in the US. Banning non-competes and at-will employment in California are the #1 reason why SWE wages are so high here.
You may value work-life balance over pay, but that is a personal choice and not an objectively superior option. Some of us are willing to work hard to become wealthy, others are fine where they are.
> a month of mandatory paid vacation
That ends up reflecting in your pay (or lack thereof). The market rate for wages will be lower because the month of vacation will be priced in.
> THE JANITOR. Everyone.
The janitor's benefits are irrelevant. I already said unskilled workers do better in EU. Your original comment was about white collar workers in companies. That means skilled workers. And a skilled worker is going to have a way better life in the US.
> Yes, our wages for highly skilled workers are not as high as some insane 300k FAANG jobs
Not as high is one way of putting it. According to levels.fyi the gap is 2-3x for a senior SWE in most FAANG or FAANG adjacent companies.
> I'd rather have it this way and the janitor happy as well.
And you are entitled to have that opinion, but you shouldn't go around claiming that US companies are "extremely inefficient" or that the environment is "hostile towards efficiency and creativity".
[1] https://ec.europa.eu/eurostat/documents/portlet_file_entry/2...
[2] https://www.arbeitnow.com/tools/salary-calculator/germany
But the data doesn't back that up. According to the EU, the US has 40% higher GDP per capita [1] compared to the EU. And that's according to the EU, which has to be the most biased source possible.
> US citizens are paying, if you take local, state, sales, etc tax and healthcare premiums into account, the same or in some cases even more taxes than Europeans do
That isn't true, at least for me and many other software engineers. Sales tax is definitely lower in the US because we don't have VAT - typical rates are 7-10% vs. 12-20% in EU. Income tax is also lower in the US. According to this calculator [2] I would pay about 10% lower income tax effective rate on my current income in the US vs. Berlin, Germany. My health insurance costs <$2000/year for a high tier plan so that cost is negligible. Payroll tax for companies is lower. Gas tax is lower, by a substantial margin.
> So.. this is pretty much what I'm on about. And I can guarantee you that they have dramatically less expense, overhead and a dramatically higher standard of work.
What's your point - that EU does have parasitic companies which produce no value or does not? You seem to be flip flopping. And I can tell you the only reason the EU has dramatically less expense is the workers make less. A lot less. I make double what my counterparts in the EU are making. They definitely don't have a higher standard of work either.
> The thing is, our "factory workers" are getting, BY DEFAULT, better benefits than even the most highly advanced Silicon Valley "impact makers"
Are they? Your factory workers get free breakfast, lunch, dinner, multi-thousand dollar offsites and dinners, and the ability to invest your salary in the (private) company? You consider things like guaranteed job protection as benefits, but I see them as lowering my pay and reducing the number of jobs available. There's a reason why European unemployment is 300 basis points higher than US and why far more startups are started in the US. Banning non-competes and at-will employment in California are the #1 reason why SWE wages are so high here.
You may value work-life balance over pay, but that is a personal choice and not an objectively superior option. Some of us are willing to work hard to become wealthy, others are fine where they are.
> a month of mandatory paid vacation
That ends up reflecting in your pay (or lack thereof). The market rate for wages will be lower because the month of vacation will be priced in.
> THE JANITOR. Everyone.
The janitor's benefits are irrelevant. I already said unskilled workers do better in EU. Your original comment was about white collar workers in companies. That means skilled workers. And a skilled worker is going to have a way better life in the US.
> Yes, our wages for highly skilled workers are not as high as some insane 300k FAANG jobs
Not as high is one way of putting it. According to levels.fyi the gap is 2-3x for a senior SWE in most FAANG or FAANG adjacent companies.
> I'd rather have it this way and the janitor happy as well.
And you are entitled to have that opinion, but you shouldn't go around claiming that US companies are "extremely inefficient" or that the environment is "hostile towards efficiency and creativity".
[1] https://ec.europa.eu/eurostat/documents/portlet_file_entry/2...
[2] https://www.arbeitnow.com/tools/salary-calculator/germany
> But the data doesn't back that up. According to the EU, the US has 40% higher GDP per capita [1] compared to the EU. And that's according to the EU, which has to be the most biased source possible.
The US is the richest country in the history of modern civilisation, yet in every possible metric worse then the rest of the developed world, sometimes less than even some third world countries. I would argue that GDP per capita is not necessarily a good indicator when most of the GDP goes into the pockets of the ultra rich and parasitic middlemen instead of back to the population, no? This is also a form of lack of efficiency.
> That isn't true, at least for me and many other software engineers. Sales tax is definitely lower in the US because we don't have VAT - typical rates are 7-10% vs. 12-20% in EU. Income tax is also lower in the US. According to this calculator [2] I would pay about 10% lower income tax effective rate on my current income in the US vs. Berlin, Germany. My health insurance costs <$2000/year for a high tier plan so that cost is negligible. Payroll tax for companies is lower. Gas tax is lower, by a substantial margin.
Sorry, no, obviously any generalisation is not valid for every single individual case, so that's why I was talking about a mean of the population and not specifically you.
However, if we were to start contemplating e.g. how much your health insurance even covers and how much you pay in co-pay (spoiler, its $0 here), even if we don't, we are still surprisingly close to each other, aren't we - and then, considering how much value you receive back of it.. it's not going into your crumbling infrastructure either.
> Are they? Your factory workers get free breakfast, lunch, dinner, multi-thousand dollar offsites and dinners, and the ability to invest your salary in the (private) company?
Actual factory workers, no, but you think our highly skilled workers don't get this? Of course they do, again, maybe only 100k instead of 300k salary off some VC funding, on the other hand you're not going to be spending 100k for stuff we get for free and the janitor and everyone else is not treated like a slave either. Don't you think it is a very reasonable assumption that in a functioning society every part, no matter how skilled or not, has to function properly and be healthy? You yourself are also dependent on every other part functioning properly.
> why SWE wages are so high here
Great, and they are part of an unsustainable bubble and destroying the whole balance between supply and demand, causing inevitable rise to homelessness, crime, mental illness and drug epidemics. I think I'm starting to understand what they mean with "driving over bodies"
> That ends up reflecting in your pay (or lack thereof). The market rate for wages will be lower because the month of vacation will be priced in.
This is correct.
> And a skilled worker is going to have a way better life in the US.
No. He will statistically die sooner, receive some of the worst healthcare in the entire world, live in the midst of poverty and crime, and will have considerable less time to actually live his life.
> You consider things like guaranteed job protection as benefits, but I see them as lowering my pay
Only until you realise that this also applies to yourself, and then consider that you are much more likely to suffer from chronic illness, depression and burnout.
I mean, I do understand your perspective from a very egoistical standpoint, but please just take a look at your country and how that's working out for you these days.
The US is the richest country in the history of modern civilisation, yet in every possible metric worse then the rest of the developed world, sometimes less than even some third world countries. I would argue that GDP per capita is not necessarily a good indicator when most of the GDP goes into the pockets of the ultra rich and parasitic middlemen instead of back to the population, no? This is also a form of lack of efficiency.
> That isn't true, at least for me and many other software engineers. Sales tax is definitely lower in the US because we don't have VAT - typical rates are 7-10% vs. 12-20% in EU. Income tax is also lower in the US. According to this calculator [2] I would pay about 10% lower income tax effective rate on my current income in the US vs. Berlin, Germany. My health insurance costs <$2000/year for a high tier plan so that cost is negligible. Payroll tax for companies is lower. Gas tax is lower, by a substantial margin.
Sorry, no, obviously any generalisation is not valid for every single individual case, so that's why I was talking about a mean of the population and not specifically you.
However, if we were to start contemplating e.g. how much your health insurance even covers and how much you pay in co-pay (spoiler, its $0 here), even if we don't, we are still surprisingly close to each other, aren't we - and then, considering how much value you receive back of it.. it's not going into your crumbling infrastructure either.
> Are they? Your factory workers get free breakfast, lunch, dinner, multi-thousand dollar offsites and dinners, and the ability to invest your salary in the (private) company?
Actual factory workers, no, but you think our highly skilled workers don't get this? Of course they do, again, maybe only 100k instead of 300k salary off some VC funding, on the other hand you're not going to be spending 100k for stuff we get for free and the janitor and everyone else is not treated like a slave either. Don't you think it is a very reasonable assumption that in a functioning society every part, no matter how skilled or not, has to function properly and be healthy? You yourself are also dependent on every other part functioning properly.
> why SWE wages are so high here
Great, and they are part of an unsustainable bubble and destroying the whole balance between supply and demand, causing inevitable rise to homelessness, crime, mental illness and drug epidemics. I think I'm starting to understand what they mean with "driving over bodies"
> That ends up reflecting in your pay (or lack thereof). The market rate for wages will be lower because the month of vacation will be priced in.
This is correct.
> And a skilled worker is going to have a way better life in the US.
No. He will statistically die sooner, receive some of the worst healthcare in the entire world, live in the midst of poverty and crime, and will have considerable less time to actually live his life.
> You consider things like guaranteed job protection as benefits, but I see them as lowering my pay
Only until you realise that this also applies to yourself, and then consider that you are much more likely to suffer from chronic illness, depression and burnout.
I mean, I do understand your perspective from a very egoistical standpoint, but please just take a look at your country and how that's working out for you these days.
> I would argue that GDP per capita is not necessarily a good indicator when most of the GDP goes into the pockets of the ultra rich instead of back to the population, no? This is also a form of lack of efficiency.
That is your opinion. Output per person (GDP per capita) is the objective measure of efficiency. Also, European taxes on capital gains are about the same as the US, so in fact EU is not really taxing the ultra-wealthy any more than the US. High wage earners are taxed instead, but high wage earners are not ultra-wealthy.
> Sorry, no, obviously any generalisation is not valid for every single individual case, so that's why I was talking about a mean of the population and not specifically you.
Again, that's not supported by the data [1].
> However, if we were to start contemplating e.g. how much your health insurance even covers and how much you pay in co-pay (spoiler, its $0 here), even if we don't, we are still surprisingly close to each other, aren't we - and then, considering how much value you receive back of it..
My health insurance might not have $0 copay but it is low enough that a doctor's visit costs about as much as a dine-in casual lunch would. And I get higher quality doctors, since our doctors make 6-7 figures compared to maximum 100k of EU doctors (the NHS in the UK pays less than 100k GBP for specialist doctors...), so all the talent gets vacuumed up by the US.
And they are not surprisingly close - I ran the numbers with my US income. My income for the same position in EU would be halved or more. So the actual gap in net income after tax and health insurance would be substantially larger.
> No, but you think our highly skilled workers don't get this? Of course they do
Do the engineers at your company get that benefit? How much money do you think they can realistically invest when they make half of their American counterparts and get taxed at 35-40%?
> Great, and they are destroying the whole balance between supply and demand, causing inevitable rise to homelessness, crime, mental illness and drug epidemics
These things are caused by a failure to build housing and prosecute petty theft, not by high wages.
> Our minimum wage is still twice as high as yours.
Netherlands minimum wage is 10.14 EUR/h [2] while CA minimum wage is $14-15/h [3]. And in practice, the wages for low skill workers in CA are around $20/h now due to market demand. Not only that, but the unemployment rate (and particularly the youth unemployment rate which is a proxy for unskilled labor) is much higher in EU.
> No. He will statistically die sooner, receive some of the worst healthcare in the entire world, live in the midst of poverty and crime, etc etc etc.
You are trying to make inferences about a high earner from statistics about the median. That's egregiously incorrect.
> But at least you yourself earn twice as much. Sounds reasonable.
Again, that's your opinion that it's unreasonable. As long as skilled workers continue to migrate from EU to the US due to the higher wages, your opinion is irrelevant. And if you take a look at the makeup of any top ranked master's or PhD program today in STEM or business in the US, you will see that it is 30% European, 30% Chinese, 30% Indian. So I think the market does not really care about your opinion.
[1] https://www.taxpolicycenter.org/briefing-book/how-do-us-taxe...
[2] https://www.government.nl/topics/minimum-wage/amount-of-the-...
[3] https://www.dir.ca.gov/dlse/faq_minimumwage.htm
That is your opinion. Output per person (GDP per capita) is the objective measure of efficiency. Also, European taxes on capital gains are about the same as the US, so in fact EU is not really taxing the ultra-wealthy any more than the US. High wage earners are taxed instead, but high wage earners are not ultra-wealthy.
> Sorry, no, obviously any generalisation is not valid for every single individual case, so that's why I was talking about a mean of the population and not specifically you.
Again, that's not supported by the data [1].
> However, if we were to start contemplating e.g. how much your health insurance even covers and how much you pay in co-pay (spoiler, its $0 here), even if we don't, we are still surprisingly close to each other, aren't we - and then, considering how much value you receive back of it..
My health insurance might not have $0 copay but it is low enough that a doctor's visit costs about as much as a dine-in casual lunch would. And I get higher quality doctors, since our doctors make 6-7 figures compared to maximum 100k of EU doctors (the NHS in the UK pays less than 100k GBP for specialist doctors...), so all the talent gets vacuumed up by the US.
And they are not surprisingly close - I ran the numbers with my US income. My income for the same position in EU would be halved or more. So the actual gap in net income after tax and health insurance would be substantially larger.
> No, but you think our highly skilled workers don't get this? Of course they do
Do the engineers at your company get that benefit? How much money do you think they can realistically invest when they make half of their American counterparts and get taxed at 35-40%?
> Great, and they are destroying the whole balance between supply and demand, causing inevitable rise to homelessness, crime, mental illness and drug epidemics
These things are caused by a failure to build housing and prosecute petty theft, not by high wages.
> Our minimum wage is still twice as high as yours.
Netherlands minimum wage is 10.14 EUR/h [2] while CA minimum wage is $14-15/h [3]. And in practice, the wages for low skill workers in CA are around $20/h now due to market demand. Not only that, but the unemployment rate (and particularly the youth unemployment rate which is a proxy for unskilled labor) is much higher in EU.
> No. He will statistically die sooner, receive some of the worst healthcare in the entire world, live in the midst of poverty and crime, etc etc etc.
You are trying to make inferences about a high earner from statistics about the median. That's egregiously incorrect.
> But at least you yourself earn twice as much. Sounds reasonable.
Again, that's your opinion that it's unreasonable. As long as skilled workers continue to migrate from EU to the US due to the higher wages, your opinion is irrelevant. And if you take a look at the makeup of any top ranked master's or PhD program today in STEM or business in the US, you will see that it is 30% European, 30% Chinese, 30% Indian. So I think the market does not really care about your opinion.
[1] https://www.taxpolicycenter.org/briefing-book/how-do-us-taxe...
[2] https://www.government.nl/topics/minimum-wage/amount-of-the-...
[3] https://www.dir.ca.gov/dlse/faq_minimumwage.htm
> Again, that's your opinion that it's unreasonable.
First of all, I specifically started off my original post saying that everything that followed is my subjective, personal opinion and experiences. What exactly did you expect trying to argue with me about it?
> Netherlands minimum wage is 10.14 EUR/h [2] while CA minimum wage is $14-15/h [3]. And in practice, the wages for low skill workers in CA
So we're cherry-picking US states and EU countries now instead of going by averages?
> > No. He will statistically die sooner, receive some of the worst healthcare in the entire world, live in the midst of poverty and crime, etc etc etc.
> You are trying to make inferences about a high earner from statistics about the median. That's egregiously incorrect.
Higher earners are still almost equally affected by any of the issues above, as are you. My statement stands.
> Again, that's your opinion that it's unreasonable. As long as skilled workers continue to migrate from EU to the US due to the higher wages, your opinion is irrelevant. And if you take a look at the makeup of any top ranked master's or PhD program today in STEM or business in the US, you will see that it is 30% European, 30% Chinese, 30% Indian. So I think the market does not really care about your opinion.
.. so? We also have a lot of US citizens living here and our universities are filled with expats from all over the world.
Also, BTW.. these students you mention will mostly be left with horrendous, crippling student debt.
Ours will have 0 in student debt because all education is free, so people are also studying for longer periods of time, maybe even your doctor.
> These things are caused by a failure to build housing and prosecute petty theft, not by high wages.
Not by high wages, by disproportionally high or low wages. There is enough housing in the US already. There is just simply no way to afford it for anyone but high-skill workers because of this. Combine that with the absolute lack of social housing or regulation and poverty and you arrive at exactly the inevitable rise of homelessness and crime that you think needs to be cracked down upon instead of fixed at its root.
> Again, that's not supported by the data [1].
I cannot see any of your data taking into account other expenses and correlations to expenses that the US population is affected by and EU citizens are not. Obviously the tax rate on paper is lower, but that wasn't my point to begin with.
Let's just leave it at that. You have your opinion, I have my opinion, end results matter and statistics are speaking loud and clearly.
First of all, I specifically started off my original post saying that everything that followed is my subjective, personal opinion and experiences. What exactly did you expect trying to argue with me about it?
> Netherlands minimum wage is 10.14 EUR/h [2] while CA minimum wage is $14-15/h [3]. And in practice, the wages for low skill workers in CA
So we're cherry-picking US states and EU countries now instead of going by averages?
> > No. He will statistically die sooner, receive some of the worst healthcare in the entire world, live in the midst of poverty and crime, etc etc etc.
> You are trying to make inferences about a high earner from statistics about the median. That's egregiously incorrect.
Higher earners are still almost equally affected by any of the issues above, as are you. My statement stands.
> Again, that's your opinion that it's unreasonable. As long as skilled workers continue to migrate from EU to the US due to the higher wages, your opinion is irrelevant. And if you take a look at the makeup of any top ranked master's or PhD program today in STEM or business in the US, you will see that it is 30% European, 30% Chinese, 30% Indian. So I think the market does not really care about your opinion.
.. so? We also have a lot of US citizens living here and our universities are filled with expats from all over the world.
Also, BTW.. these students you mention will mostly be left with horrendous, crippling student debt.
Ours will have 0 in student debt because all education is free, so people are also studying for longer periods of time, maybe even your doctor.
> These things are caused by a failure to build housing and prosecute petty theft, not by high wages.
Not by high wages, by disproportionally high or low wages. There is enough housing in the US already. There is just simply no way to afford it for anyone but high-skill workers because of this. Combine that with the absolute lack of social housing or regulation and poverty and you arrive at exactly the inevitable rise of homelessness and crime that you think needs to be cracked down upon instead of fixed at its root.
> Again, that's not supported by the data [1].
I cannot see any of your data taking into account other expenses and correlations to expenses that the US population is affected by and EU citizens are not. Obviously the tax rate on paper is lower, but that wasn't my point to begin with.
Let's just leave it at that. You have your opinion, I have my opinion, end results matter and statistics are speaking loud and clearly.
Perhaps except Polestar?
Spot on comment - agreed 100%. I generally agree that certain aspects of US system are completely broken comparing to UE. (I was also born in UE and moved to US).
However w.r.t. "capitalism" vs "socialism" I must say that it is related but wrong lenses to look at it. The right distinction is "individually" vs "collectively" owned.
US corporations are "collaboratively owned" even if they are "private" in theory. This is what makes them work the same as "collaboratively owned bureaucracies". Working in a big US corpo is like getting a cozy job in a government. European SWE companies are "individually owned", even if they are surrounded by more social-inclined environment (which comes with it's own pros and cons).
However w.r.t. "capitalism" vs "socialism" I must say that it is related but wrong lenses to look at it. The right distinction is "individually" vs "collectively" owned.
US corporations are "collaboratively owned" even if they are "private" in theory. This is what makes them work the same as "collaboratively owned bureaucracies". Working in a big US corpo is like getting a cozy job in a government. European SWE companies are "individually owned", even if they are surrounded by more social-inclined environment (which comes with it's own pros and cons).
You’re right, most, especially almost all of the smaller and medium-sized SWE companies are owned by individuals, but we sure do have corporations here as well. They look similar to any other US institution on the inside, but are obviously mostly still operating under the local understanding of work and employee rights. I have no real experience with the seriously big corporations, that always seemed like something I’d rather not work at personally, but I don’t believe it’s very different there.
I mean, I've seen the same exact thing in the UK and Germany. People just don't give a fuck about their job, they come to do the minimum amount of work and fuck off. More Brits stayed for overtime, Germans preferred to leave on time. But they solved it by hiring immigrants who will work like horses.
And for low/unskilled workers, in the UK they're with an agency so they can be sacked anytime, while in Germany they're hired on a 6 month contract, then swapped with others for 6 months, then the previous guys return after 6 months, it's rather insane. So much for social protection or whatever.
Mercedes parts QA people and warehouse workers are on 6 days/10-12 hours for 3-6 months. Literally looking at an advert right now. Wage doesn't even matter (it's minimum), that kind of schedule is bad for quality. Also, great European work/life balance lol
What I'm trying to say, it's more of a company problem.
And for low/unskilled workers, in the UK they're with an agency so they can be sacked anytime, while in Germany they're hired on a 6 month contract, then swapped with others for 6 months, then the previous guys return after 6 months, it's rather insane. So much for social protection or whatever.
Mercedes parts QA people and warehouse workers are on 6 days/10-12 hours for 3-6 months. Literally looking at an advert right now. Wage doesn't even matter (it's minimum), that kind of schedule is bad for quality. Also, great European work/life balance lol
What I'm trying to say, it's more of a company problem.
No, that’s really just picking out the bad apples in the face of undeniable statistics. I could do the same for the US now but then we’d end up with almost the whole apple tree
I’m also not saying that we don’t have problems in Europe either, but they are not structural and by default
I’m also not saying that we don’t have problems in Europe either, but they are not structural and by default
Thanks for your comment. It's save me to write my own.
Basically, we've just privatized socialism, not only because we've outsourced health insurance into an employer-provider benefit, but also in the sense that large corporate structures are overseen by bureaucracies that lead to huge amounts of opacity and waste, akin to stereotypical Soviet era governments.
https://news.ycombinator.com/item?id=30928403
And gains are redistributed similarly.
https://news.ycombinator.com/item?id=30724348
https://news.ycombinator.com/item?id=30928403
And gains are redistributed similarly.
https://news.ycombinator.com/item?id=30724348
If it is, I have yet to see it. Managers, owners and middlemen making everything a slog to work with is very much a thing in Europe. And when you realize European managers are also sitting on ivory towers relative to ICs, it becomes pretty apparent why this behavior is somewhat universal.
Count yourself lucky thay you didn't have the misfortune of working for any Asian companies. Big or small, most are extremely hierarchical and your loyalty to a specific director/VP is the only currency that matters.
Oh, yeah, you’re right. I only know about the Japanese work environments but that’s already more than enough. It’s like end-stage America
It’s easy to massively improve the performance of most companies:
1. Fire 50% of managers. 2. Use the salary money saved to hire people doing the actual work. 3. Wait for a while to see how much things have improved. Repeat if overall performance has improved (it almost always has).
1. Fire 50% of managers. 2. Use the salary money saved to hire people doing the actual work. 3. Wait for a while to see how much things have improved. Repeat if overall performance has improved (it almost always has).
You'll run into the same problem you run into with stack ranking where you up firing x% of ICs every quarter - the good ones leave, the bad ones stay.
Say you fire half the managers. Let's say you live in a fantasy world where you can accurately measure who is the bottom half vs. the top half by whatever metric matters to you. So you fire the worst half. You've just done a couple things:
1. Probably triggered some sort of "layoff" legislation/notice/severance/whatever and sent a ton of people looking for work before the next round, whether you expect there to be a next round or not (but you've already said there would be).
2. The good managers, who could probably walk into another management role without much trouble, do so. Why risk being in the second round?
3. You're left with something approaching the middle quartile, but now they're doing more than 2x the work after the top 5-10% of your management leaves after your purge. How many people do you know suddenly get better at their job after you double their workload?
4. I don't know how true it is but there is an old saying "people don't leave jobs they leave managers," and so now for half the company you've fired their manager and given them someone very overworked. For some non-trivial percentage of the company their new manager is worse than their old manager.
5. Due to #1 and #4, your best ICs start to leave, so engineering and product quality (and velocity) drop precipitously.
6. You've lost your best managers, who would fight to keep the hiring bar high, so the weak ones compromise on shaky candidates. Engineering and product quality drop even more, and morale tanks.
Congratulations, you've just filed for bankruptcy with extra steps.
Say you fire half the managers. Let's say you live in a fantasy world where you can accurately measure who is the bottom half vs. the top half by whatever metric matters to you. So you fire the worst half. You've just done a couple things:
1. Probably triggered some sort of "layoff" legislation/notice/severance/whatever and sent a ton of people looking for work before the next round, whether you expect there to be a next round or not (but you've already said there would be).
2. The good managers, who could probably walk into another management role without much trouble, do so. Why risk being in the second round?
3. You're left with something approaching the middle quartile, but now they're doing more than 2x the work after the top 5-10% of your management leaves after your purge. How many people do you know suddenly get better at their job after you double their workload?
4. I don't know how true it is but there is an old saying "people don't leave jobs they leave managers," and so now for half the company you've fired their manager and given them someone very overworked. For some non-trivial percentage of the company their new manager is worse than their old manager.
5. Due to #1 and #4, your best ICs start to leave, so engineering and product quality (and velocity) drop precipitously.
6. You've lost your best managers, who would fight to keep the hiring bar high, so the weak ones compromise on shaky candidates. Engineering and product quality drop even more, and morale tanks.
Congratulations, you've just filed for bankruptcy with extra steps.
I think you are right if it is the good managers being fired. If it is the bad managers being fired then it is 100% a good thing. A real world example is Steve Jobs turning Apple around after Sculley nearly ran it into the ground. Jobs did it by firing most of middle management. Basically anybody who was not directly contributing to products. It worked.
Moron or not, I dont want people to starve simply because they dont help a company perform optimally.
If we were to implement some form of a universal basic income there would be no obligation to become a self-serving asshole at whatever company you can get yourself into. The people doing the work would be able to stand up for themselves and tell management to fuck off if they do become moronic or overly self-serving
If we were to implement some form of a universal basic income there would be no obligation to become a self-serving asshole at whatever company you can get yourself into. The people doing the work would be able to stand up for themselves and tell management to fuck off if they do become moronic or overly self-serving
OK, OK. I am a supporter of of UBI, but let's not make it sound like ICs are the victims that are tolerating the abuse, working for peanuts, or otherwise they will starve.
Lots of ICs are also self-serving morons. It's not like the managers designed crap solutions, wrote the crap code, and are the cause of barely anything working, at least not directly.
My point was mostly that the whole point of hiring managers (and often paying them more than ICs) was to get some people work on optimizing the productivity, making sure best ICs stay and can be effective, and help in various ways ones that are not as solid (possibly yet). By reliably failing to do so, what's the point of having them in the first place, and even more so - holding them in such a high esteem, paying them more, and having so many of them around.
Lots of ICs are also self-serving morons. It's not like the managers designed crap solutions, wrote the crap code, and are the cause of barely anything working, at least not directly.
My point was mostly that the whole point of hiring managers (and often paying them more than ICs) was to get some people work on optimizing the productivity, making sure best ICs stay and can be effective, and help in various ways ones that are not as solid (possibly yet). By reliably failing to do so, what's the point of having them in the first place, and even more so - holding them in such a high esteem, paying them more, and having so many of them around.
>what's the point of having them in the first place,
to increase company size and keep more people in the world fed. without them, that money just goes into the CEO's pocket anyway.
>paying them more,
this i disagree with as well. Money should be way better allocated to the people keeping the company alive since everyones dinner depends on them.
But overall a company should hire as many people as it can afford. have them work from home and do almost nothing most of the time. pay them the least in the company.
Usually these discussions leave out what happens when people dont have jobs at all, which would happen to a lot of people if companies were run optimally and morons were fired. Do we let them die so that we can buy yachts? I dont think we should all die together if we cant save everyone, but I do think we should be working to maximize the number of "free loaders" our country can support and viewing that as a signal of strength.
I also believe if we remove all these people who are better off as free loaders from the workforce, that companies would become more productive overall, not less. There is this belief that everyone would just stop working if they didnt need to and nothing would get done. I dont buy it. Absolute worst case scenario we could have a draft and use the military to fill the gaps in the workforce lol
to increase company size and keep more people in the world fed. without them, that money just goes into the CEO's pocket anyway.
>paying them more,
this i disagree with as well. Money should be way better allocated to the people keeping the company alive since everyones dinner depends on them.
But overall a company should hire as many people as it can afford. have them work from home and do almost nothing most of the time. pay them the least in the company.
Usually these discussions leave out what happens when people dont have jobs at all, which would happen to a lot of people if companies were run optimally and morons were fired. Do we let them die so that we can buy yachts? I dont think we should all die together if we cant save everyone, but I do think we should be working to maximize the number of "free loaders" our country can support and viewing that as a signal of strength.
I also believe if we remove all these people who are better off as free loaders from the workforce, that companies would become more productive overall, not less. There is this belief that everyone would just stop working if they didnt need to and nothing would get done. I dont buy it. Absolute worst case scenario we could have a draft and use the military to fill the gaps in the workforce lol
A bureaucrat has never created a solution, so thinking UBI would solve anything is naive at best. Why not go for something simpler, like make basic life cheap and efficient so people can live with very little work? Bonus point: no need to take (steal?) money from people to implement.
Exactly.
UBI is like printing money - the last stage before a country's hyper-inflationary collapse.
Instead of inflation & printing money, we should instead be thinking of salt - once a valuable commodity, nowadays so cheap people are literally giving it away (restaurants don't charge for it).
With enough technological development, almost every necessity of life can be as cheap (and cheaper) as salt. Except medicine, because people will always want to live longer, but even there technology helps - poor people in first-world countries have access to much better healthcare than even the riches human 100 years ago.
UBI is like printing money - the last stage before a country's hyper-inflationary collapse.
Instead of inflation & printing money, we should instead be thinking of salt - once a valuable commodity, nowadays so cheap people are literally giving it away (restaurants don't charge for it).
With enough technological development, almost every necessity of life can be as cheap (and cheaper) as salt. Except medicine, because people will always want to live longer, but even there technology helps - poor people in first-world countries have access to much better healthcare than even the riches human 100 years ago.
Great elaboration. If the government kept small like the founding fathers envisioned, I am 99% sure an American would be able to live comfortably on one day of work per week today. They were able to raise a family with one salary way back, and with how much productivity has increased (and would have further increased if not for the government) today would be very different.
>A bureaucrat has never created a solution
>make basic life cheap and efficient
I'm interested in your take on how we exercise total control over the cost of living without any sort of bureaucratic processes being implemented?
If vendors are required to accept UBI credit for certain goods and services and must then collect payment from the government, the government is able to restrict inflation by refusing to pay inflated prices.
A "UBI-like system" has such broad range and flexibility of design and implementation that to dismiss it entirely while suggesting (im not sure exactly what to call your suggestion) market manipulation? is ludicrous.
There is a finite amount of work that needs to be done to sustain the necessities for everyone. basic life IS cheap and efficient, but we arent allowed to pay for what it is. I cant buy a simple small house for cheap, because someone who already has a house can afford to pay more and then rent it to me instead.
There NEEDS to be a centralized power separating out basic needs purchasing from "extra" purchasing. All of the "extra" economic activity should be more expensive and the basic needs purchasing should be cheaper. You cannot accomplish that without government. you need centralized power to enforce it.
>make basic life cheap and efficient
I'm interested in your take on how we exercise total control over the cost of living without any sort of bureaucratic processes being implemented?
If vendors are required to accept UBI credit for certain goods and services and must then collect payment from the government, the government is able to restrict inflation by refusing to pay inflated prices.
A "UBI-like system" has such broad range and flexibility of design and implementation that to dismiss it entirely while suggesting (im not sure exactly what to call your suggestion) market manipulation? is ludicrous.
There is a finite amount of work that needs to be done to sustain the necessities for everyone. basic life IS cheap and efficient, but we arent allowed to pay for what it is. I cant buy a simple small house for cheap, because someone who already has a house can afford to pay more and then rent it to me instead.
There NEEDS to be a centralized power separating out basic needs purchasing from "extra" purchasing. All of the "extra" economic activity should be more expensive and the basic needs purchasing should be cheaper. You cannot accomplish that without government. you need centralized power to enforce it.
I would suggest reading or listening to Thomas Sowelll's Basic Ecconomics. Even just listening to the first chapter should convince you that a centralized power is a bad idea.
https://www.youtube.com/watch?v=OrPxEmOV0YI
Thomas Sowell seems very considerate of the opinions he forms, I'll check it out. I do already agree in general that centralized power is typically a bad idea. We cannot avoid it, however. For example, the Police force exists as a phenomenon. Without them, a group of people will naturally form privately and specialize in protection services under self-serving chaotic interests (a "mafia" for short). And since they are responsible for protection, they will be able to enforce their chaotic will upon anyone. This is because human-to-human interaction can be extremely volatile and we are capable of killing each other quickly. So it might not be ideal for economics, but we still exist as part of nature and need to account for that.
We must rely on social contracts to stabilize human interaction enough for an economic system to even be possible. Buying and Selling is meaningless when Looting and Destruction are nonpunishable. A social contract is meaningless if we do not punish people for breaking them. A government is a collection of such contracts. The US government differentiates these contracts by various types and instills a separation of powers as a public framework for dealing with dangers of centralized power. Mafias have no such considerations
Power still continues to consolidate among "mafia"s. They are less effective directly as a result of public centralized powers. I believe the next evolution in this war is the differentiation between what people need and what people want. They should not operate under the same economic model. If I WANT the food you NEED to eat, I should let you have it and pursue purchasing it from you instead. that should be a social contract.
This should be common sense, but in the world we live in there is no visibility to what is needed vs what is wanted. People would be incentivized to claiming a NEED on as much as possible. "Bad" Public centralized power used to enforce reasonable claims to NEEDs is the only way forward given the nature of our reality. "Only way" sounds limiting, but of course there are a million+ different ways we can go about it.
We must rely on social contracts to stabilize human interaction enough for an economic system to even be possible. Buying and Selling is meaningless when Looting and Destruction are nonpunishable. A social contract is meaningless if we do not punish people for breaking them. A government is a collection of such contracts. The US government differentiates these contracts by various types and instills a separation of powers as a public framework for dealing with dangers of centralized power. Mafias have no such considerations
Power still continues to consolidate among "mafia"s. They are less effective directly as a result of public centralized powers. I believe the next evolution in this war is the differentiation between what people need and what people want. They should not operate under the same economic model. If I WANT the food you NEED to eat, I should let you have it and pursue purchasing it from you instead. that should be a social contract.
This should be common sense, but in the world we live in there is no visibility to what is needed vs what is wanted. People would be incentivized to claiming a NEED on as much as possible. "Bad" Public centralized power used to enforce reasonable claims to NEEDs is the only way forward given the nature of our reality. "Only way" sounds limiting, but of course there are a million+ different ways we can go about it.
Lol what a loaded statement. There are plenty of government programs that have produced better lives for people after being implemented. Imagine being this religious and blind about state-market interactions.
A bureaucrat decides whether to add a hurdle or not. Now once in a while they do things that end up positively affecting some of the population, but at what cost?
Life is more nuanced than your bad faith one-sided takes. I think deep down you know this. You should stop spreading exaggerated propaganda.
I don’t think people that want UBI are bad-faith, they are more likely naive. Asking for life to be cheap and efficient so people can live with little work if they want is spreading propaganda, while asking for the biggest monopoly that had killed people for war experiments, to get a lot more power is somehow being good-faith and responsible person? I’ll let others decide this one.
UBI might not be the solution but how is that in any way simpler to do or even to conceive
All you have to do is have bureaucrats remove the hurdles they added. It will just take some time.
Just to pick one example, do you see something like state-imposed food standards as a 'hurdle' added by bureaucrats? What about housing construction standards?
One person's hurdle can be another person's safety net?
Yes monopolistic regulations are 100percent hurdles. Now free market standards that people can choose (if they want more safety net), or personal standards, well they don't affect everyone so those are fine.
Do you consider a Director as a manager of managers?
Yeap. It's manager^2. Thankfully at that level they are so detached, that they could be a highly paid potato and it wouldn't change much for the people at bottom doing the actual work.
At one company I worked at, after I quit, they had to hire 19 engineers to rebuild the piece of software I built on my own. What took me 9 months took them a year. I quit because they wouldn't give me a raise. Even the CTO recognized to me that I was the most skilled programmer there. I don't think talent is that hard to spot and while I agree measuring programming productivity in a concrete manner is difficult, knowing who's above average isn't hard.
Seems more to me that managers just don't want to fork over higher salaries and engineering is looked at as a cost center to be minimized.
Seems more to me that managers just don't want to fork over higher salaries and engineering is looked at as a cost center to be minimized.
You probably should have gotten the raise, and there are some fair and unfair reactions to you here. There isn’t enough information to judge if you’re summarizing this fairly, but maybe this is related: one thing I’ve seen happen many times over is that the first person or first few people to work on a project have a massive productivity advantage over people that come later. We could call it “10x” but it’s not measurable, it’s just very large.
The reason that first-in people are more productive is they are witness to all of the initial assumptions and initial architecture, they decide and understand how every corner of the thing works, and they understand how to refactor it quickly and change core pieces of the pipeline. By the time other people join later, there’s a whole bunch of dependencies that make it both difficult to understand the whole system and time-consuming to change - a core piece has subsystems that depend on it, and each subsystem has unit tests, etc. etc.. People who don’t have familiarity with the entirety of the system have to make small changes and tread carefully, and this is almost completely independent of the skill of the programmer.
The strongest example of this is when I built a codebase with a partner for a cloud service in a year, and then sold the company to a group of engineers that I believe are probably better than I am. It took them much longer, several years, to get to the point where they could swap out and rewrite major features. But it’s absolutely clear to me this wasn’t because I’m more productive than they are, it’s because the system complexity was high, learning what I did and why took a lot of time, my documentation was sub-par, I wasn’t around enough and able to help them understand what I did.
BTW did you try to get other programmers involved? Is it possible part of the issue was doing too much solo work and not communicating enough? Not saying this has anything to do with you, but I’ve known and managed some very highly skilled programmers that are difficult to work with despite their apparent code productivity. It just means that skill and code output are only part of the job, and high skill can’t always overcome other issues.
The reason that first-in people are more productive is they are witness to all of the initial assumptions and initial architecture, they decide and understand how every corner of the thing works, and they understand how to refactor it quickly and change core pieces of the pipeline. By the time other people join later, there’s a whole bunch of dependencies that make it both difficult to understand the whole system and time-consuming to change - a core piece has subsystems that depend on it, and each subsystem has unit tests, etc. etc.. People who don’t have familiarity with the entirety of the system have to make small changes and tread carefully, and this is almost completely independent of the skill of the programmer.
The strongest example of this is when I built a codebase with a partner for a cloud service in a year, and then sold the company to a group of engineers that I believe are probably better than I am. It took them much longer, several years, to get to the point where they could swap out and rewrite major features. But it’s absolutely clear to me this wasn’t because I’m more productive than they are, it’s because the system complexity was high, learning what I did and why took a lot of time, my documentation was sub-par, I wasn’t around enough and able to help them understand what I did.
BTW did you try to get other programmers involved? Is it possible part of the issue was doing too much solo work and not communicating enough? Not saying this has anything to do with you, but I’ve known and managed some very highly skilled programmers that are difficult to work with despite their apparent code productivity. It just means that skill and code output are only part of the job, and high skill can’t always overcome other issues.
The context you're presenting is different from the one presented by GP. Making a few generous assumptions, both GP and the team started from the same point (requirements) and made a similar system, same inputs, same outputs. If that is the case, doing it in a shorter timeframe, while alone compared to a team of devs is insane.
I don't necessarily buy GP's story, but it's not the same story as "reading up and extending a system is harder than making a system", where group B would have a different starting point as group A.
I don't necessarily buy GP's story, but it's not the same story as "reading up and extending a system is harder than making a system", where group B would have a different starting point as group A.
I can't see why you don't buy it. I have seen this kinda thing happening dozens of times in my career. Both in startups (especially in startups!) but also very frequently even in enterprise.
One developer makes a system in N months, a team of people is hired to rewrite it, it takes 2x or 3x the amount of time. A tale as old as time.
It is kinda obvious from the get go that it would take more time. With 19 developers there is a much larger organisation and communication overhead. If there's more managers, then means A LOT of bikshedding. In enterprise, there's probably someone responsible for the architecture, there will most certainly involve architecture astronautics "to help developers move faster", which will invariably make them slower.
One developer makes a system in N months, a team of people is hired to rewrite it, it takes 2x or 3x the amount of time. A tale as old as time.
It is kinda obvious from the get go that it would take more time. With 19 developers there is a much larger organisation and communication overhead. If there's more managers, then means A LOT of bikshedding. In enterprise, there's probably someone responsible for the architecture, there will most certainly involve architecture astronautics "to help developers move faster", which will invariably make them slower.
Years ago I did a weekend hackathon. My team came in second. The first team was 13 people - 8 or 9 were 'devs' of some stripe. Our team was 3 people - me as the only developer.
My 'hack demo' was far more 'advanced' with respect to functioning stuff than the winning team, who faked a bit of their presentation. They had a lot of stuff, and a good idea, but... in 2 days, there's not much time to make decisions. Showed a demo after a day to a few others - someone from the eventual winning team kinda smirked and poked a bit of fun, making some comment about how we weren't all that far ahead of his team. I replied back that I was the only developer, and there were only 3 of us, and .. got a small jaw drop from him.
We simply didn't have the overhead of the other teams. We had someone with an idea, discussed in a small team, and me implementing, and I got to say 'no' to a whole lot of things that, in a larger team, we'd have tried to split up and hack on in parallel.
I'm not at all saying the questioning isn't valid - we don't have enough context to know definitively what conclusions to draw. BUT... a small group of people (or individual) with the right tools, aptitude, motivation and time can accomplish a whole lot more than many people assume.
My 'hack demo' was far more 'advanced' with respect to functioning stuff than the winning team, who faked a bit of their presentation. They had a lot of stuff, and a good idea, but... in 2 days, there's not much time to make decisions. Showed a demo after a day to a few others - someone from the eventual winning team kinda smirked and poked a bit of fun, making some comment about how we weren't all that far ahead of his team. I replied back that I was the only developer, and there were only 3 of us, and .. got a small jaw drop from him.
We simply didn't have the overhead of the other teams. We had someone with an idea, discussed in a small team, and me implementing, and I got to say 'no' to a whole lot of things that, in a larger team, we'd have tried to split up and hack on in parallel.
I'm not at all saying the questioning isn't valid - we don't have enough context to know definitively what conclusions to draw. BUT... a small group of people (or individual) with the right tools, aptitude, motivation and time can accomplish a whole lot more than many people assume.
Yep. One of the most important books in our field, The Mythical Man Month, agrees with a lot of this. But we still choose to keep ignoring it at our own peril.
The part about having one dev doing most of the work is even suggested in the book. But of course it's something impossible when "everyone is replaceable" is a requirement for modern businesses.
> I got to say 'no' to a whole lot of things that, in a larger team
That's one of the #1 tricks of writing good software for fast and cheap. Engineers get to say no to stupid shit from product/design/management/C-level.
The part about having one dev doing most of the work is even suggested in the book. But of course it's something impossible when "everyone is replaceable" is a requirement for modern businesses.
> I got to say 'no' to a whole lot of things that, in a larger team
That's one of the #1 tricks of writing good software for fast and cheap. Engineers get to say no to stupid shit from product/design/management/C-level.
Well, you're describing a scenario where you didn't really need a big team. So it stands to reason that if you have a bunch of people who want to participate--while you theoretically have more knowledge and insights to draw from it's not surprising in the slightest that can be overwhelmed by communication/discussion overhead in a tightly time-bounded situation.
It wasn't surprising to me, but it was somewhat surprising to others in the event. It just sort of goes against the conventional wisdom of "more=better", but yes, in hard-deadline situations, having one person push through is often a better option than trying to coordinate between groups.
Not fully buying it doesn't have to do with not believing the feasibility of GP's story. Rather, stories tend to be more complex than any given individual tends to represent them, and I'd like to give a full team of 19 developers the benefit of the doubt they didn't run around like headless chickens. Case in point, if you mention managers and communication outside those 19 developers, that already changes things quite a bit.
That individuals can truly develop amazing things which most teams could only hope to reach shouldn't be doubted. Plenty of solo projects with absolutely astounding results exist to prove the opposite. Enough that one could argue they fall outside the realm of 'they are geniuses with a rare talent'. Management types like to pretend developers are idiot savants capable of programming, but good developers are far more than that.
That individuals can truly develop amazing things which most teams could only hope to reach shouldn't be doubted. Plenty of solo projects with absolutely astounding results exist to prove the opposite. Enough that one could argue they fall outside the realm of 'they are geniuses with a rare talent'. Management types like to pretend developers are idiot savants capable of programming, but good developers are far more than that.
I'm completely ok with giving a team of 19 developers the benefit of the doubt, but in this case it doesn't matter if they're good or bad developers. They're 19 people. There's gonna be lots more overhead if it's a project that one person was able to do themselves.
Bring in a junior developer in the middle and you're gonna have to train them, slowing down the process. Bring in a new senior and he might not slow you down, but won't be productive for a while. Bring a designer and that overhead becomes even higher. Bring a second designer and it's even worse. Another stakeholder? Same deal.
Dailies and Retros are too crowded? Divide the team in two and bring another manager? Same deal.
Software is hard. Head count doesn't mean speed. In fact it often means the opposite.
EDIT: About solo devs, it's funny that in HN there is a bit of a cult for good developers that manage to make things useable for others, and that includes everything from products to libraries and languages. But as soon as someone tells a story about someone or some team being unable to take over a solo-dev work, their work is immediately treated as if it were complete garbage. One thing that made me a better developer was stopping having this attitude. Maybe the reason I can't understand is that I am the one who's not good enough.
EDIT 2: Btw, sorry if my tone sounds as if I'm disagreeing with you. I’m not! I also don't think you were doubting the OP. It's just that I keep seeing this industry making the same bad assumptions about team-size, year in year out.
Bring in a junior developer in the middle and you're gonna have to train them, slowing down the process. Bring in a new senior and he might not slow you down, but won't be productive for a while. Bring a designer and that overhead becomes even higher. Bring a second designer and it's even worse. Another stakeholder? Same deal.
Dailies and Retros are too crowded? Divide the team in two and bring another manager? Same deal.
Software is hard. Head count doesn't mean speed. In fact it often means the opposite.
EDIT: About solo devs, it's funny that in HN there is a bit of a cult for good developers that manage to make things useable for others, and that includes everything from products to libraries and languages. But as soon as someone tells a story about someone or some team being unable to take over a solo-dev work, their work is immediately treated as if it were complete garbage. One thing that made me a better developer was stopping having this attitude. Maybe the reason I can't understand is that I am the one who's not good enough.
EDIT 2: Btw, sorry if my tone sounds as if I'm disagreeing with you. I’m not! I also don't think you were doubting the OP. It's just that I keep seeing this industry making the same bad assumptions about team-size, year in year out.
Your assumption is fair given the industry has been trending towards 'more' as a way to be 'better', without understanding how things scale, how development isn't the same as a manufactory line and multiple types trying to pawn their arrogance off as others simply not "understanding it". I'm sure you can relate with many anecdotes where mentioned bad assumptions were sold as ICs being faulty rather than those in charge.
'More' meaning in every non-technical context. More paper, more communication, more heads to count, etc.
'More' meaning in every non-technical context. More paper, more communication, more heads to count, etc.
Exactly. The trend to more is often forced by investors etc, but this thinking is also seeping into developers.
I worked in a Softbank startup that start hiring like crazy for positions that weren't necessary, because that's what Softbank asked for. It was a crazy place to work where anything bringing productivity gains and solving developer pain wasn't rewarded. But, of course, we several people working on developer experience, because there was not enough work for all developers.
On the other hand, maybe this is a good thing. It means more jobs for developers. More money redistribution. But on the other hand it is soul crushing to see something that could be a 2-hour walk on the park becoming a 3-month transatlantic expedition involving several teams.
In the job above, I worked for a few weeks on a team that was responsible for one single screen, and this screen had three checkboxes which we used to update some third-party API. No, there wasn't much more than that. It made me want to kill myself.
I worked in a Softbank startup that start hiring like crazy for positions that weren't necessary, because that's what Softbank asked for. It was a crazy place to work where anything bringing productivity gains and solving developer pain wasn't rewarded. But, of course, we several people working on developer experience, because there was not enough work for all developers.
On the other hand, maybe this is a good thing. It means more jobs for developers. More money redistribution. But on the other hand it is soul crushing to see something that could be a 2-hour walk on the park becoming a 3-month transatlantic expedition involving several teams.
In the job above, I worked for a few weeks on a team that was responsible for one single screen, and this screen had three checkboxes which we used to update some third-party API. No, there wasn't much more than that. It made me want to kill myself.
Because if you rewrite, there’s less obligation to previous choices and tests. This should facilitate dev speed, as long as second-system is avoided.
You’re right, my starting point is slightly different, if we take the top comment at face value, or at least I agree with you that I did make slightly different apparent assumptions. Though since we’re deconstructing it now, there’s no reason you should assume the 19 person crew wasn’t looking at the poster’s original solution, the post didn’t specify same inputs, and it’s quite unlikely to be the case IMO. Poster may be ignoring the quality and extensibility of the newer design, or may be ignoring performance in favor of functionality, or ignoring documentation or updated requirements. Or, maybe they really are faster and more productive than 19 people, of course I don’t actually know anything. :)
However, I really wanted to point out I only gave a single example of something I’ve seen multiple times, I’ve witnessed the same effect (first-in advantage) even with rewrites, and (perhaps surprisingly) even with the same people the second time ‘round! There are lots of potential reasons, but the 2nd time round with the same people is a curious and interesting one, because it says something about our tendency to want to rewrite things and our inability to estimate the time to re-solve the same problems even having solved them before. I’ve seen this a few times, twice (two completely separate instances at separate companies) it was whole-team efforts that ended up costing millions of dollars in delay and the org regretted doing a rewrite instead of an incremental effort.
However, I really wanted to point out I only gave a single example of something I’ve seen multiple times, I’ve witnessed the same effect (first-in advantage) even with rewrites, and (perhaps surprisingly) even with the same people the second time ‘round! There are lots of potential reasons, but the 2nd time round with the same people is a curious and interesting one, because it says something about our tendency to want to rewrite things and our inability to estimate the time to re-solve the same problems even having solved them before. I’ve seen this a few times, twice (two completely separate instances at separate companies) it was whole-team efforts that ended up costing millions of dollars in delay and the org regretted doing a rewrite instead of an incremental effort.
Reminds me of Peter Naur's essay, "Programming as Theory Building": https://pages.cs.wisc.edu/~remzi/Naur.pdf
Love this article. It contains a very deep and important insight, that the program and programmer are inseparable. Can’t replace one without replacing the other.
People often pretend you can. In big companies a new team will “take ownership” of an existing system. But they won’t really understand it until they rewrite it. Wanting to rewrite is not a character flaw, it’s just an inherent part of the process.
That said, if one person wrote the first version, then one person can write the second version. Teams don’t have to get bigger.
People often pretend you can. In big companies a new team will “take ownership” of an existing system. But they won’t really understand it until they rewrite it. Wanting to rewrite is not a character flaw, it’s just an inherent part of the process.
That said, if one person wrote the first version, then one person can write the second version. Teams don’t have to get bigger.
I generally see what you are aiming at, but I don't think you are weighting all aspects and showing the whole story. There could be so many different views of such situation.
Was it actually rebuild from scratch? Rebuilding and taking over maintenance and support are two different efforts.
Why it had to be rebuilt? Was there a really unsuccessful attempt of a handover? Why was it so hard to hand over? Are we certain that documentation and training was sufficient for it to succeed?
Was ongoing support taken into account? Maintenance, new features, patching, monitoring - was it hard, was it clear for others how to approach those topics? Was the architecture easy to follow and pick up by others?
Expecting that others will be as genius as you may be seen as positive aim at perfection. It may also be seen as bad teamwork that will build up costs later on. Companies create standards, use "approved" frameworks and copy-paste solutions because it's then easier to support and require less people with less skill. It's hard to recruit already, you don't have to over-complicate solutions and make it even harder. Then there is a day in which your product dies on production and there is just one person who can figure out what is going on. For me it's a clear sign of poor management and we should all stay away from such practices.
Was it actually rebuild from scratch? Rebuilding and taking over maintenance and support are two different efforts.
Why it had to be rebuilt? Was there a really unsuccessful attempt of a handover? Why was it so hard to hand over? Are we certain that documentation and training was sufficient for it to succeed?
Was ongoing support taken into account? Maintenance, new features, patching, monitoring - was it hard, was it clear for others how to approach those topics? Was the architecture easy to follow and pick up by others?
Expecting that others will be as genius as you may be seen as positive aim at perfection. It may also be seen as bad teamwork that will build up costs later on. Companies create standards, use "approved" frameworks and copy-paste solutions because it's then easier to support and require less people with less skill. It's hard to recruit already, you don't have to over-complicate solutions and make it even harder. Then there is a day in which your product dies on production and there is just one person who can figure out what is going on. For me it's a clear sign of poor management and we should all stay away from such practices.
A developer leaving the company is not responsible for a successful handover or that the documentation is correct.
> A developer leaving the company is not responsible for a successful handover or that the documentation is correct.
But if the handover was unsuccessful, it can call into question the skills of that developer. I mean, instead of being a "10x" developer, maybe they were actually a 1x developer that look a lot of shortcuts and wrote unmaintainable spaghetti code (or somewhere in between). Maybe they were someone who hoarded domain knowledge and refused to share it. In any case, the employer didn't realize the claimed value of that employee's work.
But if the handover was unsuccessful, it can call into question the skills of that developer. I mean, instead of being a "10x" developer, maybe they were actually a 1x developer that look a lot of shortcuts and wrote unmaintainable spaghetti code (or somewhere in between). Maybe they were someone who hoarded domain knowledge and refused to share it. In any case, the employer didn't realize the claimed value of that employee's work.
No it doesn't, it calls into question how much redundant knowledge, code quality, documentation, and support the org values.
Which 90% of the time for anything but features and UI appearance is no value.
That allows the construction of micro-empires and dependence. Orgs either recognize that and provide resources, or they rely on shorter-term one man hero efficiencies, and pay the piper later.
They paid the piper later.
And who knows what "19" means. 19 offshores, so that's more like 6x the cost? And offshores are probably short term so they assume they'll hire one or two offshores long term which will ... maybe ... eventually get cheaper.
That's the beancounter logic. So they think long term they saved money.
Which 90% of the time for anything but features and UI appearance is no value.
That allows the construction of micro-empires and dependence. Orgs either recognize that and provide resources, or they rely on shorter-term one man hero efficiencies, and pay the piper later.
They paid the piper later.
And who knows what "19" means. 19 offshores, so that's more like 6x the cost? And offshores are probably short term so they assume they'll hire one or two offshores long term which will ... maybe ... eventually get cheaper.
That's the beancounter logic. So they think long term they saved money.
Exactly. I was working 100 hour weeks, almost all spent writing code and given no time for documentation, knowledge transfer, etc.. They bet the house on me and wouldn't pay me appropriately.
> A developer leaving the company is not responsible for a successful handover or that the documentation is correct.
It is a mutual responsibility. More often then not I've found that my manager, coworkers, etc. didn't ask any questions about my work during my notice period.
It is a mutual responsibility. More often then not I've found that my manager, coworkers, etc. didn't ask any questions about my work during my notice period.
> A developer leaving the company is not responsible ... that the documentation is correct.
I completely disagree. Documentation, however it exists, should always be correct. Whether you document by flowchart, code comments, self-reading code, or some other means, I always maintain that it should be updated as you update the code itself. Just like tests. If you only update it when you need to use it, you're missing the point of it.
I completely disagree. Documentation, however it exists, should always be correct. Whether you document by flowchart, code comments, self-reading code, or some other means, I always maintain that it should be updated as you update the code itself. Just like tests. If you only update it when you need to use it, you're missing the point of it.
If you get paid and if there is space to do that. There is often the ‘yeah yeah let’s add the rest of the features first the do docs’. I agree with you but this often goes wrong, especially at startups.
adding docs meanwhile isnt always working either as the feature product might change heavily, this is a hard discipline since you need to balance when to doc what.
A company should demand the documentation they need to understand things when the feature is under-development or shortly afterwards.
Documentation takes time. It's their fault for cutting corners and pushing out a product/service that's undocumented spaghetti code.
Documentation takes time. It's their fault for cutting corners and pushing out a product/service that's undocumented spaghetti code.
They never asked for documentation and instead pushed for more development faster.
I don’t think he is saying that a developer is in no way responsible for documentation, that is a pretty uncharitable interpretation of the comment.
I think they’re saying it is not up to the developer to make sure it happening writ large/that there is a system in place. That’s pretty much why we have managers and processes in place that everyone follows beforehand (ideally). If a company doesn’t implement systems, it’s not really up to me to do it. Often I will because it makes my life easier and I’m not a rigid “not my department” personality, but I’m not going to feel personally responsible when they drop the ball and wanted to plow ahead without putting the systems in place upfront. Especially because this often happens despite folks bringing up the need in the first place.
I think they’re saying it is not up to the developer to make sure it happening writ large/that there is a system in place. That’s pretty much why we have managers and processes in place that everyone follows beforehand (ideally). If a company doesn’t implement systems, it’s not really up to me to do it. Often I will because it makes my life easier and I’m not a rigid “not my department” personality, but I’m not going to feel personally responsible when they drop the ball and wanted to plow ahead without putting the systems in place upfront. Especially because this often happens despite folks bringing up the need in the first place.
> self-reading code
I always strive to make my code simple and readable, but there's a saying that "one person organization is another hot mess".
I always strive to make my code simple and readable, but there's a saying that "one person organization is another hot mess".
Right or wrong, docs and tests are often given the lowest priority. Everything is good in moderation: you want some docs (especially for external APIs), some tests (integration > unit in many cases), but don't go overboard. You don't need 1000 unit tests for a little CRUD app. Documentation is subject to drift. For internal APIs, you're better off looking at the code.
It was a bank with high security, so the code actually had 100% coverage in tests.
I was working 100 hour weeks and not given any time for documentation or knowledge transfer. The code was certainly self-reading but it was a very complex system, especially security wise as it was a bank. Their other developers were juniors and couldn't understand it so they threw it out and started from scratch.
I quit with no notice because I was burnt out and promised a vacation when the product launched. They renegged after denying me a raise multiple times. So I left.
I quit with no notice because I was burnt out and promised a vacation when the product launched. They renegged after denying me a raise multiple times. So I left.
I am of the opinion that a developer should always act like a professional, with the best interests of their employer in mind, and that this means doing their best to assure a smooth handover until their very last day of work.
After their last day, if they were fired, all bets are off.
After their last day, if they were fired, all bets are off.
> I am of the opinion that a developer should always act like a professional, with the best interests of their employer in mind
Sorry but bets are also off once an employer gives them the middle finger, like in this case.
If someone is admittedly trying to pay you only the minimal amount possible, it is completely reasonable that you also work the minimal amount not to be fired or sued.
It goes both ways.
Sorry but bets are also off once an employer gives them the middle finger, like in this case.
If someone is admittedly trying to pay you only the minimal amount possible, it is completely reasonable that you also work the minimal amount not to be fired or sued.
It goes both ways.
They refused me a raise on multiple occassions, worked me for 100 hours a week for 3 months straight, promised me three weeks off when the product launched, which they then renegged on. I quit with no notice to save my mental and physical health which had severely deteriorated.
So until that day, you basically accept fate if you are put in a bad situation and search around for a better job, should you get baited into taking a bad job.
Surely I don't need to tell you why many people opt for a day-by-day basis instead. Play stupid games, win stupid prizes.
Surely I don't need to tell you why many people opt for a day-by-day basis instead. Play stupid games, win stupid prizes.
A developer should ABSOLUTELY be responsible for ensuring something they have built is adequately documented to continue functioning despite being run over by a bus
I want to agree with you, but actually can't.
He should not be responsible. Because he already failed - he should have had that under control while he was working on it, from the very first day. Not on his notice period.
We push a mentality of devops and the whole team (regardless of their position) being responsible for the final product. Push interdisciplinary attitude, where fine defined borders of each team/job fade. That developer IS responsible for that and if it's not covered by the time of his notice period it means both him and his management failed in some extent.
We push a mentality of devops and the whole team (regardless of their position) being responsible for the final product. Push interdisciplinary attitude, where fine defined borders of each team/job fade. That developer IS responsible for that and if it's not covered by the time of his notice period it means both him and his management failed in some extent.
thank you
u/gsibble's story sounds familiar to me.
People aren't rational, nothing ever makes any sense.
I once build a budgeting and estimating tool (for architecture). Super simple, just worked. The PHBs brought in consultants to "solve the problem". Two years later, my tool was being used on the downlow, like some kind of contraband, because the replacement never worked.
Another time, another place, I was brought in to rescue a project. Four devs spent about a year on an enterprisey monstrosity. It wouldn't even compile. Once I understood the task, I banged out a tool, using node.js & AWS for the first time, in two weeks. Then another 2 weeks to get into production. Clients were ecstatic.
I have many more examples.
FWIW, I'm a very average programmer; I just try to solve the problem in front of me. But I like to think I'm really good at requirements, analysis, customer communications, etc.
I once build a budgeting and estimating tool (for architecture). Super simple, just worked. The PHBs brought in consultants to "solve the problem". Two years later, my tool was being used on the downlow, like some kind of contraband, because the replacement never worked.
Another time, another place, I was brought in to rescue a project. Four devs spent about a year on an enterprisey monstrosity. It wouldn't even compile. Once I understood the task, I banged out a tool, using node.js & AWS for the first time, in two weeks. Then another 2 weeks to get into production. Clients were ecstatic.
I have many more examples.
FWIW, I'm a very average programmer; I just try to solve the problem in front of me. But I like to think I'm really good at requirements, analysis, customer communications, etc.
> But I like to think I'm really good at requirements, analysis, customer communications, etc.
This goes so much farther than people think. So many people think that if they learn to write code, they'll be effective in this line of work. Writing effective code is one part of a balanced skillset necessary to do good work.
This goes so much farther than people think. So many people think that if they learn to write code, they'll be effective in this line of work. Writing effective code is one part of a balanced skillset necessary to do good work.
the company may have decided that the product is just more important than when OP was still working there so it requires more engineers to expand it etc.
however other than that if OP isn't lying I can't see any way how a 1 vs 19 situation is anything but a failure for the company lol. maybe 1 vs 2 or 1 vs 3.
however other than that if OP isn't lying I can't see any way how a 1 vs 19 situation is anything but a failure for the company lol. maybe 1 vs 2 or 1 vs 3.
I am very senior (25+ years experience) and they used all jrs (1-3 yrs). They seemed of the mindset that monkeys can write Shakespeare.
>> Why it had to be rebuilt? Was there a really unsuccessful attempt of a handover?
This is a good question. It could be either that management is incompetent or that the code was unmaintainable. But still, the fact that it took a team of people much longer to build does prove a point. For projects of this size, it's difficult to build them fast unless the code is maintainable, even if it's just a team of 1.
There can be some extreme cases of corner-cutting which can deliver fast short term results but even this has its limits. The complexity or security issues tend to catch up with you quite quickly.
This is a good question. It could be either that management is incompetent or that the code was unmaintainable. But still, the fact that it took a team of people much longer to build does prove a point. For projects of this size, it's difficult to build them fast unless the code is maintainable, even if it's just a team of 1.
There can be some extreme cases of corner-cutting which can deliver fast short term results but even this has its limits. The complexity or security issues tend to catch up with you quite quickly.
Management was incompetent and I have proof. Their stock hit a high of $15 less than six months ago. It's currently sitting at $0.66. They went from $5.5 billion to $255 million in market cap in less than six months.
They had many problems.
They had many problems.
I quit with no notice so there was no attempt to hand over. I was the only senior at the company (25+ years experience) and the rest were jrs (1-3 years). The 19 people that replaced me were juniors who developed whole new software based upon a monolithic architecture since they couldn't understand my complex Microservices based one.
If the company is large, it’s not that recognizing talent is hard, it’s rewarding talent. I’ve worked at places that lock in 3% average compensation increases for departments. That includes promotions. So in a team of 5, if you give one person a 15% raise, everyone else gets zero. This is a ham fisted way that companies keep salaries under control.
It’s not that managers don’t know who is good, it’s that they can’t do anything about it.
It’s not that managers don’t know who is good, it’s that they can’t do anything about it.
Reminds me of the story a couple years back where Honda Japan couldn’t hire any AI engineers because their high salaries wouldn’t fit into the company’s pay grades.
This kind of happens in America today. I've worked for a Fortune 500 company that had a lot of trouble hiring good engineers on a full time basis, as the powers that be had decided that they shouldn't compare developer salaries to the market as large, but just their specific industry, so their idea of average market rate was off by tens of thousands of dollars.
When dealing with capital projects and contractors, however, they had no problems whatsoever giving people on very long contracts hourly rates that weren't just good for their industry, but would have been good for Northern California. I worked for 3 years straight, 40 hours a week, where I was making three times the take-home pay than coworkers with the same responsibilities. And this was after accounting for all taxes, health care, and giving myself more days off than the full time workers did.
Management seemed fine with that arrangement too. Said coworker's direct manager tried to talk to the CTO about the situation. The argument was that if they were happy paying people like me really well, and that they were losing their best FTEs to other companies in a regular basis, that maybe they should pay their best workers a competitive way, instead of ending up with FTEs that just were not competent enough to be hired at regular rates somewhere else. The answer was "If our best FTEs are getting poached by west coast companies, this means that we are good at training"
Remember the story about how some government agencies in charge of building things are getting hollowed out, losing all expertise, leading to very slow, very expensive projects being mostly handled by consultants? It's how it works in software for a big percentage of private sector firms that were already big in the 1970s.
When dealing with capital projects and contractors, however, they had no problems whatsoever giving people on very long contracts hourly rates that weren't just good for their industry, but would have been good for Northern California. I worked for 3 years straight, 40 hours a week, where I was making three times the take-home pay than coworkers with the same responsibilities. And this was after accounting for all taxes, health care, and giving myself more days off than the full time workers did.
Management seemed fine with that arrangement too. Said coworker's direct manager tried to talk to the CTO about the situation. The argument was that if they were happy paying people like me really well, and that they were losing their best FTEs to other companies in a regular basis, that maybe they should pay their best workers a competitive way, instead of ending up with FTEs that just were not competent enough to be hired at regular rates somewhere else. The answer was "If our best FTEs are getting poached by west coast companies, this means that we are good at training"
Remember the story about how some government agencies in charge of building things are getting hollowed out, losing all expertise, leading to very slow, very expensive projects being mostly handled by consultants? It's how it works in software for a big percentage of private sector firms that were already big in the 1970s.
This trips up large companies all the time. They can’t hire SAP or AI or cloud or whatever is hot. The good ones train their own, but even then they can’t keep them when they’re paid 40% below market for the skill.
The irony is the same companies can pay 3x the comp for external consultants.
The irony is the same companies can pay 3x the comp for external consultants.
I was told it's different budget line, so nobody really cares. HR just does not like to see IT being paid 4 times as much as them.
> The irony is the same companies can pay 3x the comp for external consultants.
I once worked for a university during a large ERP migration.
There was a mix of employees and consultants working on the migration.
Everyone that the university managed to hire (at salaries WAY below-market price) was almost immediately snatched and started working as consultants themselves (in other companies, obviously). And rightly so.
I once worked for a university during a large ERP migration.
There was a mix of employees and consultants working on the migration.
Everyone that the university managed to hire (at salaries WAY below-market price) was almost immediately snatched and started working as consultants themselves (in other companies, obviously). And rightly so.
Can confirm. As a low-level manager at a large company, I have pretty much no control over compensation beyond ranking my directs. Someone above my manager merges the lists together and draws a line. I've had good engineers leave because of this, and I don't blame them.
yep... robbing peter to pay paul. Until someone on your team threatens to quit, at which you're given more money all of a sudden to retain.
Sadly, 90% of them just quit before there is even a chance to give mid cycle raise.
Sadly, 90% of them just quit before there is even a chance to give mid cycle raise.
You would think that if management had known it would cost them at least 19x what they were paying you, they would be happy to give you whatever raise you asked. But, maybe not. There are a lot of other factors.
There's a trust factor. For some reason, upper management doesn't necessarily trust the judgement of their lower management, like like lower management rarely trusts the judgement of their engineers.
There's an information disparity. Upper management often doesn't see what people on the lower rungs of the org chart are doing. To upper management, it looks like the one who's getting all the things done is lower management, not the engineers.
There's also a psychological factor. For some reason, humans are much more likely to overpay for something new than to pay far less to maintain something old. I'm not entirely sure why, but I see this mentality affect everybody from upper management to engineers to people buying cars.
There's also the ego factor. I've seen some business owners react very, very poorly to having an employee request a raise. It can be perceived as somebody trying to take more money out of your pocket for no return. This can also be applied to larger companies and budgets, bonuses, etc.
There's also the "fiefdom" factor. Your management might see expanding your team from 1 engineer to 19 as an improvement to their social standing in the company regardless of how much money it costs the company. The larger your department, the more important you're perceived to other departments and the c-suite.
edit: spelling and clarity.
There's a trust factor. For some reason, upper management doesn't necessarily trust the judgement of their lower management, like like lower management rarely trusts the judgement of their engineers.
There's an information disparity. Upper management often doesn't see what people on the lower rungs of the org chart are doing. To upper management, it looks like the one who's getting all the things done is lower management, not the engineers.
There's also a psychological factor. For some reason, humans are much more likely to overpay for something new than to pay far less to maintain something old. I'm not entirely sure why, but I see this mentality affect everybody from upper management to engineers to people buying cars.
There's also the ego factor. I've seen some business owners react very, very poorly to having an employee request a raise. It can be perceived as somebody trying to take more money out of your pocket for no return. This can also be applied to larger companies and budgets, bonuses, etc.
There's also the "fiefdom" factor. Your management might see expanding your team from 1 engineer to 19 as an improvement to their social standing in the company regardless of how much money it costs the company. The larger your department, the more important you're perceived to other departments and the c-suite.
edit: spelling and clarity.
The thing is that they never realize this until it's too late... once it's too late, they are too usually too proud to ask you to come back. That's what easy money does to people, it makes them proud and complacent.
Most of the tech industry is built on easy money. Fast growth which required little effort.
All of these people think that they worked hard for their money, but what they call 'hard work', I call 'easy peasy' and what they call 'very risky', I call 'low risk'.
99.99% of the population would probably turn to communism if they had worked as hard as I did for so little reward... That said, my stance is apathetic. It's all the same to me.
If you can get by in one hopelessly crooked system, you can probably get by in a different hopelessly crooked system.
Most of the tech industry is built on easy money. Fast growth which required little effort.
All of these people think that they worked hard for their money, but what they call 'hard work', I call 'easy peasy' and what they call 'very risky', I call 'low risk'.
99.99% of the population would probably turn to communism if they had worked as hard as I did for so little reward... That said, my stance is apathetic. It's all the same to me.
If you can get by in one hopelessly crooked system, you can probably get by in a different hopelessly crooked system.
> There's a trust factor. For some reason, upper management doesn't necessarily trust the judgement of their lower management, like like lower management rarely trusts the judgement of their engineers.
They should have their own judgement on the effectiveness of their direct reports. The problem is that they trust their own judgement while having poor judgement themselves. Trust could also be an issue but assessing effectiveness is something gained over time, not self-declared.
They should have their own judgement on the effectiveness of their direct reports. The problem is that they trust their own judgement while having poor judgement themselves. Trust could also be an issue but assessing effectiveness is something gained over time, not self-declared.
>I'm not entirely sure why
I’ve always seen it as an offshoot of the mentality that fixing something old is often delaying an inevitable new purchase (especially when it comes to tech). Total armchair theory based on how if it’s limping along usually they’ll go “well just keep using it we’ll upgrade later.”
I’ve always seen it as an offshoot of the mentality that fixing something old is often delaying an inevitable new purchase (especially when it comes to tech). Total armchair theory based on how if it’s limping along usually they’ll go “well just keep using it we’ll upgrade later.”
> and engineering is looked at as a cost center to be minimized
Labor is a cost center to be minimized for a business.
Your goal is to make money. If you can do that by having $0 in labor costs, then you want to.
The reason programmers aren't paid in proportion to their productivity is the same that every other profession also is not.
You get paid the least your employer can get away with paying you, not what you "deserve".
It's better if everyone recognizes this.
You probably want to avoid companies where the incentives aren't in place for you to grow.
Labor is a cost center to be minimized for a business.
Your goal is to make money. If you can do that by having $0 in labor costs, then you want to.
The reason programmers aren't paid in proportion to their productivity is the same that every other profession also is not.
You get paid the least your employer can get away with paying you, not what you "deserve".
It's better if everyone recognizes this.
You probably want to avoid companies where the incentives aren't in place for you to grow.
> You get paid the least your employer can get away with paying you, not what you "deserve".
This approach works only for stuff that won't give you 2 week notice because they have got 10% raise elsewhere.
In a real world it would be akin to buying a new car when current one suddenly stops working instead paying for routine service. Maintaining a car is also "a cost", and you can drive it for as little as you "can get away with".
The actual real reason is that most management is just bunch of morons busy optimizing for their own success, and no one worrying about any common sense good of the company.
This approach works only for stuff that won't give you 2 week notice because they have got 10% raise elsewhere.
In a real world it would be akin to buying a new car when current one suddenly stops working instead paying for routine service. Maintaining a car is also "a cost", and you can drive it for as little as you "can get away with".
The actual real reason is that most management is just bunch of morons busy optimizing for their own success, and no one worrying about any common sense good of the company.
> The actual real reason is that most management is just bunch of morons busy optimizing for their own success, and no one worrying about any common sense good of the company.
Why should management optimize for improving you? Management is planning to job hop to a better future just like you should be doing...
We do not live in a utilitarian utopia. The world is not optimized so everyone helps everyone reach their full potential. The people at the top are selfish - by virtue of being selfish, you're more likely to get there.
Sure, it's easy to rise to the top if the tide lifts everyone to the top. But most people get to the top by stepping on everyone else's head.
Why should management optimize for improving you? Management is planning to job hop to a better future just like you should be doing...
We do not live in a utilitarian utopia. The world is not optimized so everyone helps everyone reach their full potential. The people at the top are selfish - by virtue of being selfish, you're more likely to get there.
Sure, it's easy to rise to the top if the tide lifts everyone to the top. But most people get to the top by stepping on everyone else's head.
> Labor is a cost center to be minimized for a business.
It's worth calling out that this is not an absolute value. It's definitely the predominant one, but businesses can and do exist where the core motive is to make sure that everyone working for the company shares in the success of the company equally.
And I think it is past time to be challenging that status quo
It's worth calling out that this is not an absolute value. It's definitely the predominant one, but businesses can and do exist where the core motive is to make sure that everyone working for the company shares in the success of the company equally.
And I think it is past time to be challenging that status quo
Unpopular view here ... if it took 19 engineers to rebuild your software - that seems like a failure on your part (not theirs).
I don't think there is enough context to determine that. It seems plausible that it could maybe be a mix of being highly productive due to the lack of overhead of working with many other people and some obfuscation through complexity probably for the same reason that he wasn't working with other people and could optimize for only his own legibility.
There are a lot of explanations possible.
I’ve deal with with the aftermath of with “80% developers” my entire career. In two weeks, they’d write a good enough program with no handling of edge cases or errors.
Replacing one of these with a proper application can take a year.
I’ve also dealt with a team of programmers who couldn’t come close to my productivity solo. It was due to constraints and communication overhead, not incompetence.
When you go from a solo dev to a team of 19, that sounds more like a change in strategy by management than anything else.
I’ve deal with with the aftermath of with “80% developers” my entire career. In two weeks, they’d write a good enough program with no handling of edge cases or errors.
Replacing one of these with a proper application can take a year.
I’ve also dealt with a team of programmers who couldn’t come close to my productivity solo. It was due to constraints and communication overhead, not incompetence.
When you go from a solo dev to a team of 19, that sounds more like a change in strategy by management than anything else.
I’m not sure what you mean by 80% developers, but I am generally cautious on developers who are seen as uber productive. I worked with one in the past, and they would blow through so much code. It amazed everyone else, but they left a literal wake in the code. It was just a gigantic mess when you dove into it that wasted so much time down the road in onboarding others, refactoring it, maintaining it, etc.
Sorry, I should have clarified, they are developers that quickly do 80% of the work and move to the next thing.
They are often quite intelligent and very productive, but aren't inclined to think a problem through to completion.
They are often quite intelligent and very productive, but aren't inclined to think a problem through to completion.
Gotcha, and no worries! That makes perfect sense. I was just calling it out that I wasn't for sure to ward off inadvertently supporting or commenting on something I wasn't sure about.
[deleted]
Yeah, I've inherited a mess of software written by one of those before.
I used to have some imposter syndrome because I wasn't that hyper productive, but not after having to clean that code up.
For example, I found a supposedly queue-less parallel map / threadpool with 2 or 3 queues inside of it, which had weird deadlock bugs that would result in strange occasional timeouts. I replaced it with a parallel map with no queues built on top of a thin and standardized threading library. The deadlocks went away. The resulting code was pretty boring in readable. I never bothered to dig into why the old code deadlocked, but throwing it all away fixed all the problems.
It is a lot easier to greenfield where you can put off the edge conditions till later and focus entirely on the first 80%, it is also really easy to greenfield when you focus on just typing as fast as you can and spray sloppy code everywhere (actually sloppy code like that crazy parallel map implementation I threw away). I suspect the latter is what a lot of "10x developers" actually are.
I used to have some imposter syndrome because I wasn't that hyper productive, but not after having to clean that code up.
For example, I found a supposedly queue-less parallel map / threadpool with 2 or 3 queues inside of it, which had weird deadlock bugs that would result in strange occasional timeouts. I replaced it with a parallel map with no queues built on top of a thin and standardized threading library. The deadlocks went away. The resulting code was pretty boring in readable. I never bothered to dig into why the old code deadlocked, but throwing it all away fixed all the problems.
It is a lot easier to greenfield where you can put off the edge conditions till later and focus entirely on the first 80%, it is also really easy to greenfield when you focus on just typing as fast as you can and spray sloppy code everywhere (actually sloppy code like that crazy parallel map implementation I threw away). I suspect the latter is what a lot of "10x developers" actually are.
It was a combination of being the sole decision maker, architect, product manager, etc. without having to coordinate with a team, being very senior (25+ years), being a very fast coder (I produced 4x the lines of code of anyone else at the company during my year there), and the fact they only hired jrs other than me straight out of coding camps. They expected code monkeys to write Shakespeare. This was a bank with extreme security requirements that I build in a high sophisticated microservice architecture. My code was easy to read, but the systems were certainly not easy to understand, especially to jrs with zero experience in microservices, Kubernetes, devops at all, etc..
Can you develop?
It seems to me the need to rewrite the project at all, depending on the reasons, could be the failure, not that it took one year and 19 engineers to do it.
It seems to me the need to rewrite the project at all, depending on the reasons, could be the failure, not that it took one year and 19 engineers to do it.
Yes, we're lacking context here. Most of the time developers will want to build things from scratch given the opportunity. It's simply easier (from one's opinion) and the time gap may provide with better tooling and frameworks. That applies whether the new lead developer is good or bad.
And longer time is not a good indicator too, since previously op may cutting corners to make development faster.
However 19 engineers handling one project that can be handled by one person previously is imo, a sign of not optimized work. That is, granted if the scope of work is the same for both.
And longer time is not a good indicator too, since previously op may cutting corners to make development faster.
However 19 engineers handling one project that can be handled by one person previously is imo, a sign of not optimized work. That is, granted if the scope of work is the same for both.
IME it's a sign of one developer doing their best to get a system up and running well enough for business to get by (basically a MVP) and business not providing the staff necessary to improve upon it until it is too late. Maybe it needed 19 engineers all along. At least, that has been my experience in the past.
Junior/mid devs will rewrite something they don't understand, rather than analyze and understand it. Everyone wants a green field project.
can you explain?
there's no logical link here for me at all. if OP was never born and they had to build that app from scratch, and it took them 1 year and 19 engineers to do it, you wouldn't be posting the same thing.
there's no logical link here for me at all. if OP was never born and they had to build that app from scratch, and it took them 1 year and 19 engineers to do it, you wouldn't be posting the same thing.
To me there is no logical reason for needing 19 engineers other than poor documentation, written in a niche language (or non-standard for the org) or they use a consulting firm that of course said it will take 19 engineers and needs rebuilding.
Why, in any scenario, would something well coded and documented need that amount of rework otherwise? Aside political, ego reasons that is...
Why, in any scenario, would something well coded and documented need that amount of rework otherwise? Aside political, ego reasons that is...
I watched something similar play out once upon a time, albeit not quite to the scale of 19 developers, but rather six developers. I expect a team of 19 would have found a similar fate.
The rework was driven by a desire to move an existing web application to mobile. That was fair enough, I suppose. Given the market they were trying to go after I think that was a reasonable choice. But alongside that it was decided by the powers that be that the entire backend, which was already well abstracted from the frontend and would have transitioned to mobile quite nicely, would be replaced by Firebase to speed up development for the team of junior frontend-focused developers it hired to build the project. That choice was far more dubious, but the leaders were convinced it would speed up development and allow them to hire cheaper workers.
The initial prototype of the rewrite was stood up impressively quickly. However, the weight of the technical debt accumulated during that time saw further development start to crawl to a snail's pace. For example, every little new data access pattern that came up revealed that the database (Firestore) wasn't structured effectively for the use case requiring a lot of work in constantly massaging the data. The automated test suite found in the original was also foregone in the rewrite, which multiplied the manual effort required to verify every change. And there was, simply, a much higher defect rate. Months upon months were spent just fixing bugs.
Long story short, new leadership wanted to focus on mobile and thought they could do it faster and cheaper switching to tech that low-cost developers would be capable of using. One reasonable, in my opinion, choice followed by a whole lot of bad choices. Perhaps that falls under political/ego reasons, but I'm not so sure. The intent was sound, but the execution fell flat.
The rework was driven by a desire to move an existing web application to mobile. That was fair enough, I suppose. Given the market they were trying to go after I think that was a reasonable choice. But alongside that it was decided by the powers that be that the entire backend, which was already well abstracted from the frontend and would have transitioned to mobile quite nicely, would be replaced by Firebase to speed up development for the team of junior frontend-focused developers it hired to build the project. That choice was far more dubious, but the leaders were convinced it would speed up development and allow them to hire cheaper workers.
The initial prototype of the rewrite was stood up impressively quickly. However, the weight of the technical debt accumulated during that time saw further development start to crawl to a snail's pace. For example, every little new data access pattern that came up revealed that the database (Firestore) wasn't structured effectively for the use case requiring a lot of work in constantly massaging the data. The automated test suite found in the original was also foregone in the rewrite, which multiplied the manual effort required to verify every change. And there was, simply, a much higher defect rate. Months upon months were spent just fixing bugs.
Long story short, new leadership wanted to focus on mobile and thought they could do it faster and cheaper switching to tech that low-cost developers would be capable of using. One reasonable, in my opinion, choice followed by a whole lot of bad choices. Perhaps that falls under political/ego reasons, but I'm not so sure. The intent was sound, but the execution fell flat.
> To me there is no logical reason for needing 19 engineers other than poor documentation
They're rebuilding it from scratch. The documentation needed to build a system from scratch should be provided entirely by management, product managers and product owners.
Should developers write some documentation? Sure. But "how to rewrite this shit from scratch" is not the kind of documentation developers should be writing.
Talented people do exist. And untalented developers are more common than talented ones. There's no reason to doubt OP or to call him a shitty documentation writer just so it matches your world view.
They're rebuilding it from scratch. The documentation needed to build a system from scratch should be provided entirely by management, product managers and product owners.
Should developers write some documentation? Sure. But "how to rewrite this shit from scratch" is not the kind of documentation developers should be writing.
Talented people do exist. And untalented developers are more common than talented ones. There's no reason to doubt OP or to call him a shitty documentation writer just so it matches your world view.
Thank you. The biggest issues were:
- I was not ever told to write documentation, never given time to do it, and was working around 100 hour weeks, almost all spent coding, under tight deadlines.
- I'm a senior developer / Architect with 25+ years experience and a degree in Computer Engineering from a top school
- The 19 people who replaced me were almost all right out of coding camps with 1-3 years experience
- I was not ever told to write documentation, never given time to do it, and was working around 100 hour weeks, almost all spent coding, under tight deadlines.
- I'm a senior developer / Architect with 25+ years experience and a degree in Computer Engineering from a top school
- The 19 people who replaced me were almost all right out of coding camps with 1-3 years experience
I'm not saying the developer is crap, I'm saying it didn't take 19 developers to do what he/she did.
Each of those 19 developers could have been just as good, but the problem/requirement was likely very different for them.
Each of those 19 developers could have been just as good, but the problem/requirement was likely very different for them.
I have 25+ years experience and a computer engineering degree from a top university.
The 19 people were all right out of coding camps and each had 1-3 years experience.
The 19 people were all right out of coding camps and each had 1-3 years experience.
Are the requirements really 19 times harder though? Or at least N times larger, so that it requires 19 times more people? I most sincerely doubt it.
The reason there was 19 developers is probably because someone pulled the number 19 out of their ass.
The reason there was 19 developers is probably because someone pulled the number 19 out of their ass.
I've been there, a client-side app I built in 6 months got a rewrite which took 5 people 2 years and ended up with about half the original functionality.
The rewrite was warranted because so much stuff (API, UI) was changing entirely due to external forces. What it actually did (from the user's perspective) was pretty similar, how it did everything needed to be different. I didn't write it myself again because I was busy with other stuff.
There were numerous reasons it failed (we can say failed because the customer ended up going elsewhere). Devs were inexperienced, overconfident, chose inappropriate technology for the problem and wouldn't listen to advice. There was nobody in a tech lead position on the project (CTO at the time constantly spouted nonsense about "self organising teams") so everybody spent their time shaving their pet yaks and hoping other people would handle the difficult/boring bits. Deadlines were repeatedly issued but had no bearing on reality so everyone knew they'd be missed - thus they were meaningless.
The rewrite was warranted because so much stuff (API, UI) was changing entirely due to external forces. What it actually did (from the user's perspective) was pretty similar, how it did everything needed to be different. I didn't write it myself again because I was busy with other stuff.
There were numerous reasons it failed (we can say failed because the customer ended up going elsewhere). Devs were inexperienced, overconfident, chose inappropriate technology for the problem and wouldn't listen to advice. There was nobody in a tech lead position on the project (CTO at the time constantly spouted nonsense about "self organising teams") so everybody spent their time shaving their pet yaks and hoping other people would handle the difficult/boring bits. Deadlines were repeatedly issued but had no bearing on reality so everyone knew they'd be missed - thus they were meaningless.
Witnessed a bit of the inverse or similar, dunno. Something written over many years and working very well, was to be "rewritten" as a web site/app/mobile thing. And a "single" (wunder) dev pulled a miracle with a great POC demo where seemingly all needed functionality was almost there and working, all in a week which included many late nights according to them. This person had used the magical power of "angular" and all these "fancy" new things that wow-ed the leadership, that was so used to that "slow thick client" with it's outdated "C# compiled code".
Then after this transpired, it was up to the team to make all the APIs available to this new pretty-much-finished app and for it to be wired and polished into a "production ready" app. This process, along with all the unfinished, badly written, tech-debt ridden crap, took a year. Barely months in, simple features by this wunder-dev took weeks, incessant complaints about tech-debt by said dev, endless meetings and hand-wavy excuses about how "no we can't do it that way, it's not the angular way, and you don't know JS so shush!".
Countless angular upgrades and package updates with breaking changes, renderer this, web-component that, cordova that, do we support react, oh we didn't make it mobile friendly cause we can use native component libraries, oh crap we have multiple repos zomg now we need Lerna to compile our app, what about events let's use an event bus on the FE, and on and on, with no end in sight. It's years later and it's still being supported as if it's the holy grail, all while it continues dragging down actual feature dev. All this for a couple-dozen screens.
Then after this transpired, it was up to the team to make all the APIs available to this new pretty-much-finished app and for it to be wired and polished into a "production ready" app. This process, along with all the unfinished, badly written, tech-debt ridden crap, took a year. Barely months in, simple features by this wunder-dev took weeks, incessant complaints about tech-debt by said dev, endless meetings and hand-wavy excuses about how "no we can't do it that way, it's not the angular way, and you don't know JS so shush!".
Countless angular upgrades and package updates with breaking changes, renderer this, web-component that, cordova that, do we support react, oh we didn't make it mobile friendly cause we can use native component libraries, oh crap we have multiple repos zomg now we need Lerna to compile our app, what about events let's use an event bus on the FE, and on and on, with no end in sight. It's years later and it's still being supported as if it's the holy grail, all while it continues dragging down actual feature dev. All this for a couple-dozen screens.
Op was not saying it was good and documented code so a lot of context is missing here but even if it was a POC that needed a more generic/maintainable code rewrite, it would still justify keeping the original developer who wrote the code and giving them a market value compensation. Now again, we’re missing context here and it is not impossible that the code was a complicated mess that the original dev cobbled together culminating in a hot fire and they were too arrogant to be kept around. I’ve seen variations of that scenario. However, incompetency of the management is more likely to be the cause. Let’s keep in mind that in a lot of companies they management want to make sure all devs are replaceable so they don’t obtain too much leverage.
Exactly, that was my point. It's not that the engineer simply coded better than 19 other people together could, it's that other factors came into play. If the intent was to portray they are just a 19x developer... I know I'd have some questions...
To me it rings true. 1x is how much the company could get away with paying, so they did, because companies are reluctant to part with money. 19x is closer to how much value the system was providing, and thus how much resources were allocated to replacing it when that suddenly seemed necessary.
If the company had a more long term mindset, they would have been allocating something like 3x devs continuously the whole time, so that when the original dev quit, there was no crisis.
But… they didn’t. I’ve seen this kind of short term thinking up close plenty of times. Nothing to do with documentation quality.
If the company had a more long term mindset, they would have been allocating something like 3x devs continuously the whole time, so that when the original dev quit, there was no crisis.
But… they didn’t. I’ve seen this kind of short term thinking up close plenty of times. Nothing to do with documentation quality.
They never gave me time to write documentation. I was working 100 hour weeks, almost all coding, under tight deadlines.
You can see why I wanted a raise.
You can see why I wanted a raise.
Logically if the OP was never born, his software wouldn't exist, and a company wouldn't have made the judgement that replacing his software asap would be a good use of up to 19 man years of budget
(Of course it's also unknown whether that decision was a sensible one, whether it was forced by external pressure like API changes despite the stability and maintainability of the original system and whether the OP's software possessed equivalent functionality to its expensive replacement. All we know is the choice to create the software again from scratch was, to some extent, influenced by what had already been created)
(Of course it's also unknown whether that decision was a sensible one, whether it was forced by external pressure like API changes despite the stability and maintainability of the original system and whether the OP's software possessed equivalent functionality to its expensive replacement. All we know is the choice to create the software again from scratch was, to some extent, influenced by what had already been created)
[deleted]
Funny, i was once in a project where i was asked to build some software. They asked if I can do it in a year. When I asked for requirements they deflected to scrum.
Probably the shittiest job I've ever had. Asked to build a system in a year with no pre-defined scope or requirements (which I complained about in advance). Told them I can build something in a year.
Of course they weren't happy about something because they wanted more. Told them to go fuck themselves.
Frankly, I should have seen it coming before the project started. Fixed budget, no requirements or scope should have been a giant red flag in hindsight.
I wonder what happened to that.
Probably the shittiest job I've ever had. Asked to build a system in a year with no pre-defined scope or requirements (which I complained about in advance). Told them I can build something in a year.
Of course they weren't happy about something because they wanted more. Told them to go fuck themselves.
Frankly, I should have seen it coming before the project started. Fixed budget, no requirements or scope should have been a giant red flag in hindsight.
I wonder what happened to that.
> Fixed budget, no requirements or scope
Their requirements were pretty clear to me: they want to have a cake and eat it.
Their requirements were pretty clear to me: they want to have a cake and eat it.
What do you think is better for your manager’s own salary: managing a large team of 19 people or managing one person?
It sounds like they should have paid to keep you.
That said, I've written software that I would expect would require more engineers to keep around long term, in production. Better testing, security, reliability, scalability, maintainability. I can say this without disparaging my own work (well, I probably deserve at least a little criticism) or the people who took over the project.
Some software developers are really ingenious but a bit too undisciplined, great at understanding the business environment, and good enough at overall coding and architecture that what they build can be put into production without great risk or reliability, albeit with notable technical debt. In short, they actually build the tire rope swing,and without this kind of developer, the tire swing will never be built. It simply will not result from the 19 developer team you mentioned.
But it takes a very different kind of discipline to convert this into something that can work long term, and sometimes people are genuinely shocked to discover how much it will actually cost to make that rope swing safe and reliable in the long term.
By the way, I do want to make sure I emphasize that this isn't necessarily what happened in your case. Based on past experience, I have little trouble believing that you were simply replaced by a very expensive large team that didn't accomplish as much as you did along almost every axis, from maintainability to security to business relevance to innovation.
That said, I've written software that I would expect would require more engineers to keep around long term, in production. Better testing, security, reliability, scalability, maintainability. I can say this without disparaging my own work (well, I probably deserve at least a little criticism) or the people who took over the project.
Some software developers are really ingenious but a bit too undisciplined, great at understanding the business environment, and good enough at overall coding and architecture that what they build can be put into production without great risk or reliability, albeit with notable technical debt. In short, they actually build the tire rope swing,and without this kind of developer, the tire swing will never be built. It simply will not result from the 19 developer team you mentioned.
But it takes a very different kind of discipline to convert this into something that can work long term, and sometimes people are genuinely shocked to discover how much it will actually cost to make that rope swing safe and reliable in the long term.
By the way, I do want to make sure I emphasize that this isn't necessarily what happened in your case. Based on past experience, I have little trouble believing that you were simply replaced by a very expensive large team that didn't accomplish as much as you did along almost every axis, from maintainability to security to business relevance to innovation.
Not only did I ask for a raise, I also asked for a team. What they gave me were code camp graduates with 1-2 years experience.
We were building a bank based upon a highly complex microservice architecture running on Kubernetes and other complex software. The team they gave me was essentially useless.
I asked to hire more senior developers and they said it wasn't in the budget.
We were building a bank based upon a highly complex microservice architecture running on Kubernetes and other complex software. The team they gave me was essentially useless.
I asked to hire more senior developers and they said it wasn't in the budget.
Actually, without an objective metric, it's hard to explain why some programmer would be paid more than others...
So most of the time, it's more about some specifics of the job - with a specific job title (like "Lead Dev" instead of "Dev") - or the number of year of "experience" (actually : in the job). These are not really related to productivity but it's objective
So most of the time, it's more about some specifics of the job - with a specific job title (like "Lead Dev" instead of "Dev") - or the number of year of "experience" (actually : in the job). These are not really related to productivity but it's objective
I was Chief Software Architect.
That has happened to me as well. "You are the best engineer we have by far, but we can't pay you more, I'm sorry". I left shortly. At least they were honest.
That was pretty much exactly what happened, and I was working 100 hour weeks. I was promised 3 weeks off after we launched and they reneged. When that happened, I gave notice.
>they had to hire 19 engineers to rebuild the piece of software I built on my own
Be honest - did you write an overcomplicated piece of code that was super hard to understand? Because I know really good programmers that overcomplicate stuff and it takes a team to unwind their work. I respect these people, mind you.
Be honest - did you write an overcomplicated piece of code that was super hard to understand? Because I know really good programmers that overcomplicate stuff and it takes a team to unwind their work. I respect these people, mind you.
> Be honest - did you write an overcomplicated piece of code that was super hard to understand?
Not the person you asked but I have definitely done that. Usually writing overcomplicated code means you don't understand that particular domain/tech well enough and there may be no one else around to ask.
Half way in you realize you took the wrong approach. Now you have the difficult decision of sunk cost a fallacy here or not.
The correct answer may not be obvious, sunk cost isn't always a fallacy. I have definitely made wrong decisions here in the past and wrote bad code.
But sometimes the decision is ship something or nothing?
Not the person you asked but I have definitely done that. Usually writing overcomplicated code means you don't understand that particular domain/tech well enough and there may be no one else around to ask.
Half way in you realize you took the wrong approach. Now you have the difficult decision of sunk cost a fallacy here or not.
The correct answer may not be obvious, sunk cost isn't always a fallacy. I have definitely made wrong decisions here in the past and wrote bad code.
But sometimes the decision is ship something or nothing?
No, it was a bank that to senior developers would be super easy to understand. Their entire engineering team except for me was coding camp graduates (I was the only person with an actual software degree from a university) who had the capability of understanding the intricacies of, say, just the security implications of banking microservices.
We weren't building some little website. This was actual people's money on the line.
It's specifically why they hired me, since I have a history of writing secure fintech software.
But they royally fucked me over, abused me, and burnt me out. So I left.
We weren't building some little website. This was actual people's money on the line.
It's specifically why they hired me, since I have a history of writing secure fintech software.
But they royally fucked me over, abused me, and burnt me out. So I left.
Assuming they rebuilt an exact replica of your software, there is a misaligned incentive at play. The hiring manager don't pay the 19 new hire salary out of his own pocket, the hiring manager don't build the product directly. No one get fired by hiring bunch more people. On the other hand, arguing a, for example, 50% effort does have a negative impact to whoever making the arguing. Even more so if it means fighting HR bureaucracy. Imagine the salary is benchmarked against some sort of "industry average" and you have to convince people that you are maybe 100% better than average.
So assuming you are still playing the employment game, maybe next time you can make arguing for you easier.
So assuming you are still playing the employment game, maybe next time you can make arguing for you easier.
So the value of your work was -19 programmer years, the cost to clean up after you're gone.
Was the code that bad?
This is why we don't pay for productivity. It can't be measured, and the principal -agent problem looms large.
Was the code that bad?
This is why we don't pay for productivity. It can't be measured, and the principal -agent problem looms large.
This assumes that the 19 programmer decision was a good technical decision.
Most of these styles of rewrites I've seen over the years are grossly wasteful and mostly motivated by ego and politics.
Most of these styles of rewrites I've seen over the years are grossly wasteful and mostly motivated by ego and politics.
More than that, it assumes the 19 headcount decision was a good management decision. It obviously wasn't; regardless of how brilliant the OP is (I have my reservations, just from the fact that the company opted to -rewrite- it rather than extend/build around it), you don't hire 19 people in one year to replace a piece of software written by one person. That reeks of "we need this replaced ASAP; get two teams of contractors working on it", without realizing that past a certain point adding people creates negative value.
> That reeks of "we need this replaced ASAP; get two teams of contractors working on it"
When I once saw something like this it was "We just got a whack load of investor dollars for hiring" coupled with a belief that moving to a PaaS, requiring a rewrite to support that new infrastructure, that was purportedly easy for inexperienced developers would allow them to hire literal high school students (some quite amazing, to be fair) on the cheap and thinking that more developers would equal more output.
The original product was built on Postgres, and when I questioned the move away it was explained to me that hiring someone who understood how to work with such systems (the PaaS provides a document database that indeed does make it really easy to get data into it) would cost four times more than the juniors they were hiring. Four juniors over one senior was considered a good tradeoff for the business.
And it probably was for the first month or two. The early work was pushed out much faster than a lone dev would have ever been able to. But it wasn't long before the technical choices started to fall short, in particular the document database not being suitable for the workload, which ground velocity to a halt once the easy work was done. Eventually the project shrunk down to a couple of senior devs that were hired to untangle the mess.
When I once saw something like this it was "We just got a whack load of investor dollars for hiring" coupled with a belief that moving to a PaaS, requiring a rewrite to support that new infrastructure, that was purportedly easy for inexperienced developers would allow them to hire literal high school students (some quite amazing, to be fair) on the cheap and thinking that more developers would equal more output.
The original product was built on Postgres, and when I questioned the move away it was explained to me that hiring someone who understood how to work with such systems (the PaaS provides a document database that indeed does make it really easy to get data into it) would cost four times more than the juniors they were hiring. Four juniors over one senior was considered a good tradeoff for the business.
And it probably was for the first month or two. The early work was pushed out much faster than a lone dev would have ever been able to. But it wasn't long before the technical choices started to fall short, in particular the document database not being suitable for the workload, which ground velocity to a halt once the easy work was done. Eventually the project shrunk down to a couple of senior devs that were hired to untangle the mess.
I've seen code so bad that it was declared to be a total loss after the original programmer was discharged.
I've just as often see engineers claim code is a total loss and rewrite...without even trying to improve the existing code.
One time, the company split into two: One skeleton crew to maintain the "bad" code in production, and everyone else was allocated to the rewrite.
I was able to refactor and improve the "bad" code without much trouble. I'm pretty sure the reason it was deemed so bad was because certain engineers didn't actually try to work with it. They got offended by it quickly and gave up.
The rewrite failed btw - when I left, they were about to rewrite the rewrite (they had recently hired a new CTO).
The "bad" code brought in millions of dollars. It might still be doing so lol.
I was pretty junior in my career when this happened. It taught me that most senior engineers are posers. That generalization has only been reinforced as I've gotten more experience.
One time, the company split into two: One skeleton crew to maintain the "bad" code in production, and everyone else was allocated to the rewrite.
I was able to refactor and improve the "bad" code without much trouble. I'm pretty sure the reason it was deemed so bad was because certain engineers didn't actually try to work with it. They got offended by it quickly and gave up.
The rewrite failed btw - when I left, they were about to rewrite the rewrite (they had recently hired a new CTO).
The "bad" code brought in millions of dollars. It might still be doing so lol.
I was pretty junior in my career when this happened. It taught me that most senior engineers are posers. That generalization has only been reinforced as I've gotten more experience.
'One skeleton crew to maintain the "bad" code in production, and everyone else was allocated to the rewrite.'
My employer is doing this now. I'm on the maintenance side. I am not refactoring it quietly, yet. I am quietly supporting the rewrite team, although I won't get credit for it.
The 'bad' code makes us money today. The new code costs us money today. I doubt it will ever be better enough to pay for its own development. But that does not seem to matter. Mgmt wants to be like google. Mgmt wants a bigger org.
Not much I can do except to keep the money coming in today.
My employer is doing this now. I'm on the maintenance side. I am not refactoring it quietly, yet. I am quietly supporting the rewrite team, although I won't get credit for it.
The 'bad' code makes us money today. The new code costs us money today. I doubt it will ever be better enough to pay for its own development. But that does not seem to matter. Mgmt wants to be like google. Mgmt wants a bigger org.
Not much I can do except to keep the money coming in today.
Also been there.
Started on the rewrite, noticed it wasn't gonna go anywhere, asked to switch to maintaining the money maker.
Didn't need to refactor much: the code quality was VASTLY superior than the new system. However I not-so-silently worked on a redesign.
After four years not working there, the old system is still running full steam. The new one was shelved.
Started on the rewrite, noticed it wasn't gonna go anywhere, asked to switch to maintaining the money maker.
Didn't need to refactor much: the code quality was VASTLY superior than the new system. However I not-so-silently worked on a redesign.
After four years not working there, the old system is still running full steam. The new one was shelved.
One piece of advice: make damn sure you get credit for supporting the rewrite.
This is actually quite common in the hardware space. A hardware project can take a couple years, meanwhile the existing product has to be sustained. Also, a lot of stuff in a hardware product can become a total loss due to component obsolescence or the need to cram new / different features into a physical footprint. Even if it was a great design.
As others have pointed out, just like in software, we have to be cognizant of the career risk of hitching one's wagon to the product that's going out the door.
As others have pointed out, just like in software, we have to be cognizant of the career risk of hitching one's wagon to the product that's going out the door.
[deleted]
I did something similar a 4 or so years back. I wrote something in a month (+ a couple of working with stakeholders to make sure it did what it should). I did it in a legacy tech stack that the architects didn't like, on the side of the main activity, as the deadline was coming close and some hireing processes were slow.
A team of around devs 5 (some coming and going) having been trying to solve the same problem since, but they're still not being close to finished.
In other words, the productivity is in the order 50x to 100x slower than when I did it. Rather, the main reason was that I knew how to write code like that, while they were set up to fail.
Basically, some architect was making all sorts of unnecessary demands for how to wite the code, and the programers were not familiar with much of the tech stack that was introduced.
Also, coding standards were really verbose, easily 10x-30x what I wrote, in lines of code. The current state of what they have look suspiciously like FizzBuzzEnterpriseEdition:
https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...
TLDR; Incompetent tech leadership prone to cargo-culting, can slow down productivity to virtually zero. In some cases, productivity can go up by ~100x if ignoring their demands.
A team of around devs 5 (some coming and going) having been trying to solve the same problem since, but they're still not being close to finished.
In other words, the productivity is in the order 50x to 100x slower than when I did it. Rather, the main reason was that I knew how to write code like that, while they were set up to fail.
Basically, some architect was making all sorts of unnecessary demands for how to wite the code, and the programers were not familiar with much of the tech stack that was introduced.
Also, coding standards were really verbose, easily 10x-30x what I wrote, in lines of code. The current state of what they have look suspiciously like FizzBuzzEnterpriseEdition:
https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...
TLDR; Incompetent tech leadership prone to cargo-culting, can slow down productivity to virtually zero. In some cases, productivity can go up by ~100x if ignoring their demands.
Seems like a failure on behalf of management to get so dependent on a single resource vs distributing work more evenly. All eggs in one basket and all that.
The bandaid had to be ripped at some point. They should have added resource over time though to take pieces bit by bit.
The bandaid had to be ripped at some point. They should have added resource over time though to take pieces bit by bit.
If you are that productive and doesn't feel anyone is recognizing you. I highly recommend building your own company. All the sweat you put in will be paid back.
Knowing what is capable of making money is a very different skill from knowing how to build things. It’s very easy to pour countless hours into making the perfect product that no one wants.
Right, solving problems does not equate to making money. It takes a different skill to do that. However, there’s a solution: partner with other skilled people who know different aspects of running a business. Sure, it’s easier said than done and it does take some risk.
Why would you though? A life with a salary and being able to switch jobs to get a better offer/move on is comfortable.
I did. It's currently worth $6 billion.
But it was a horrible experience that nearly killed me. Not interested in doing that again.
But it was a horrible experience that nearly killed me. Not interested in doing that again.
Yup.. just management that doesn’t want pay for to talent.
It’s sad, bc people do understand the difference with other people.. sports, singing, poker, etc etc
It’s sad, bc people do understand the difference with other people.. sports, singing, poker, etc etc
This sounds like the result of a curious phenomena where good people are not rewarded with neither money nor time, because they "function", while problematic or loudmouth employees get all the time and money because they complain.
BTW: The linked article is from 2009.
My experience differs from the article. Where I have been and worked, if someone just copies together stuff they found on stackoverflow, that's not considered productive programming. That's usually a sign of incompetence. Also, pulling in huge frameworks to solve some simple acute problem is also not considered productive programming. It may solve the problem at hand (poorly, usually) but it will create huge future costs for maintaining the dependencies, applying patches, and following changes.
In my world, productive programming means solving an actual problem quickly and effectively, and in a way that minimized legacy costs in the following years. The code you leave behind is easy to follow, has few side effects or even none, is not just correct but obviously correct. And where it is not correct, it is easy to fix. You leave behind code that has documentation and good unit test coverage. Code that you needn't worry about. THAT is productive programming in my world.
That said, I have personally witnessed 10x productivity differences under these definitions, too. My observation is that poor programmers get stymied by frameworks and environments they hardly grasp, and are either deathly afraid to touch anything or they try something and it breaks in horrendous unanticipated ways so they get paralyzed.
A 10x programmer will not be paralyzed by fear but they will approach systematically. First you write unit tests for the existing code, so you understand the problem domain. Then you can start changing things and you'll know if you broke something because your unit tests will fail. Then you can start ripping out chunks of legacy code that is not actually needed anymore or was there to solve some hypothetical future problem that never materialized.
To me the most important skill set in programming is time management and following a systematic approach to problems, as opposed to viewing programming as an art form and then feeling the oppressive weight of existing obstacles limiting your free spirit.
The measure of good programming is not whether you solve that problem (that is a given) but by how much future headache your solution causes. Leave the world better than you found it.
My experience differs from the article. Where I have been and worked, if someone just copies together stuff they found on stackoverflow, that's not considered productive programming. That's usually a sign of incompetence. Also, pulling in huge frameworks to solve some simple acute problem is also not considered productive programming. It may solve the problem at hand (poorly, usually) but it will create huge future costs for maintaining the dependencies, applying patches, and following changes.
In my world, productive programming means solving an actual problem quickly and effectively, and in a way that minimized legacy costs in the following years. The code you leave behind is easy to follow, has few side effects or even none, is not just correct but obviously correct. And where it is not correct, it is easy to fix. You leave behind code that has documentation and good unit test coverage. Code that you needn't worry about. THAT is productive programming in my world.
That said, I have personally witnessed 10x productivity differences under these definitions, too. My observation is that poor programmers get stymied by frameworks and environments they hardly grasp, and are either deathly afraid to touch anything or they try something and it breaks in horrendous unanticipated ways so they get paralyzed.
A 10x programmer will not be paralyzed by fear but they will approach systematically. First you write unit tests for the existing code, so you understand the problem domain. Then you can start changing things and you'll know if you broke something because your unit tests will fail. Then you can start ripping out chunks of legacy code that is not actually needed anymore or was there to solve some hypothetical future problem that never materialized.
To me the most important skill set in programming is time management and following a systematic approach to problems, as opposed to viewing programming as an art form and then feeling the oppressive weight of existing obstacles limiting your free spirit.
The measure of good programming is not whether you solve that problem (that is a given) but by how much future headache your solution causes. Leave the world better than you found it.
What you are describing sounds like a good senior engineer. There can ofcourse be exceptions, especially if we talk about necessary complexity that has been turned into a swamp, but usually what you are describing is closer to x2 engineering. x10 is when you stop solving problems and make them vanish instead.
An example: Business/product/whatever wants fuzzy search on a listing.
x2 says "I know how to do that. We just use Debezium and kafka to get the data into Elastic Search and then query it from there". Business/product/whatever says "cool, code it up". The infrastructure is a little difficult, but two months later a well tested good solution is in production, everyone is happy. Good job?
x10 says "how good does the fuzzy search need to be? Elastic Search is king, but Postgres can do it too". Business/product/whatever says "I don't know". x10 engineer codes a demo in 2 hours, shows it to business/product/whatever. Business/product/whatever says "that will do, lets ship it". The day after its shipped to production, noone ever talks about fuzzy search anymore.
Noone is every consistently x2 or x10 or xWhatever. Sometimes x2 is the best you can do, but other times you can do much much better. The trick is usually to be on the lookout for it.
An example: Business/product/whatever wants fuzzy search on a listing.
x2 says "I know how to do that. We just use Debezium and kafka to get the data into Elastic Search and then query it from there". Business/product/whatever says "cool, code it up". The infrastructure is a little difficult, but two months later a well tested good solution is in production, everyone is happy. Good job?
x10 says "how good does the fuzzy search need to be? Elastic Search is king, but Postgres can do it too". Business/product/whatever says "I don't know". x10 engineer codes a demo in 2 hours, shows it to business/product/whatever. Business/product/whatever says "that will do, lets ship it". The day after its shipped to production, noone ever talks about fuzzy search anymore.
Noone is every consistently x2 or x10 or xWhatever. Sometimes x2 is the best you can do, but other times you can do much much better. The trick is usually to be on the lookout for it.
I love this example as it hits close to home. I once, several years ago, worked on a team where nobody else knew there was full-text search inside Postgres.
Took a few hours to convince, demonstrate and teach, but we got there. Took half that time to implement.
Six months on, there were about 10 full-text queries per hour. Posgres is probably overkill for what we're doing, but since the data is there. Imagine if we had gone the ElasticSearch route.
I still have fantasies of punching the guy who said "But if PostgreSQL has fulltext search, why would they had invented ElasticSearch"?
Took a few hours to convince, demonstrate and teach, but we got there. Took half that time to implement.
Six months on, there were about 10 full-text queries per hour. Posgres is probably overkill for what we're doing, but since the data is there. Imagine if we had gone the ElasticSearch route.
I still have fantasies of punching the guy who said "But if PostgreSQL has fulltext search, why would they had invented ElasticSearch"?
I like your unit test example.
I find that when approaching something new, like a codebase, API or framework, the most important thing to do after getting a cursory lay of the land, is establishing a tight feedback loop for determining if something is functioning/breaking/improving.
In the case of refactoring, that's often adding test coverage as in your example. When experimenting with a new technology it's usually building a 'tracer bullet', the smallest e2e working piece of functionality to ensure that your mental model matches with the reality of how it actually works.
The tools and processes of a technical org can have a big impact on how easy it is to take this approach. Enabling the engineers in your organization to create tight feedback loops and easily experiment is a huge boost to productivity. Test execution speed, ease of deploying dev instances of services or whole clusters of services, logs that are easy to access and query, distributed traces. At larger companies it can be a huge pain to simply spin up or get access to an instance of a service that you can poke, change, break and throwaway much less a cluster of interacting microservices.
I find that when approaching something new, like a codebase, API or framework, the most important thing to do after getting a cursory lay of the land, is establishing a tight feedback loop for determining if something is functioning/breaking/improving.
In the case of refactoring, that's often adding test coverage as in your example. When experimenting with a new technology it's usually building a 'tracer bullet', the smallest e2e working piece of functionality to ensure that your mental model matches with the reality of how it actually works.
The tools and processes of a technical org can have a big impact on how easy it is to take this approach. Enabling the engineers in your organization to create tight feedback loops and easily experiment is a huge boost to productivity. Test execution speed, ease of deploying dev instances of services or whole clusters of services, logs that are easy to access and query, distributed traces. At larger companies it can be a huge pain to simply spin up or get access to an instance of a service that you can poke, change, break and throwaway much less a cluster of interacting microservices.
> The measure of good programming _ought to be, but isn't and never will be in the eyes of the people who are actually going to make it into a position of authority_ is not whether you solve that problem (that is a given) but by how much future headache your solution causes
As Dilbert points out "our boss can't judge the quality of our work, but he knows when it's late". The only measure of good programming that will translate into actual tenure in an organization is: how fast did you get it done? It's been this way for 50 years. It won't end tomorrow just because you're right about the way things ought to be.
As Dilbert points out "our boss can't judge the quality of our work, but he knows when it's late". The only measure of good programming that will translate into actual tenure in an organization is: how fast did you get it done? It's been this way for 50 years. It won't end tomorrow just because you're right about the way things ought to be.
[deleted]
>"To me the most important skill set in programming is time management and following a systematic approach to problems, as opposed to viewing programming as an art form and then feeling the oppressive weight of existing obstacles limiting your free spirit."
THIS. Well said.
THIS. Well said.
> First you write unit tests for the existing code, so you understand the problem domain. Then you can start changing things and you'll know if you broke something because your unit tests will fail.
In many projects this is a fantasy. I've yet to work on a C++ project where one could add (useful) unit tests to existing code without rearchitecting. If you don't design your code to use unit tests to begin with it won't be easy to add them later.
Python, sure. C++: no way
In many projects this is a fantasy. I've yet to work on a C++ project where one could add (useful) unit tests to existing code without rearchitecting. If you don't design your code to use unit tests to begin with it won't be easy to add them later.
Python, sure. C++: no way
I feel that programming ability rises by roughly an order of magnitude every decade, as one learns more approaches to problem solving.
I've been programming over 30 years, so my daily productivity may be something like 1/1000 of what I'd be capable of if I had something like JARVIS in the Iron Man movies.
That's a total humblebrag and I'm no Tony Stark, I'm not saying that. Just that I'm concerned that if we view programmer aptitude through the lens of productivity instead of the complexity of problem that can be solved, then programmers will eventually find themselves underemployed.
For my mental health, I had to let my ego die and begin to look beyond my personal contribution (which will always pale in comparison to my dreams). I view programmers now as enabling larger groups of people to work and support their families. In a very real sense, we sacrifice our human potential on minutia so that others don't have to. Like how doctors move to small towns to help people instead of landing large salaries at major hospitals. I'm sad that people who win the internet lottery are often spared ego death, so hoard their wealth and never wake up to a greater understanding of how they could pay it forward outside of models built on the profit motive.
I've been programming over 30 years, so my daily productivity may be something like 1/1000 of what I'd be capable of if I had something like JARVIS in the Iron Man movies.
That's a total humblebrag and I'm no Tony Stark, I'm not saying that. Just that I'm concerned that if we view programmer aptitude through the lens of productivity instead of the complexity of problem that can be solved, then programmers will eventually find themselves underemployed.
For my mental health, I had to let my ego die and begin to look beyond my personal contribution (which will always pale in comparison to my dreams). I view programmers now as enabling larger groups of people to work and support their families. In a very real sense, we sacrifice our human potential on minutia so that others don't have to. Like how doctors move to small towns to help people instead of landing large salaries at major hospitals. I'm sad that people who win the internet lottery are often spared ego death, so hoard their wealth and never wake up to a greater understanding of how they could pay it forward outside of models built on the profit motive.
Developer productivity specifically and knowledge work in general is extremely hard to measure.
Not only that, it is also very subjective. What is valuable to one person might be a liability to another.
Just the other day I looked at results from a developer who spun a huge mess of AWS infrastructure, microservices, lambdas and so on all to solve a very simple problem. He probably congratulated himself for a job well done.
So the success of this person would largely depend on the manager he has. For example, how much the manager values simplicity.
Not only that, it is also very subjective. What is valuable to one person might be a liability to another.
Just the other day I looked at results from a developer who spun a huge mess of AWS infrastructure, microservices, lambdas and so on all to solve a very simple problem. He probably congratulated himself for a job well done.
So the success of this person would largely depend on the manager he has. For example, how much the manager values simplicity.
There are certainly managers and directors that would be mesmerized by the architecture diagram in your example, and immediately put that dev up for promo.
Of course, and that is the point. How can we pay in proportion to the value a developer is creating if we can't even agree on what is valuable?
https://en.wikipedia.org/wiki/Pareto_principle
If programmers were paid in proportion to their productivity most (maybe 80%) would starve to death. They would be better off providing data entry for minimum wage. On the other hand, those that are productive (aren't afraid to write original software) would be lavishly rewarded beyond most of our imaginations. Their output doesn't even have to be high quality.
This would resoundingly benefit everybody. People doing a job just to put an unqualified body in a seat are an economic drag. Their contributions are often a net negative purely existing to qualify their own existence. For example, does the user actually want 10mb of JS executing for 10 seconds on every page load just to put a few lines of text on the screen? Does the user care that it took a large team of software engineers to pull that off and waste their time without which those software engineers would have to do something else? No, the user won't shed a tear.
Yes, there are 10x developers. Yes, most software developers have no idea what a 10x developer is and are absolutely incapable of recognizing one even when working adjacent to one.
The only valid question is why the industry tolerates, and even infantilizes, hiring people not qualified to do this work at their own expense. The simple answer, also economically valid, is because it takes them less effort to make a knowingly bad decision than confront the risk of defining what comprises valid selection criteria.
If programmers were paid in proportion to their productivity most (maybe 80%) would starve to death. They would be better off providing data entry for minimum wage. On the other hand, those that are productive (aren't afraid to write original software) would be lavishly rewarded beyond most of our imaginations. Their output doesn't even have to be high quality.
This would resoundingly benefit everybody. People doing a job just to put an unqualified body in a seat are an economic drag. Their contributions are often a net negative purely existing to qualify their own existence. For example, does the user actually want 10mb of JS executing for 10 seconds on every page load just to put a few lines of text on the screen? Does the user care that it took a large team of software engineers to pull that off and waste their time without which those software engineers would have to do something else? No, the user won't shed a tear.
Yes, there are 10x developers. Yes, most software developers have no idea what a 10x developer is and are absolutely incapable of recognizing one even when working adjacent to one.
The only valid question is why the industry tolerates, and even infantilizes, hiring people not qualified to do this work at their own expense. The simple answer, also economically valid, is because it takes them less effort to make a knowingly bad decision than confront the risk of defining what comprises valid selection criteria.
If I understand you correctly (and please, if I don't, do tell) you are advancing that most employees would agree that 80% of their hires are individually a net negative to the company, and they (the employees) know that, and they are okay with that and don't change anything, because facing this predicament (I assume we are in agreement this sounds like a pretty big predicament?) seems daunting.
If that is in fact what you think is going on, I think you are most likely insane and I am very interested to hear more.
If that is in fact what you think is going on, I think you are most likely insane and I am very interested to hear more.
Not only that, he seems to be OK with these 80% making <= minimum wage. Fun!
The 10mb of JS is an interesting but misplaced example. There are situations where it's worth the effort to write something with a smaller footprint from scratch but it always comes down to individual incentives. Will it ship faster if we just import this overpowered library? Will additional bloat to our webapp effect the bottom line in any discernible way? The answer to those questions is so frequently yes and no respectively that the emergent result is what you see in your browser's network tab.
The user won't shed a tear if it's removed, but they won't leave and spend their money elsewhere in all but the most pathological cases. I think the state of webdev is the result of a common and general problem, micro optimal decisions result in frustrating macro structural issues.
But then again if you've found cases where you can build a business off of serving users 10 fewer mb of JS than a competitor, more power to you. Be the change.
The user won't shed a tear if it's removed, but they won't leave and spend their money elsewhere in all but the most pathological cases. I think the state of webdev is the result of a common and general problem, micro optimal decisions result in frustrating macro structural issues.
But then again if you've found cases where you can build a business off of serving users 10 fewer mb of JS than a competitor, more power to you. Be the change.
> But then again if you've found cases where you can build a business off of serving users 10 fewer mb of JS than a competitor, more power to you. Be the change.
That depends upon the product. If the primary revenue engine is advertising the product is the end user, not the software. As such, track the shit out of them.
If the revenue engine is something else or the goal is merely disruption then, more than likely, the product is the application. The primary driver empowering retention is don't give your users a compelling reason to consider the competition.
That depends upon the product. If the primary revenue engine is advertising the product is the end user, not the software. As such, track the shit out of them.
If the revenue engine is something else or the goal is merely disruption then, more than likely, the product is the application. The primary driver empowering retention is don't give your users a compelling reason to consider the competition.
Programming work is also maintenance. You need people around to put out fires or keep things up to date. If you’re only paying based on performance, the high performers will do a big project and immediately leave to somewhere else. The lower performers (at least impact-wise) won’t be there to fix a mess or make incremental upgrades. This approach already happens.
This is actually why a lot of software at larger companies aren’t user friendly. There are obvious small bugs or quality of life improvements that could be made for the customer, but it’s hard to tie to measured revenue impact so the SWE team does nothing to fix it.
This is actually why a lot of software at larger companies aren’t user friendly. There are obvious small bugs or quality of life improvements that could be made for the customer, but it’s hard to tie to measured revenue impact so the SWE team does nothing to fix it.
what does citing the pareto principle here even mean? say 80% of programmers are "unproductive" isn't even what the principle even states. a generous interpretation in line with the line of though you've presented would be that 80% of programmers contribute 20% of overall productivity. this perhaps isn't wrong, but defining "unproductivity" from the assumed contribution proportions of an entire industry would require even more heinous assumptions that a any single developer isn't able to do
perhaps you're more productive than your fellow co-workers, congratulations, but extrapolating your programming skills into economic commentary or hiring is a bit egregious
perhaps you're more productive than your fellow co-workers, congratulations, but extrapolating your programming skills into economic commentary or hiring is a bit egregious
The same is true of businesses. There are plenty that make money while being unproductive and selling subpar software.
How do you measure the productivity of someone that can wade into a horribly buggy 10 year old piece of code that has terrible edge conditions and is integrated with other 10 year old pieces of code that you can't break, and you need to work out how to fix it and test it?
I often feel like I'm pretty slow in terms of my output, but I generally wade into really tough problems after other devs/teams have flailed at them for weeks and I manage to solve the problem. Does that make me a "10x programmer"? I don't tend to greenfield anywhere near as fast as that so I can't claim to have written some 40,000 line program from scratch in a month. I can write some 100 line patch in 2 weeks that nobody else could come up with though and keep some 10 year old 40,000 line production critical codebase still running.
I often feel like I'm pretty slow in terms of my output, but I generally wade into really tough problems after other devs/teams have flailed at them for weeks and I manage to solve the problem. Does that make me a "10x programmer"? I don't tend to greenfield anywhere near as fast as that so I can't claim to have written some 40,000 line program from scratch in a month. I can write some 100 line patch in 2 weeks that nobody else could come up with though and keep some 10 year old 40,000 line production critical codebase still running.
Productivity is hard to define in cases like you've mentioned. If a normal developer is 1x but can't solve a particularly difficult problem, and a million others just like that one can't solve it either, how do we measure the productivity of the better developer who can solve the problem? Are they infinitely more productive?
true.. adequate programmers code exactly what you tell them to..and even then it may not be great. Great engineers step back and ask 'why are you asking me to do this?'..(probably silently).. which inevitably leads to a more refined solution, or none at all when they realize you don't actually understand the actual problem, more likely just a symptom of it. Nobody remembers what didn't happen and they certainly don't pay you more for that.
This is usually a function of experience, but not necessarily. Productive developers are constantly mapping each development requirement into a larger context of the 'system processes' at large, cross-referencing their (usually deeper) understanding of the technical, business, and political issues involved (all involving some acquisition or expenditure of 'energy' in the general sense). Their productivity is more a function of their understanding of economics writ large, than their recall of algorithms or specific toolsets. It's the main reason senior development is so difficult to hire for..
This is usually a function of experience, but not necessarily. Productive developers are constantly mapping each development requirement into a larger context of the 'system processes' at large, cross-referencing their (usually deeper) understanding of the technical, business, and political issues involved (all involving some acquisition or expenditure of 'energy' in the general sense). Their productivity is more a function of their understanding of economics writ large, than their recall of algorithms or specific toolsets. It's the main reason senior development is so difficult to hire for..
My favourite programmer productivity anecdote:
https://www.folklore.org/StoryView.py?story=Negative_2000_Li...
https://www.folklore.org/StoryView.py?story=Negative_2000_Li...
> Their productivity is more a function of their understanding of economics writ large, than their recall of algorithms or specific toolsets
I agree with your post except for that bit. IME it is very much down to a more creative and questioning approach to coding that separates the better from the less good.
I don't think, again IME, that asking the question "but should we?" has ever got me that far (though it is a good question) because bad managers take no notice and good managers have already asked it.
I agree with your post except for that bit. IME it is very much down to a more creative and questioning approach to coding that separates the better from the less good.
I don't think, again IME, that asking the question "but should we?" has ever got me that far (though it is a good question) because bad managers take no notice and good managers have already asked it.
I think what I was trying to say is that the best performers attempt to understand the problem domain more holistically than, say, more average performers. What are the forces driving all of this and how do I deal with those forces in the most efficient way. Obviously, a dramatically more productive engineer also has deep experience is probably many toolsets, languages, etc., and that experience informs many of the decisions that they make when crafting a solution. However, I would argue that they have forgotten many of the picayune details of each, and only retain the most useful conceptual capabilities of those experiences so they can apply them quickly to some new and (seemingly) unrelated problem.
The most productive programmers are the ones that make other programmers more productive. Making a tool or library or other piece of reusable infrastructure that increases the productivity of 100 engineers by 10% is 10x productivity.
I view helping others as a force multiplier. I prioritize that over my own stuff and have actually been rewarded for it sometimes.
Manager spotted
Are there a lot of managers prioritizing internal dev tools and infra over flashy product release announcement bullet point features?
Of course not. They're all skunkworks projects. Just like refactoring has to be.
I've developed internal tools that help me a lot and help others too. None of the managers of any of my jobs has ever asked "When did you find time to build that?"
I'm sure it's partly because management doesn't have a good idea of how long things take to build. The internal tool could have taken you a week but management probably thinks it took a couple hours.
I've developed internal tools that help me a lot and help others too. None of the managers of any of my jobs has ever asked "When did you find time to build that?"
I'm sure it's partly because management doesn't have a good idea of how long things take to build. The internal tool could have taken you a week but management probably thinks it took a couple hours.
Then the parent comment makes no sense since the grandparent comment is espousing a view that managers would allegedly not.
> Programmers are most effective when they avoid writing code. They may realize the problem they’re being asked to solve doesn’t need to be solved, that the client doesn’t actually want what they’re asking for.
And how do you balance your urge to say "this feature is not what brings us the most value" in a team setting where the business/ product decisions should be evaluated by the product owners?
I've only worked with one product owner who actually appreciated the engineers challenging product decisions and was capable of actually changing priorities based on our feedback. He didn't always change his mind, but I know that he was always listening and never made me feel like insubordinate little child.
Most business and product people may let you share your thoughts, they smile and nod, and ignore everything you said. Do it a couple of times, you will be labelled as "not a team player". Do you want to know how our similar features performed in the past? You want to challenge whether some SAFe ceremony actually works for your "autonomous" team? You want to recommend hiring an analyst because the whole product flies blind without proper data? Want to take a step back and think about whether a project that takes many man-years to complete is bringing the business or the users any value? Too bad, shut up and code.
I had to work too many times on a "super urgent, hundred million dollar feature" and "non-negotiable legal requirements" that still hide behind a feature toggle.
In practice, you can figure out in a couple of months whether the person in charge of product vision is capable of listening or not. If they are not, you'll either learn how to keep your skepticism to yourself and do as you are told, or you start looking for a new position (or going solo).
And how do you balance your urge to say "this feature is not what brings us the most value" in a team setting where the business/ product decisions should be evaluated by the product owners?
I've only worked with one product owner who actually appreciated the engineers challenging product decisions and was capable of actually changing priorities based on our feedback. He didn't always change his mind, but I know that he was always listening and never made me feel like insubordinate little child.
Most business and product people may let you share your thoughts, they smile and nod, and ignore everything you said. Do it a couple of times, you will be labelled as "not a team player". Do you want to know how our similar features performed in the past? You want to challenge whether some SAFe ceremony actually works for your "autonomous" team? You want to recommend hiring an analyst because the whole product flies blind without proper data? Want to take a step back and think about whether a project that takes many man-years to complete is bringing the business or the users any value? Too bad, shut up and code.
I had to work too many times on a "super urgent, hundred million dollar feature" and "non-negotiable legal requirements" that still hide behind a feature toggle.
In practice, you can figure out in a couple of months whether the person in charge of product vision is capable of listening or not. If they are not, you'll either learn how to keep your skepticism to yourself and do as you are told, or you start looking for a new position (or going solo).
Because programmer usually is not businessman.
That is, first you bet, then you could win, or lose.
This is totally different lifestyle and different style of thinking.
And that's not all. In reality typical win means, you just got much more than typical bank deposit give. For example bank give 10%, but you got 20%.
And this also consider much different knowledge set and skillset, than typical programmer think.
For real business much more important than abstract loc, how good you know business (and/or lifestyle) of your client, and how good your code fill his needs.
Separate important problem, what people say they need, does not really equals to what they really need.
And one also very important part of this puzzle, sometimes you must become salesman and convince your client to buy your solution, which client don't understand, but you sure, it is what he need, and may be more important to you, to what you invested your time and money.
And for salesman it is very typical, to have ZERO permanent part of compensation, live only from percents of sales. And to be honest, sales are not 100% depend on salesman skills, but have few peaks on few famous parts of year, and also have huge known decline periods.
So, if programmer want to be paid in proportion to his VALUE, he will deal with all things I mentioned. And yes, in many cases, this means, to become much more salesman and much less programmer.
To be honest, in usual developed country it's worth it. In developing country, successful programmers paid comparable to big bosses and to media stars.
That is, first you bet, then you could win, or lose.
This is totally different lifestyle and different style of thinking.
And that's not all. In reality typical win means, you just got much more than typical bank deposit give. For example bank give 10%, but you got 20%.
And this also consider much different knowledge set and skillset, than typical programmer think.
For real business much more important than abstract loc, how good you know business (and/or lifestyle) of your client, and how good your code fill his needs.
Separate important problem, what people say they need, does not really equals to what they really need.
And one also very important part of this puzzle, sometimes you must become salesman and convince your client to buy your solution, which client don't understand, but you sure, it is what he need, and may be more important to you, to what you invested your time and money.
And for salesman it is very typical, to have ZERO permanent part of compensation, live only from percents of sales. And to be honest, sales are not 100% depend on salesman skills, but have few peaks on few famous parts of year, and also have huge known decline periods.
So, if programmer want to be paid in proportion to his VALUE, he will deal with all things I mentioned. And yes, in many cases, this means, to become much more salesman and much less programmer.
To be honest, in usual developed country it's worth it. In developing country, successful programmers paid comparable to big bosses and to media stars.
> Programmers are most effective when they avoid writing code. They may realize the problem they’re being asked to solve doesn’t need to be solved, that the client doesn’t actually want what they’re asking for. They may know where to find reusable or re-editable code that solves their problem.
This snippet is at the heart of it for me. The best analogy I give is a drawing of Pablo Picasso's horse. After many years of understanding your craft, a developer knows how to provide the most value with the least complexity required. It's not because the developer doesn't want to write code. It's more that they understand how to maximize the tools available for the system they work in. Reduction of complexity is better than the addition of it over the long term.
This snippet is at the heart of it for me. The best analogy I give is a drawing of Pablo Picasso's horse. After many years of understanding your craft, a developer knows how to provide the most value with the least complexity required. It's not because the developer doesn't want to write code. It's more that they understand how to maximize the tools available for the system they work in. Reduction of complexity is better than the addition of it over the long term.
I'm so glad to see this article on the HN front page. It's spot on and it's what makes coding such a difficult career and why it feels so non-meritocratic. It's happened to me a couple of times that I had to work under the leadership of someone who was far less skilled than me. It's a painful experience and it can take over a year for non-technical directors to figure it out; also, by the time they start to suspect something is wrong, they may have become friends and don't want to admit to themselves that their chief engineer is simply not good.
It's easy to say "Well, just quit and join a different company" but this trivializes how incredibly widespread this problem is across all companies including very financially successful ones. They have a huge amount of money; they can throw thousands of engineers at any problem; they don't need to be efficient to stay afloat and they usually aren't... And usually companies which are already earning a lot of money don't care about anything other than merely staying afloat - Everyone is just coasting along thanks to their market monopolies.
In my last role, I was presented with what could have been a once-in-a-lifetime opportunity. It could have worked out really well but it worked out terribly because the top engineer was not qualified for the job and neither were the founders. It's not like I can just turn around an find another opportunity like that the next day; it took 10 years and a lot of things had to line up exactly right to get that opportunity. This was the best financial opportunity I had come across in over a decade. I still think it could have worked out very differently.
Talent and skills don't attract such financial opportunities in this industry; it's all about luck. It's not even about social connections because people in this industry have an obsession with 'warm introduction' and this creates a huge amount of friction - It's literally impossible to socially network your way to a good opportunity; if you don't try hard enough, you won't get any opportunities. If you try too hard, investors or founders will feel threatened by you - It will make them uncomfortable. This industry is full of sheep; they're terrified to do anything differently than their peers, it doesn't matter how rich they are. They have FU money but they're terrified to say FU. It makes 0 sense to me.
For the average person who is or aspires to be above average, the tech industry is a kafkaesque nightmare. You have to be content with being average and rolling the dice. This means you have to content yourself with mediocrity and work on your people skills instead.
It's easy to say "Well, just quit and join a different company" but this trivializes how incredibly widespread this problem is across all companies including very financially successful ones. They have a huge amount of money; they can throw thousands of engineers at any problem; they don't need to be efficient to stay afloat and they usually aren't... And usually companies which are already earning a lot of money don't care about anything other than merely staying afloat - Everyone is just coasting along thanks to their market monopolies.
In my last role, I was presented with what could have been a once-in-a-lifetime opportunity. It could have worked out really well but it worked out terribly because the top engineer was not qualified for the job and neither were the founders. It's not like I can just turn around an find another opportunity like that the next day; it took 10 years and a lot of things had to line up exactly right to get that opportunity. This was the best financial opportunity I had come across in over a decade. I still think it could have worked out very differently.
Talent and skills don't attract such financial opportunities in this industry; it's all about luck. It's not even about social connections because people in this industry have an obsession with 'warm introduction' and this creates a huge amount of friction - It's literally impossible to socially network your way to a good opportunity; if you don't try hard enough, you won't get any opportunities. If you try too hard, investors or founders will feel threatened by you - It will make them uncomfortable. This industry is full of sheep; they're terrified to do anything differently than their peers, it doesn't matter how rich they are. They have FU money but they're terrified to say FU. It makes 0 sense to me.
For the average person who is or aspires to be above average, the tech industry is a kafkaesque nightmare. You have to be content with being average and rolling the dice. This means you have to content yourself with mediocrity and work on your people skills instead.
The nature of labour and productivity has been understood by classical economists for hundreds of years now. You are not paid in proportion to the excess value you produce, or else you would be an owner of the company.
Many programmers are owners in their companies. Unfortunately for them, this is not always a good thing
Then what are you paid in proportion to?
There are entire schools of economic thought about that question. In the classical view, it's your labour power. In the neoclassical view, it's the scarcity of the labour you produce.
I am asking because in a simple model of perfect competition, you are paid your marginal product of labor, i.e., your productivity. Spence's signalling model of education is also based on the idea that people are compensated for their productivity. Even in efficiency-wage models, the equilibrium wage is set at the marginal product of labor.
I have given the problem of how to correctly compensate according to productivity some thought, and one idea I keep revisiting are auctions.
Assuming that you have a fairly good idea of what needs to be done and how to divide it up into reasonable chunks, I could imagine an auction where you just create a list of things and programmers in your company freely bid on them with how much money they’ll be paid for completing each task.
The system doesn’t have to be complete. Imagine auctioning off the top x% most urgent bugs to be fixed every sprint, reviewing PRs, etc as extra work.
There are some very big flaws with this approach, namely that requirement specifications are basically impossible to get right and review and that incentive structures are not well aligned:
- If I bid $5000 to fix a bug, but introduce $10,000 of technical debt into the codebase, then I just made money by externalising the cost.
- It makes you compete with your colleagues for buds and that creates a really hostile work environment that probably drastically decreases workout pace efficiency
So it’s just been an idea that’s been floating around my head, but maybe an econ grad student can work something out from this.
Assuming that you have a fairly good idea of what needs to be done and how to divide it up into reasonable chunks, I could imagine an auction where you just create a list of things and programmers in your company freely bid on them with how much money they’ll be paid for completing each task.
The system doesn’t have to be complete. Imagine auctioning off the top x% most urgent bugs to be fixed every sprint, reviewing PRs, etc as extra work.
There are some very big flaws with this approach, namely that requirement specifications are basically impossible to get right and review and that incentive structures are not well aligned:
- If I bid $5000 to fix a bug, but introduce $10,000 of technical debt into the codebase, then I just made money by externalising the cost.
- It makes you compete with your colleagues for buds and that creates a really hostile work environment that probably drastically decreases workout pace efficiency
So it’s just been an idea that’s been floating around my head, but maybe an econ grad student can work something out from this.
Nice try.
From history of aviation known, in USSR in 1920s tried to increase productivity of all production in similar way.
They accepted ANY suggestion and pay for them average few pennies (for more economy effect paid more money). And said, documents shown thousands suggestions and payments, some people made hundreds suggestions per month, and this was significant increase to their salary.
But this lasts only few months, because people for these pennies suggest mostly useless things and in some cases even harmful.
For example, in planes construction used oval aluminum tubes, to save weight and to make slightly less air drag. One suggests to use cheap steel round tubes. Aluminum was expensive, so this was extremely economy effective, but plane load decrease about 20% and speed decreased also about 20%, and this was not acceptable.
From history of aviation known, in USSR in 1920s tried to increase productivity of all production in similar way.
They accepted ANY suggestion and pay for them average few pennies (for more economy effect paid more money). And said, documents shown thousands suggestions and payments, some people made hundreds suggestions per month, and this was significant increase to their salary.
But this lasts only few months, because people for these pennies suggest mostly useless things and in some cases even harmful.
For example, in planes construction used oval aluminum tubes, to save weight and to make slightly less air drag. One suggests to use cheap steel round tubes. Aluminum was expensive, so this was extremely economy effective, but plane load decrease about 20% and speed decreased also about 20%, and this was not acceptable.
It’s because productivity is a function of the environment wherein one is practicing.
E.g. if someone really believes they can make 10x more they should quit and start their own company to do that.
I’m in an organization where I am considered super productive, but I know that is a quirk of how I interface efficiently with this particular organizational structure. If I was off on my own, I wouldn’t be nearly as productive.
E.g. if someone really believes they can make 10x more they should quit and start their own company to do that.
I’m in an organization where I am considered super productive, but I know that is a quirk of how I interface efficiently with this particular organizational structure. If I was off on my own, I wouldn’t be nearly as productive.
Knowing how to write software is not the same thing as knowing how to market and monetize it.
I think the other thing that goes on these days is that, for better or for worse, DEI initiatives have flattened pay bands for everyone. I'm not making any comment about whether certain subgroups are over or under paid, but it should be quite obvious that the incentives mean that hiring managers are now terrified of overpaying certain groups and equally terrified of underpaying others.
When, as this article points out, outcomes are extremely difficult to measure for any individual programmer, this results in less variation of pay yet still with wide variation in real underlying productivity.
When, as this article points out, outcomes are extremely difficult to measure for any individual programmer, this results in less variation of pay yet still with wide variation in real underlying productivity.
I've been thinking about this myself. I'm highly productive and always avoid unnecessary complexity. My most common question is: Can we not do it?
However, when I worked for a company I did get bigger promotions but that it was in the 10-20% range. I was literally 2-3 times more productive than people who got paid 30-40% less.
If you take a big picture look, you will see things get more obvious when you give it enough time. In 10 years the difference will be big enough (I think).
However, when I worked for a company I did get bigger promotions but that it was in the 10-20% range. I was literally 2-3 times more productive than people who got paid 30-40% less.
If you take a big picture look, you will see things get more obvious when you give it enough time. In 10 years the difference will be big enough (I think).
If they want and good at working on things I hate (tedious, repetitive work, testing) I don't mind it. . Without them my performance will go down too.
I just take it as the company pay them well than they pay me bad. However if I feel that my pay is below market rate, then it's another matter.
I just take it as the company pay them well than they pay me bad. However if I feel that my pay is below market rate, then it's another matter.
There is little semblance of meritocracy, especially in larger companies where salaries are not even determined on an individual basis, but more as a function of years worked and meeting the minimum bar to sustain good yearly ratings.
The structure itself is preset, and no matter how effective you are in your role, companies generally recognize that competing for talent has a narrow value range. Companies are hurting for sound product ideas and good business plans more than they are for talented people to implement them. As long as all of their corporate peers are generally in the same boat, turnover is merely a statistic. Talent comes and goes, and you only need to acquire at equal rates to your talent losses.
Hiring is just as hit or miss, and article after article here demonstrates that corporate America has given up trying to innovate on that process. If companies could bureaucratically recognize talent internally, then maybe they could hire better candidates. But that’s expensive, and like I said before, the value proposition is limited. If they hire a 10x person, it’s a risky investment anyway, because they’ll leave a 10x hole to fill. It’s just easier to hire 10x people, which has better statistical stability in turnover.
The structure itself is preset, and no matter how effective you are in your role, companies generally recognize that competing for talent has a narrow value range. Companies are hurting for sound product ideas and good business plans more than they are for talented people to implement them. As long as all of their corporate peers are generally in the same boat, turnover is merely a statistic. Talent comes and goes, and you only need to acquire at equal rates to your talent losses.
Hiring is just as hit or miss, and article after article here demonstrates that corporate America has given up trying to innovate on that process. If companies could bureaucratically recognize talent internally, then maybe they could hire better candidates. But that’s expensive, and like I said before, the value proposition is limited. If they hire a 10x person, it’s a risky investment anyway, because they’ll leave a 10x hole to fill. It’s just easier to hire 10x people, which has better statistical stability in turnover.
Cause no one is, that would be called participating employees into company's profit.
Here's what I've noticed in my career so far. It's difficult if not impossible to assign an actual concrete value to programmer productivity. This makes it difficult to compare programmers side by side and assign a true value to each of them. Some companies rank developers but it's done subjectively. This fuzziness allows businesses to not pay fairly for extreme productivity (and conversely, forces them to pay too much for crappy productivity). Usually at any company there are one or more 10x programmers who do most of the work and a ton of mediocre developers.
While I don't agree that it's impossible to assign concrete value, any value suffers from network effects. Gaps in people's skillsets can be made up with someone strong in a gap and another person for another gap and now you have 2 less productive people individually, but they make the group better overall.
When you replace 1 guy with 19 (as per another thread), the management is easier as there is less need for focus and more flexibility in hiring/firing, which is worth a lot.
When you replace 1 guy with 19 (as per another thread), the management is easier as there is less need for focus and more flexibility in hiring/firing, which is worth a lot.
I have found that the most effective programmers are diplomats, they consider consequences and don’t dive into making unconsidered fixes. They understand that the code they write is not only for themselves and that nothing, especially not people, works in isolation. My preference is for clarity and comprehension over breakneck, manic late-night cola-fueled, pizza-box programming sessions. This isn’t The Matrix…
> My preference is for clarity and comprehension over breakneck, manic late-night cola-fueled, pizza-box programming
Mine, too - but we're not the ones making the decisions and writing the paychecks... and our preference for "good" over "right now" is why we're not the ones making the decisions and writing the paychecks.
Mine, too - but we're not the ones making the decisions and writing the paychecks... and our preference for "good" over "right now" is why we're not the ones making the decisions and writing the paychecks.
Programmers are paid the market rate for their field, level, geographic area. It's just supply and demand.
Only on entry to new firm.
After that its the lowest raise they can get away with and not lose you.
After that its the lowest raise they can get away with and not lose you.
Besides this being an extremely utilitarian way to view of humans that obfuscates inherent value of human beings, it is a general problem with wage labour under capitalism, where only capital earns proportional to its “value”.
I think we should focus our energy more on the question how we can provide everyone according to their needs than how utilizable they are, if we want to live in a more healthy and thriving society than we currently do! At the end there is really no need to give some people 10 times more just because they are productive in a certain way. And this calculation already fails as soon as we add more dimension to it, e.g. someone might not be producing 10 times more productive code but maybe they do offer a lot of social skills that make everyone in the team have a better time during work hours.
I think we should focus our energy more on the question how we can provide everyone according to their needs than how utilizable they are, if we want to live in a more healthy and thriving society than we currently do! At the end there is really no need to give some people 10 times more just because they are productive in a certain way. And this calculation already fails as soon as we add more dimension to it, e.g. someone might not be producing 10 times more productive code but maybe they do offer a lot of social skills that make everyone in the team have a better time during work hours.
Sometimes to make a project work you need all types of work, not only high visibility, high impact work that gets management attention and raises.
Good example is promo process at a particular large tech company - you win promo by picking a project that is high visiblity, appears difficult, standalone piece with "ownership". Maybe 25% of work that needs to be done meets this criteria.
It's hard to get promoted for "product excellence". They tried to do a push a few years ago, when I was there. You won't get promoted for fixing an issue that annoys millions of users or maintaining a succesfull product, unless you really build a case around that with data, case studies, etc. You would spend more than half of your effort on proving that your work is valuable.
Good example is promo process at a particular large tech company - you win promo by picking a project that is high visiblity, appears difficult, standalone piece with "ownership". Maybe 25% of work that needs to be done meets this criteria.
It's hard to get promoted for "product excellence". They tried to do a push a few years ago, when I was there. You won't get promoted for fixing an issue that annoys millions of users or maintaining a succesfull product, unless you really build a case around that with data, case studies, etc. You would spend more than half of your effort on proving that your work is valuable.
If the product was successful even with the bug that annoyed millions of users, then have you really contributed anything by fixing it? Sometimes, the answer is yes, but I think it makes sense to require data to back that up. Similarly, data should be required for new products as well. Like great, you built this new system, but no one used it so you actually just wasted a bunch of time.
That's the tragedy of software development. Nobody wants to do work that isn't super visible (usually in the form of new features). Simplicity and robustness are not appreciated nor rewarded.
> You would spend half of your effort on proving that your work is valuable.
That seems.... reasonable?
That seems.... reasonable?
"salaries usually fall within a fairly small range in any company"
I don't think so? I've heard that some top-tier talent makes $500k annually while most beginners make $50k annually. Isn't that a 10x difference which would be in line with 1x beginners vs. 10x pros?
I don't think so? I've heard that some top-tier talent makes $500k annually while most beginners make $50k annually. Isn't that a 10x difference which would be in line with 1x beginners vs. 10x pros?
The important bit is the “in any company.” Generally speaking the 500k developers are going to different companies than the 50k developers. The range at the 500k person’s company is lets say 300k-600k, while the range at the 50k company is lets say 40k-70k. The sorting of skill happens in line with a company’s ability to pay talent.
no one gets paid on proportion to their productivity. artists do not, actors do not, managers do not, politicians certainly do not. you get paid according to your perceived market value unless you contract per well defined project(not per hr)
The incentive structure for an above average programmer is usually somewhat broken, though stock options can theoretically patch this up some.
The way to get maximum return on your above-average output is to go into business for yourself.
The way to get maximum return on your above-average output is to go into business for yourself.
I am (among other things) a programmer, I absolutely do not management to have yet another string to pull me by, routinely adjusting my pay according to whatever social-engineering game they choose to decide "productivity" by.
Plus, for some of my work - it might seem even to a "fair" lay-person that I'm doing practically nothing except wasting my time for a year, then do a year's work in a couple of weeks. At other times, my contribution might be _preventing_ the introduction of poorly-designed or faulty code; so, in a sense, negative productivity...
Plus, for some of my work - it might seem even to a "fair" lay-person that I'm doing practically nothing except wasting my time for a year, then do a year's work in a couple of weeks. At other times, my contribution might be _preventing_ the introduction of poorly-designed or faulty code; so, in a sense, negative productivity...
If compensation was simply measured by productivity relative to your co-workers - and let us assume this is not a zero-sum game, and that your compensation independent from company revenue - wouldn't the most proficient and productive programmers seek to work with much less productive co-workers? Simply because they'd come out at the top, and get most compensation.
Compare that to joining a "all-star" team, where there's much less variance. You'd get paid less - because the distance between best and worst programmer is much smaller?
Compare that to joining a "all-star" team, where there's much less variance. You'd get paid less - because the distance between best and worst programmer is much smaller?
"Programmers are most effective when they avoid writing code" is the crux of this article, and stated like a fact. IMO this is not as obvious as the author believes, and needs a solid defense.
This touches on the very very obvious tension here that I think needs to be understood and stated more clearly:
Software, in theory, is frictionlessly infinitely reproducible. We now know that there are quite a few 10x, 100x, 1000x programmers out there, and yet a lot of people still getting paid to write code, which is probably a massive waste of time.
I'm not sure how we get to collectively recognizing this inefficiency, but something to try would be "more liability (some liability? like any liability at all?) for bad/harmful software.
Software, in theory, is frictionlessly infinitely reproducible. We now know that there are quite a few 10x, 100x, 1000x programmers out there, and yet a lot of people still getting paid to write code, which is probably a massive waste of time.
I'm not sure how we get to collectively recognizing this inefficiency, but something to try would be "more liability (some liability? like any liability at all?) for bad/harmful software.
Um, they are paid in terms of their productivity. However, it's not how productive they are as a programmer, but how their work translates into business value.
While measuring programmer productivity is not trivial, measuring the value of the average programmer on the revenue generated is much easier. For this reason, an average programmer at Facebook will be earning a lot more money than a great programmer at a small regional bank.
While measuring programmer productivity is not trivial, measuring the value of the average programmer on the revenue generated is much easier. For this reason, an average programmer at Facebook will be earning a lot more money than a great programmer at a small regional bank.
Define productivity.
A previous colleague at my company rushed out a load of new code in 3 months, then left the company. What a steaming pile of crap he left us. After nearly a year and a half we have had our first week without support requests related to this. This guy wrote order of magnitude more code than the others on the team, but we have spent many more hours cleaning up the crap he left.
A previous colleague at my company rushed out a load of new code in 3 months, then left the company. What a steaming pile of crap he left us. After nearly a year and a half we have had our first week without support requests related to this. This guy wrote order of magnitude more code than the others on the team, but we have spent many more hours cleaning up the crap he left.
> Programmers are most effective when they avoid writing code.
I understand the sentiment, but there's weak evidence to measure effectiveness by offloading work to others.
Not writing code for non-core purposes is not the same as avoiding it. Nor is avoiding policy-mandated code (things like tests and build scripts) making someone more effective, when it's shifting the load to others.
I understand the sentiment, but there's weak evidence to measure effectiveness by offloading work to others.
Not writing code for non-core purposes is not the same as avoiding it. Nor is avoiding policy-mandated code (things like tests and build scripts) making someone more effective, when it's shifting the load to others.
It's because they're milking inventions they didn't invent for salaries that don't reflect their intrinsic value.
If you disagree go talk to Alan Kay or Christina Engelbart.
Because engineering is considered as "liability" while sales are "assets".
Investment in more sales gives almost immediate gratification while investment in engineering takes longer and carrying bigger risk.
Thus majority of senior execs never like conversation about more investment into engineering
Investment in more sales gives almost immediate gratification while investment in engineering takes longer and carrying bigger risk.
Thus majority of senior execs never like conversation about more investment into engineering
Because compensation should be proportional to investment and both the 1X and 10X programmers invest the same thing, eight hours of their time each working day. In practice things are more complicated as this creates undesirable incentives but I think the general point stands.
You go ahead and do that, pay your employees based on the hours they are “there“.
Your competitor pays its employees based on each employee’s results.
Then let’s see which company survives in the market.
Your competitor pays its employees based on each employee’s results.
Then let’s see which company survives in the market.
It’s complicated to know, because identifying which of your employees is providing the results is a hard problem. In practice it often devolves into people spending at least as much time marketing themselves to management as they do actually being productive, and optimizes for people who are good at that marketing being in high positions instead of people who are most productive. The larger the company the more pronounced this issue is, which is why so many large companies aren’t kicked out of the market despite their lack of ability/willingness to pay according to results.
That doesn’t matter either.
If you have an average employee who complains a lot and he may leave, but that would be a hassle for you, then it makes sense to pay him a bit more so he shuts up and you don’t have to look for a new person.
Otoh, if your underpaid star developer sits quietly in his corner and all you have to do is to pat him on the back once in a while to keep him happy, why would you pay him more?
If you have an average employee who complains a lot and he may leave, but that would be a hassle for you, then it makes sense to pay him a bit more so he shuts up and you don’t have to look for a new person.
Otoh, if your underpaid star developer sits quietly in his corner and all you have to do is to pat him on the back once in a while to keep him happy, why would you pay him more?
That is why I mentioned incentives. To make it more precise, assuming everyone works to the best of their abilities, people should be compensated in proportion to the time they work, not the output of their work.
> should be compensated in proportion to the time
This assumption doesn't always hold.
Employee and employer might agree to share the value created which is not always a function of time spent working.
This assumption doesn't always hold.
Employee and employer might agree to share the value created which is not always a function of time spent working.
Can you give an example? I don't think this is impossible, but I can not immediately think of an example. And this probably heavily depends on what you mean with value created.
Example of compensation not tied to a time spent: a company might pay someone to do nothing, so this someone doesn't do something for a competitor.
Value sharing is a basic framework for compensation negotiation. Employee wants to get all the value derived from own contribution. Employer wants to pay absolute minimum employee is willing to accept. Paying more than derived value doesn't make economic sense, so compromise will be somewhere within this range. If acceptable minimum is below the derived value, compromise is impossible. Time spent working is a free variable in all this.
Value sharing is a basic framework for compensation negotiation. Employee wants to get all the value derived from own contribution. Employer wants to pay absolute minimum employee is willing to accept. Paying more than derived value doesn't make economic sense, so compromise will be somewhere within this range. If acceptable minimum is below the derived value, compromise is impossible. Time spent working is a free variable in all this.
I mean, the market clearly favors the former...
> Because compensation should be proportional to investment and both the 1X and 10X programmers invest the same thing, eight hours of their time each working day
So you "should" pay for example Rob Pike or Ken Thompson equal to what you would pay some junior dev because they invest eight hours of their time each working day?
So you "should" pay for example Rob Pike or Ken Thompson equal to what you would pay some junior dev because they invest eight hours of their time each working day?
Without being able to see their contracts, I would imagine Pike and Thompson have been around the block long enough to know that selling time isn't always the best option. They may put in eight hours of work (although I believe both are basically retired at this point), but if that's not what they are selling, the time spent is moot.
To illustrate further, as a farmer, I sell grain, not time. The job requires my time to be inputted, yes, but if I put in eight hours of work or two hours of work to produce the same amount of grain, I am getting paid the same either way. Developers can structure themselves similarly, which is to say selling something that is the product of time, not time itself, if they so choose.
The average developer, especially those on the lower end of the pay scale, however, most commonly chooses to sell their time and their time alone. And when you are selling hours just like everyone else, price is going to converge within a relatively narrow range. An hour is an hour is an hour so it is difficult to differentiate if one hour is more valuable than another or how that hour translates into the output, and so it is priced accordingly.
To illustrate further, as a farmer, I sell grain, not time. The job requires my time to be inputted, yes, but if I put in eight hours of work or two hours of work to produce the same amount of grain, I am getting paid the same either way. Developers can structure themselves similarly, which is to say selling something that is the product of time, not time itself, if they so choose.
The average developer, especially those on the lower end of the pay scale, however, most commonly chooses to sell their time and their time alone. And when you are selling hours just like everyone else, price is going to converge within a relatively narrow range. An hour is an hour is an hour so it is difficult to differentiate if one hour is more valuable than another or how that hour translates into the output, and so it is priced accordingly.
If the market works, the price should go down approaching production costs, i.e. time invested. If you are able to charge more than that, there is some kind of market failure like a lack of competition.
That's tech in a nutshell. Being a race to finding some kind of moat (intellectual property law, network effects, etc.) to prevent an efficient market from being established.
Yes. To a first approximation, ignoring a gigantic pile of complications due to incentives. And the person cleaning the office should get the same pay as well.
Since we're talking about investments, did the person cleaning the office invest the time to become adept at programming? Unlikely.
The cost of an item is often linked to how much was invested (because that is linked to how much it took to come to fruition, and therefore, how much it needs to sell at to recoup that investment). It's not only the 8 hours that is invested, it's the previous investment that needs to be recouped. That's one reason behind why different people cost different things, which is ultimately down to quality.
We're back to the initial question but at least we've dispensed with communism in the meantime.
The cost of an item is often linked to how much was invested (because that is linked to how much it took to come to fruition, and therefore, how much it needs to sell at to recoup that investment). It's not only the 8 hours that is invested, it's the previous investment that needs to be recouped. That's one reason behind why different people cost different things, which is ultimately down to quality.
We're back to the initial question but at least we've dispensed with communism in the meantime.
I am fine with that, you get compansated for the longer education period, you get 10 or 20 percent more than someone doing a cleaning job.
In most cases, end customers don't eat or use code.
Code is a vehicle for delivering value to customers.
Developers are not the only one contributing to creation of product.
In cases where you 'can' establish direct correlation between more/better code = more margin, then you can flex your leverage.
Code is a vehicle for delivering value to customers.
Developers are not the only one contributing to creation of product.
In cases where you 'can' establish direct correlation between more/better code = more margin, then you can flex your leverage.
For some reason this thread makes me think of this Steve Balmer on KLOCs rant.
https://www.youtube.com/watch?v=kHI7RTKhlz0
https://www.youtube.com/watch?v=kHI7RTKhlz0
I don't understand, how is a company supposed to make money at all if the worker is paid proportionally to their productivity?
"proportionally to" != "strictly equal to"
I find a lot of my productivity boils down to knowing what work not to bother with. This can be hard to value.
In short, Programmers are not great Negotiators. Thus, they get "the business" from The Business.
You can't just guess at which 25 percent of your employees not to pay.
Because that would be a stupid, factory floor mentality?
Oh God, are we still discussing 10x programmers?
Please let's not.
Please let's not.
Not just 10x, there's even a 19x programmer in our midst!
Seriously though, reading through this thread (and similar ones) is exhausting. Somehow everyone who programs and visits HN is the most efficient/10x/whatever programmer and simultaneously every mid+ manager somehow fell upwards into their current position by pure luck with no knowledge of anything at all.
Seriously though, reading through this thread (and similar ones) is exhausting. Somehow everyone who programs and visits HN is the most efficient/10x/whatever programmer and simultaneously every mid+ manager somehow fell upwards into their current position by pure luck with no knowledge of anything at all.
[deleted]
10x engineers don't exist, or if they do, they are less than .1% of engineers. 2x engineers, sure, 2.5-3x even, but 10x? A fantasy, a pure invention with no data to back it up. Factor that into your analysis.
The company downfall is always hiring the first "manager". After that managers will just keep inventing excuses to expand their dominion, until the company is 50% management, there's more people than actual work that needs being done, yet all work grinds to almost complete halt.
Even if a given individual is not a self-serving moron, they are overpowered by the dynamics of the group and they either comply and play the game, or they are out.
The bigger the group, the easier it is to hide in a corner with incompetence, stupidity, politics, optimize for your personal gain, and the harder it is to actually competently judge the performance and contributions of each member.
Hierarchies make people optimize for raising in the hierarchy, and accumulating power, at the expense of actually doing what the group needs.
The way human groups organize in practice is pretty much always complete dysfunction without motivated, benevolent and competent leaders at the very top. Our own self-interest combined with natural bias and blind spots in aggregate always win. And the dysfunction grows more than linear with the size of the group.
At the corporate size there is practically no actual owner/leader overseeing things (even the board is just bunch of self-serving assholes), so you effectively get a smaller and private replica of a communist state. If you read anything about communist state politics and management you're going to see 1:1 with every corporation you've ever worked in.