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..
> 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 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.
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).
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.
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.
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.
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.
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.
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.
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.
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..
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...
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...
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.
If they simply pretended it does not exist, they should be able to rewrite it with 1 developer in less than a year. If they can't and need an order of magnitude more resources, that's a sign of incompetence on the new team.
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.
> 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.
- 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
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.
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.
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)
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
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.
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 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 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.
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.
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.
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.
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.”
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.
> 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.
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.
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.
> 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.
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.
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.
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.
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.
> 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.
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.
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.
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.
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.
> 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.
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.
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.
>> 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.
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.
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.
> 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.
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 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.
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.
> 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.
> 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.
> 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
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.
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 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.
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.
> 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.
>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?
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.
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 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 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 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:
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.
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.
>"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."
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.
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.
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"?
> 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.
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.
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.
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.
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.
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.
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.
> 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.
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.
"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?
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.
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.
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.
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.
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.
> 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.
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
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.
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.
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.
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.
> 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?
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.
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.
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.
> 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).
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.
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.
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.
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.
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 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.
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.
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.
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.
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.
312 comments
[ 2.2 ms ] story [ 265 ms ] threadThis 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..
https://www.folklore.org/StoryView.py?story=Negative_2000_Li...
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.
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).
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.
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.
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.
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.
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.
They are often quite intelligent and very productive, but aren't inclined to think a problem through to completion.
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.
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.
Why, in any scenario, would something well coded and documented need that amount of rework otherwise? Aside political, ego reasons that is...
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 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.
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.
Each of those 19 developers could have been just as good, but the problem/requirement was likely very different for them.
The reason there was 19 developers is probably because someone pulled the number 19 out of their ass.
The 19 people were all right out of coding camps and each had 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
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.
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.
You can see why I wanted a raise.
(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)
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
It’s not that managers don’t know who is good, it’s that they can’t do anything about it.
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.
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.
Sadly, 90% of them just quit before there is even a chance to give mid cycle raise.
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.
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.”
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.
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.
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.
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 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 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.
Documentation takes time. It's their fault for cutting corners and pushing out a product/service that's undocumented spaghetti 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 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.
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.
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.
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.
After their last day, if they were fired, all bets are off.
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.
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.
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.
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.
They had many problems.
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.
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.
But it was a horrible experience that nearly killed me. Not interested in doing that again.
So assuming you are still playing the employment game, maybe next time you can make arguing for you easier.
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.
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.
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.
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
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.
Most of these styles of rewrites I've seen over the years are grossly wasteful and mostly motivated by ego and politics.
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.
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.
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.
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.
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.
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.
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?
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.
It’s sad, bc people do understand the difference with other people.. sports, singing, poker, etc etc
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.
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.
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.
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.
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.
'More' meaning in every non-technical context. More paper, more communication, more heads to count, etc.
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.
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.
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.
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.
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.
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.
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.
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.
Their requirements were pretty clear to me: they want to have a cake and eat it.
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.
The bandaid had to be ripped at some point. They should have added resource over time though to take pieces bit by bit.
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.
THIS. Well said.
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.
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.
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.
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"?
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 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.
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.
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.
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.
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.
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?
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.
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.
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.
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.
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.
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
Your competitor pays its employees based on each employee’s results.
Then let’s see which company survives in the market.
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?
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.
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.
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?
Not relevant to the topic, but this one is not true.
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.
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.
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).
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.
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.
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.
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.
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.
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.
Please let's not.
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.
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.