12 ms·

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 ye

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.

tiffanyh 4y ago
Unpopular view here ... if it took 19 engineers to rebuild your software - that seems like a failure on your part (not theirs).
- jraph 4y ago
  Can you develop? It seems to me the need to rewrite the project at all, depending on the reasons, could be the failure, not that it took one year and 19 engineers to do it.
  - fendy3002 4y ago
    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.
    - heretogetout 4y ago
      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.
- izzydata 4y ago
  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.
  - gsibble 4y ago
    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..
  - kayodelycaon 4y ago
    There are a lot of explanations possible. I’ve deal with with the aftermath of with “80% developers” my entire career. In two weeks, they’d write a good enough program with no handling of edge cases or errors. Replacing one of these with a proper application can take a year. I’ve also dealt with a team of programmers who couldn’t come close to my productivity solo. It was due to constraints and communication overhead, not incompetence. When you go from a solo dev to a team of 19, that sounds more like a change in strategy by management than anything else.
    - bmitc 4y ago
      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.
- deleted 4y ago
  [deleted]
- fartsucker69 4y ago
  can you explain? there's no logical link here for me at all. if OP was never born and they had to build that app from scratch, and it took them 1 year and 19 engineers to do it, you wouldn't be posting the same thing.
  - headsoup 4y ago
    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...
    - gsibble 4y ago
      They never gave me time to write documentation. I was working 100 hour weeks, almost all coding, under tight deadlines. You can see why I wanted a raise.
    - tartoran 4y ago
      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.
      - headsoup 4y ago
        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...
- wgj 4y ago
  Junior/mid devs will rewrite something they don't understand, rather than analyze and understand it. Everyone wants a green field project.
olivierduval 4y ago
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
- gsibble 4y ago
  I was Chief Software Architect.
mathattack 4y ago
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.
- SenHeng 4y ago
  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.
  - mathattack 4y ago
    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.
    - ratww 4y ago
      > 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.
    - Suchos 4y ago
      I was told it's different budget line, so nobody really cares. HR just does not like to see IT being paid 4 times as much as them.
  - hibikir 4y ago
    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.
PainfullyNormal 4y ago
You would think that if management had known it would cost them at least 19x what they were paying you, they would be happy to give you whatever raise you asked. But, maybe not. There are a lot of other factors. There's a trust factor. For some reason, upper management doesn't necessarily trust the judgement of their lower management, like like lower management rarely trusts the judgement of their engineers. There's an information disparity. Upper management often doesn't see what people on the lower rungs of the org chart are doing. To upper management, it looks like the one who's getting all the things done is lower management, not the engineers. There's also a psychological factor. For some reason, humans are much more likely to overpay for something new than to pay far less to maintain something old. I'm not entirely sure why, but I see this mentality affect everybody from upper management to engineers to people buying cars. There's also the ego factor. I've seen some business owners react very, very poorly to having an employee request a raise. It can be perceived as somebody trying to take more money out of your pocket for no return. This can also be applied to larger companies and budgets, bonuses, etc. There's also the "fiefdom" factor. Your management might see expanding your team from 1 engineer to 19 as an improvement to their social standing in the company regardless of how much money it costs the company. The larger your department, the more important you're perceived to other departments and the c-suite. edit: spelling and clarity.
- Forgeties79 4y ago
  >I'm not entirely sure why I’ve always seen it as an offshoot of the mentality that fixing something old is often delaying an inevitable new purchase (especially when it comes to tech). Total armchair theory based on how if it’s limping along usually they’ll go “well just keep using it we’ll upgrade later.”
- cryptica 4y ago
  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.
szszrk 4y ago
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.
- gsibble 4y ago
  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.
- fartsucker69 4y ago
  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.
  - gsibble 4y ago
    I am very senior (25+ years experience) and they used all jrs (1-3 yrs). They seemed of the mindset that monkeys can write Shakespeare.
olavgg 4y ago
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.
- gsibble 4y ago
  I did. It's currently worth $6 billion. But it was a horrible experience that nearly killed me. Not interested in doing that again.
- NineStarPoint 4y ago
  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.
  - tartoran 4y ago
    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.
    - freemint 4y ago
      Why would you though? A life with a salary and being able to switch jobs to get a better offer/move on is comfortable.
deleted 4y ago
[deleted]
a_c 4y ago
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.
coffeeblack 4y ago
What do you think is better for your manager’s own salary: managing a large team of 19 people or managing one person?
onlyrealcuzzo 4y ago
> and engineering is looked at as a cost center to be minimized Labor is a cost center to be minimized for a business. Your goal is to make money. If you can do that by having $0 in labor costs, then you want to. The reason programmers aren't paid in proportion to their productivity is the same that every other profession also is not. You get paid the least your employer can get away with paying you, not what you "deserve". It's better if everyone recognizes this. You probably want to avoid companies where the incentives aren't in place for you to grow.
- globalreset 4y ago
  > 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.
  - onlyrealcuzzo 4y ago
    > 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.
- yumaikas 4y ago
  > 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
analog31 4y ago
So the value of your work was -19 programmer years, the cost to clean up after you're gone. Was the code that bad? This is why we don't pay for productivity. It can't be measured, and the principal -agent problem looms large.
- whateveracct 4y ago
  This assumes that the 19 programmer decision was a good technical decision. Most of these styles of rewrites I've seen over the years are grossly wasteful and mostly motivated by ego and politics.
  - lostcolony 4y ago
    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.
    - analog31 4y ago
      I've seen code so bad that it was declared to be a total loss after the original programmer was discharged.
      - whateveracct 4y ago
        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.
geoduck14 4y ago
>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.
- gsibble 4y ago
  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.
- lawl 4y ago
  > 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?
jbverschoor 4y ago
Yup.. just management that doesn’t want pay for to talent. It’s sad, bc people do understand the difference with other people.. sports, singing, poker, etc etc
dahart 4y ago
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.
- BlargMcLarg 4y ago
  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.
makz 4y ago
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.
- gsibble 4y ago
  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.
geebee 4y ago
It sounds like they should have paid to keep you. That said, I've written software that I would expect would require more engineers to keep around long term, in production. Better testing, security, reliability, scalability, maintainability. I can say this without disparaging my own work (well, I probably deserve at least a little criticism) or the people who took over the project. Some software developers are really ingenious but a bit too undisciplined, great at understanding the business environment, and good enough at overall coding and architecture that what they build can be put into production without great risk or reliability, albeit with notable technical debt. In short, they actually build the tire rope swing,and without this kind of developer, the tire swing will never be built. It simply will not result from the 19 developer team you mentioned. But it takes a very different kind of discipline to convert this into something that can work long term, and sometimes people are genuinely shocked to discover how much it will actually cost to make that rope swing safe and reliable in the long term. By the way, I do want to make sure I emphasize that this isn't necessarily what happened in your case. Based on past experience, I have little trouble believing that you were simply replaced by a very expensive large team that didn't accomplish as much as you did along almost every axis, from maintainability to security to business relevance to innovation.
- gsibble 4y ago
  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.
atoav 4y ago
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.
lawl 4y ago
Funny, i was once in a project where i was asked to build some software. They asked if I can do it in a year. When I asked for requirements they deflected to scrum. Probably the shittiest job I've ever had. Asked to build a system in a year with no pre-defined scope or requirements (which I complained about in advance). Told them I can build something in a year. Of course they weren't happy about something because they wanted more. Told them to go fuck themselves. Frankly, I should have seen it coming before the project started. Fixed budget, no requirements or scope should have been a giant red flag in hindsight. I wonder what happened to that.
- ratww 4y ago
  > Fixed budget, no requirements or scope Their requirements were pretty clear to me: they want to have a cake and eat it.
trashtester 4y ago
I did something similar a 4 or so years back. I wrote something in a month (+ a couple of working with stakeholders to make sure it did what it should). I did it in a legacy tech stack that the architects didn't like, on the side of the main activity, as the deadline was coming close and some hireing processes were slow. A team of around devs 5 (some coming and going) having been trying to solve the same problem since, but they're still not being close to finished. In other words, the productivity is in the order 50x to 100x slower than when I did it. Rather, the main reason was that I knew how to write code like that, while they were set up to fail. Basically, some architect was making all sorts of unnecessary demands for how to wite the code, and the programers were not familiar with much of the tech stack that was introduced. Also, coding standards were really verbose, easily 10x-30x what I wrote, in lines of code. The current state of what they have look suspiciously like FizzBuzzEnterpriseEdition: https://github.com/EnterpriseQualityCoding/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.
jerednel 4y ago
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.

tiffanyh 4y ago

Unpopular view here ... if it took 19 engineers to rebuild your software - that seems like a failure on your part (not theirs).

jraph 4y ago
Can you develop? It seems to me the need to rewrite the project at all, depending on the reasons, could be the failure, not that it took one year and 19 engineers to do it.
- fendy3002 4y ago
  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.
  - heretogetout 4y ago
    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.
izzydata 4y ago
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.
- gsibble 4y ago
  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..
- kayodelycaon 4y ago
  There are a lot of explanations possible. I’ve deal with with the aftermath of with “80% developers” my entire career. In two weeks, they’d write a good enough program with no handling of edge cases or errors. Replacing one of these with a proper application can take a year. I’ve also dealt with a team of programmers who couldn’t come close to my productivity solo. It was due to constraints and communication overhead, not incompetence. When you go from a solo dev to a team of 19, that sounds more like a change in strategy by management than anything else.
  - bmitc 4y ago
    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.
deleted 4y ago
[deleted]
fartsucker69 4y ago
can you explain? there's no logical link here for me at all. if OP was never born and they had to build that app from scratch, and it took them 1 year and 19 engineers to do it, you wouldn't be posting the same thing.
- headsoup 4y ago
  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...
  - gsibble 4y ago
    They never gave me time to write documentation. I was working 100 hour weeks, almost all coding, under tight deadlines. You can see why I wanted a raise.
  - tartoran 4y ago
    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.
    - headsoup 4y ago
      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...
wgj 4y ago
Junior/mid devs will rewrite something they don't understand, rather than analyze and understand it. Everyone wants a green field project.

olivierduval 4y ago

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

gsibble 4y ago
I was Chief Software Architect.

mathattack 4y ago

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.

SenHeng 4y ago
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.
- mathattack 4y ago
  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.
  - ratww 4y ago
    > 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.
  - Suchos 4y ago
    I was told it's different budget line, so nobody really cares. HR just does not like to see IT being paid 4 times as much as them.
- hibikir 4y ago
  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.

PainfullyNormal 4y ago

You would think that if management had known it would cost them at least 19x what they were paying you, they would be happy to give you whatever raise you asked. But, maybe not. There are a lot of other factors. There's a trust factor. For some reason, upper management doesn't necessarily trust the judgement of their lower management, like like lower management rarely trusts the judgement of their engineers. There's an information disparity. Upper management often doesn't see what people on the lower rungs of the org chart are doing. To upper management, it looks like the one who's getting all the things done is lower management, not the engineers. There's also a psychological factor. For some reason, humans are much more likely to overpay for something new than to pay far less to maintain something old. I'm not entirely sure why, but I see this mentality affect everybody from upper management to engineers to people buying cars. There's also the ego factor. I've seen some business owners react very, very poorly to having an employee request a raise. It can be perceived as somebody trying to take more money out of your pocket for no return. This can also be applied to larger companies and budgets, bonuses, etc. There's also the "fiefdom" factor. Your management might see expanding your team from 1 engineer to 19 as an improvement to their social standing in the company regardless of how much money it costs the company. The larger your department, the more important you're perceived to other departments and the c-suite. edit: spelling and clarity.

Forgeties79 4y ago
>I'm not entirely sure why I’ve always seen it as an offshoot of the mentality that fixing something old is often delaying an inevitable new purchase (especially when it comes to tech). Total armchair theory based on how if it’s limping along usually they’ll go “well just keep using it we’ll upgrade later.”
cryptica 4y ago
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.

szszrk 4y ago

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.

gsibble 4y ago
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.
fartsucker69 4y ago
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.
- gsibble 4y ago
  I am very senior (25+ years experience) and they used all jrs (1-3 yrs). They seemed of the mindset that monkeys can write Shakespeare.

olavgg 4y ago

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.

gsibble 4y ago
I did. It's currently worth $6 billion. But it was a horrible experience that nearly killed me. Not interested in doing that again.
NineStarPoint 4y ago
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.
- tartoran 4y ago
  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.
  - freemint 4y ago
    Why would you though? A life with a salary and being able to switch jobs to get a better offer/move on is comfortable.

deleted 4y ago

[deleted]

a_c 4y ago

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.

coffeeblack 4y ago

What do you think is better for your manager’s own salary: managing a large team of 19 people or managing one person?

onlyrealcuzzo 4y ago

> and engineering is looked at as a cost center to be minimized Labor is a cost center to be minimized for a business. Your goal is to make money. If you can do that by having $0 in labor costs, then you want to. The reason programmers aren't paid in proportion to their productivity is the same that every other profession also is not. You get paid the least your employer can get away with paying you, not what you "deserve". It's better if everyone recognizes this. You probably want to avoid companies where the incentives aren't in place for you to grow.

globalreset 4y ago
> 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.
- onlyrealcuzzo 4y ago
  > 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.
yumaikas 4y ago
> 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

analog31 4y ago

So the value of your work was -19 programmer years, the cost to clean up after you're gone. Was the code that bad? This is why we don't pay for productivity. It can't be measured, and the principal -agent problem looms large.

whateveracct 4y ago
This assumes that the 19 programmer decision was a good technical decision. Most of these styles of rewrites I've seen over the years are grossly wasteful and mostly motivated by ego and politics.
- lostcolony 4y ago
  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.
  - analog31 4y ago
    I've seen code so bad that it was declared to be a total loss after the original programmer was discharged.
    - whateveracct 4y ago
      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.

geoduck14 4y ago

>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.

gsibble 4y ago
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.
lawl 4y ago
> 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?

jbverschoor 4y ago

Yup.. just management that doesn’t want pay for to talent. It’s sad, bc people do understand the difference with other people.. sports, singing, poker, etc etc

dahart 4y ago

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.

BlargMcLarg 4y ago
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.

makz 4y ago

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.

gsibble 4y ago
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.

geebee 4y ago

It sounds like they should have paid to keep you. That said, I've written software that I would expect would require more engineers to keep around long term, in production. Better testing, security, reliability, scalability, maintainability. I can say this without disparaging my own work (well, I probably deserve at least a little criticism) or the people who took over the project. Some software developers are really ingenious but a bit too undisciplined, great at understanding the business environment, and good enough at overall coding and architecture that what they build can be put into production without great risk or reliability, albeit with notable technical debt. In short, they actually build the tire rope swing,and without this kind of developer, the tire swing will never be built. It simply will not result from the 19 developer team you mentioned. But it takes a very different kind of discipline to convert this into something that can work long term, and sometimes people are genuinely shocked to discover how much it will actually cost to make that rope swing safe and reliable in the long term. By the way, I do want to make sure I emphasize that this isn't necessarily what happened in your case. Based on past experience, I have little trouble believing that you were simply replaced by a very expensive large team that didn't accomplish as much as you did along almost every axis, from maintainability to security to business relevance to innovation.

gsibble 4y ago
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.

atoav 4y ago

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.

lawl 4y ago

Funny, i was once in a project where i was asked to build some software. They asked if I can do it in a year. When I asked for requirements they deflected to scrum. Probably the shittiest job I've ever had. Asked to build a system in a year with no pre-defined scope or requirements (which I complained about in advance). Told them I can build something in a year. Of course they weren't happy about something because they wanted more. Told them to go fuck themselves. Frankly, I should have seen it coming before the project started. Fixed budget, no requirements or scope should have been a giant red flag in hindsight. I wonder what happened to that.

ratww 4y ago
> Fixed budget, no requirements or scope Their requirements were pretty clear to me: they want to have a cake and eat it.

trashtester 4y ago

I did something similar a 4 or so years back. I wrote something in a month (+ a couple of working with stakeholders to make sure it did what it should). I did it in a legacy tech stack that the architects didn't like, on the side of the main activity, as the deadline was coming close and some hireing processes were slow. A team of around devs 5 (some coming and going) having been trying to solve the same problem since, but they're still not being close to finished. In other words, the productivity is in the order 50x to 100x slower than when I did it. Rather, the main reason was that I knew how to write code like that, while they were set up to fail. Basically, some architect was making all sorts of unnecessary demands for how to wite the code, and the programers were not familiar with much of the tech stack that was introduced. Also, coding standards were really verbose, easily 10x-30x what I wrote, in lines of code. The current state of what they have look suspiciously like FizzBuzzEnterpriseEdition: https://github.com/EnterpriseQualityCoding/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.

jerednel 4y ago

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.