Hacker News new | past | comments | ask | show | jobs | submit login
Individuals Matter (danluu.com)
774 points by benfrederickson 69 days ago | hide | past | favorite | 398 comments



"Who is going to do it?" is always my first question whenever I am asked to estimate a piece of work. PMs/EMs are usually taken aback by the response, as if we are all supposed to pretend that all dev "resources" are equal. Yet reality doesn't fit into neat planning spreadsheets or burndown graphs, so often gets ignored.


I got a harsh lesson about this in one of my very first jobs.

A senior engineer on my team had built a rather complicated system. He was accordingly intimately familiar with all aspects of it. So when he estimated something on that system, it came with nearly all the discovery work already done.

The PM proceeded to take an estimate from this person, hand it to a brand new hire, and expect them to deliver on that. Needless to say it could have gone better for me.


The PM proceeded to take an estimate from this person, hand it to a brand new hire, and expect them to deliver on that. Needless to say it could have gone better for me.

This is a really good thing to learn from, although I doubt it felt like it at the time. The key thing that every junior dev needs to take from it is that it's fine if things don't take however long the estimate is so long as you're regularly communicating with the PM. PMs hate surprises. They need to know exactly what the state of the project is at any given moment. For them to think that a story is progressing on track when it's not is very, very bad (in their minds; it doesn't actually matter most of the time.)

If you work on a story that's estimated to take 3 days and come back after 3 days saying "It's not done yet. I'm only half way through. I had to learn a ton of stuff!" then that knocks out loads of other things, and people get pissed off.

If you work on a story that's estimated to take 3 days, and in the stand up on day 2 you say "I think I'm going quite slowly because I'm having to learn a lot, and I don't think I'll deliver this in 3 days" then your PM will (...should?) respect that you're keeping them informed. The senior might even step up to help you get there faster.

Practically all the actual work a PM does is communication. If you're not communicating with them then you're blocking them. No one likes that.


> I think I'm going quite slowly because I'm having to learn a lot, and I don't think I'll deliver this in 3 days

Their first question after you say this will be "well, how long will it take?" Whether or not you actually have any idea how much time you'll need, you'll have to give an answer, and on that blows the schedule up too much will be strongly frowned upon.

Now you've realized you're working for a crappy PM/EM who wants you to do their job for them, since they should have already known that the estimate from the first engineer will be nowhere close to the reality from the second.

The best managers I've had have been the ones that rarely need time estimates. They know enough about what's going on, and the comparative skill levels of the engineers, to give reasonable estimates themselves in most cases.


That is a function of time in company and continuity of team more than skill of manager.


I disagree. I think skill of manager plays into it more than anything. I've seen managers come on board and within 3-6 months were able to operate like this. They focused on learning the technology and getting to know the people before they started actively managing. These were large, long running teams they were joining too.


I can double tap on that. Good manager is able to understand the product and estimate by himself.

Ive had quite a bit of experience working with different managers and overall those who were „invested” and got familiar with the product „really well” could estimate for the team.


Yup, definitely agree with this. I’ve noticed these are the managers that “feel like they’ve always been there”.


>>> Practically all the actual work a PM does is communication.

Practically all the actual work a PM does can be replaced with a script and dashboard


Practically all the actual work a PM does can be replaced with a script and dashboard

That is entirely true if you have an organised, disciplined dev team that communicates well.

Good luck with that.


This isn't true even with a organized, disciplined team. What happens is the responsibilities of get divided out to other people on the team. Usually not the entire team, so some people are stuck with unacknowledged overhead.


Unacknowledged overhead happens even with a PM present. Usually it's work that is absolutely critical to getting a project done but a PM would tell you it's a waste of time if you brought it up with them.


Thank you. Another vital point - trying to tell people the real critical path is over there but no-one agreed it in the plan is .. ahh well


For small tasks, yes this works. For larger feature work that involves cross-team collaboration, including legal, security etc, a pm is a godsend.


meh. The problem is authority. PM / manager as described above is a co-ordination issue. Often administrative as well.

Either the company is imposing administrative burden a that it can remove with a little effort and scripting, or again it is co-ordination - which software usually excels at.

We can endlessly debate specifics but yes, there are many corporate environments that are almost impossible to navigate without full-time skilled administration - it that is a choice by the company not an inherent law of nature.

I seem to recall a Microsoft anecdote where someone released an internal form for developers to fill out, and billg personally sent round collecting the form telling people that sort of thing was not the Microsoft way. Far be MSFT from an ideal but bureaucracy is a choice.

Edit: my take on hierarchy and decision making is that it is clearly "obvious" that in war and times of stress there is only enough time for one person, the "hero", to review the battlefield and make decisions, which everyone else then follows. The problem with that is throughout human history that idea has literally had no better than 50/50 chance of succeeding.

I am very much short on Project management, administrative management as authority and generally anything that points away from democracy.


Yeah why do people have this view on programmers I just don't understand, every other single effing job in the world requires training and ramp-up, except programmers? And the fact that programming is depending on a unique pre-existing really complex code base further speaks against this.

When my product owner quit, the new guy was working in parallel for 2 months to learn the ropes, noboby bats an eye, but a programmer is productive from day zero and all programmers have exactly the same output. It's so wrong


I think they underestimate the value of specific knowledge. A builder that can build X meters of wall every day van do that reasonably independent of the building site. X will of course vary when you give a new kind of stones. The problem with programming is every job has its own kind of stones.


>I think they underestimate the value of specific knowledge

This is the crux of the issue. When it comes to "Knowledge Work" almost every step sooner or later becomes a specialization. For example, I used to sneer at the role of a "Build Engineer" until i was forced to take up that role in one project. The combination of HW Platforms, OS versions, config switches, build flags, magic incantations etc. quickly gave me a new found respect for a job which i had considered "trivial".


I don't understand why you would sneer at a role in the first place, without at least taking some sort of look into what they have to do.


You have missed the point of the anecdote.

It is that one tends to underestimate the complexity involved in a particular job which has evolved well beyond its initial "trivial" requirements. Hence the need to guard consciously against such tendencies particularly in domains where you may not be competent.


I find that doesn't really capture the difference. In programming, the building part is fully automated. You press play or type a compile command and wait. If someone wants a build estimate, you should give them the time it takes to compile an deploy. Code is blueprint. Writing the code is all engineering, R&D, design and architecture and it usually entails figuring out how the system will interface with countless protocols, legacy systems, details of user's lives etc. It's nothing like building something that is already fully planned. It's a lot more like researching and planning all the details.


And they overestimate it when writing job ads.


If you wrote a novel and wanted your friend to write the final chapter, then would you need to train them in your novel beforehand? Not that much different from programming.


We're just the nerds who push the nerd-buttons. We don't need to understand how it works, or why it should be this way not that way, or what the margins are. Just push the nerd-buttons and the damn thing work like it does in my head! All the hard work has been done by the ideas people who had to do all the creative stuff and make all the hard decisions. Now it just needs to be put into the computer-thingies and work!

/s, obviously


Any tech recruiter who tells you there should be no ramp-up for programmers is lying, and you should be accordingly wary if they use a lot of "hit the ground running" talk. Fact is, nobody does that. In some jobs it might take as long as six months for programmers to reach the desired level of productivity.


I think it depends on the culture of the company. Some companies do allow engineers say a month to catch up.


I think most of us have been in your situation in the early days of our career. I still remember these PMs after all those years as rather inexperienced or incompetent and try to make sure that it does not happen on the teams i oversee.


This is just extremely (almost comically) bad project management - nobody should take a senior engineer's estimate and apply it to a new hire or jr engineer.

I've never been a PM but from my planning discussions with mine all have adjusted for seniorness, familiarity with the codebase, and skillset. When I give an estimate I am only asked to give it for myself, it's the PMs job to adjust.

I guess I've been lucky because I've never had a PM that did that poor of a job. Maybe because it's because I've almost exclusively worked at companies that provide work to a paying customer, because that environment really depends on good project management.


That engineer is Senior in title only. Unfortunately this is a common pattern - a mid-level developer will play "hero", make a mess that only they understand, and - if given the title/responsibility by immature management - proceed to royally screw their team.

Actual Seniors have the experience and foresight to handle this properly. Either build code with enough documentation/tests that others can understand it, or make an onboarding/mentoring plan for team mates, or estimate based on a teammate doing the work.

In this position: the engineering manager should remove the fake Senior from the team, that will force them to get up to speed.


Up to speed on their way out the door if they have any self esteem at all.


The management graciously allocated all the time that the senior needed for all this documentation and onboard plan, then everyone in the company clapped


Devs: there are no 10x engineers!!

Orgs: okay you are indistinguishable cogs and we will treat you as cattle

Devs: no wait not like that

Truth is everyone knows that who or which teams takes a task matters immensely. We know that if Bob leads it’s gonna suck and if Alice does it’s gonna rock and finish on time.

Managers know this also.

But we’ve constructed a corporate culture where this is not allowed to be said. So we bend over backwards to pretend everyone is equal and capable of the same things in all areas. Then we secretly make sure somehow by magic the truly critical projects are routed to the people and teams with more reliable outcomes.


The corporate culture serves a very specific purpose of lowering the self-esteem of the 10x folks, keeping them at their place doing 10x work at 1x salary until they burn out. This is scalable, predictable, and serves management's interests well.

It's just if you happen to be a 10x guy, for the sake of your own sanity, learn how to run a business and get out of the corporate swamp. Nothing else will bring you happiness, believe me.


People often forget that the 10x guy is 10x only in the domain he’s been working on, and many chores has been taken away from him by his manager and given to someone else. It is fairly easy to make a 10x someone closer to a 1x just by changing his tasks and giving more chores like CR, bug fixes, more mundane features or GUI etc. Sure it will often be better quality but in areas where it matters less.


Jeff Dean was 10x when he wrote EPI INFO, he was 10x when he worked on profilers at DEC WRL, he was 10x when he and Sanjay Ghemawat wrote MapReduce, and he was 10x when they rewrote Google's search indexer. Maybe 1000x or 10000x, really. It's true that part of that was that he worked on things that mattered instead of things that didn't, and he could have found himself in a situation where he didn't have that opportunity. But it's clearly not just productivity in a single domain, and it's not because someone else was fixing all his bugs.


There are statistical outliers in every single thing that has a big enough amount of samples and that it is possible for there to be statistical outliers.

Maybe you attract those like flies are attracted to honey, but pointing out that an Einstein existed isn't really helpful for approximately all teams of physicists out there, minus one or two teams

I'm not even saying there isn't a huge quality variance in the regular pool of programmers, mind you. Just that pointing out the existence of bad motherfuckers in a population of a few million people shouldn't come as a surprise.


The average person is about 2 meters tall, weighs about 100 kg, can run about 10 kilometers per hour, lives about 70 years, and can shovel about 60 tons of coal in a day (without power tools). If you took a sample of a few million people, it should very definitely come as a surprise to find that it included "10x" people: people who were 20 meters tall, people who weighed 1000 kg, people who could run 100 kilometers per hour, people who lived 700 years, or people who could shovel 600 tons of coal a day.

It should come as even more of a surprise to find "Jeff Dean" people who were 2 kilometers tall, or who weighed 100 tonnes, or who could run 10,000 km per hour, or who lived 70,000 years, or who could shovel 60,000 tonnes of coal in a day.

Your comments about how physicists do physics are equally wrongheaded. Physics isn't any more a matter of shoveling coal than programming is, probably less so.


What made you think I think physics or programming is analogue to easily quantifiable manual labour?

>It should come as even more of a surprise to find "Jeff Dean"

To find them, yes. To point out that they exist and the likely that you'll work with them is statistically insignificant? No.

The thing with intellectual labour is that some insights have immeasurable value. Some statistical outliers have such humongous intellectual capabilities that it's ridiculous how often they'll have great insights.

Of course, that won't stop people from trying to attach some numbers to it, even if their numbers are epistemologically shit.


None of that makes any sense.


I would be happy to explain myself better :(


The proverbial '10x developer' is by definition an outlier tho yet people never stop arguing they don't exist.


I'd wager that has something to do with jumping the shark.

People feel the need to chat about 10x developers when they don't even agree what a 1x developer is, and when they do present a definition, that definition is a function of (company, team, project, existing code base) which means there are more possible instances of 1x developers than the amount of developers who have ever lived.

Everyone is better off if they just ditch the "10x" which has connotations that programming nerds will latch on to and just use "highly performant dudes".


No, in the studies in Sackman, Erikson, and Grant's 01968 paper (10.1145/362851.362858), which is the origin of the 10x-developer idea, there were only 12 and 9 programmers, respectively. In both studies the standard deviations were comparable to the means. That means 10x developers were a substantial part of the population, and the rest of the population also has very high variance; it isn't just a question of a few outliers.

Jeff Dean is probably legitimately an outlier, though.


I'm not sure you can generalize from the top 0.001% like Jeff Dean to the top 10% or even 1%


This is just a redressing of the same “everyone is just as good” bullshit. Some people get a fuckload more work done because they go down the right design paths to start with, know how to work effectively, know what pieces to skip, etc.

The same is true in nearly every field. Programming is not special.


I deliberately used “closer to 1x”, but let me respond with an anecdote. I know several people, each working in a different org, who explicitly manage their managers by demanding to work on issues that have good visibility, are not too short >2 weeks but not too long <2-3 months so they are ready before the next review period. This way they are seen from the outside as very good performers while someone else is doing the less appreciated (but still essential) work.


I built and own a company with 200x employees building a wide variety of websites for people.

The 10x programmer is real. The 5x salesperson is real. The 20x manager is real.


Sure they are, I'm arguing that their force multiplier has to be taken with the context they are in, and that the change of the context can reduce the multiplier.


I think people also don't realize that high-performers weren't always high-performers. They had to hone their skills, usually by doing years of the right kind of challenging work with modest rewards, and sometimes they can be formed by exceptional mentoring.

But however they got there it took time, it's something that can be cultivated as long as folks aren't treated as fungible.


I disagree, the few really high-performers that I have worked with were high-performers already from the first week with a new technology, from the first month in their first job, and already as a student during practical work they were more productive than most people who had many years of challenging work behind them.

Experience is important and adds up, honing the skills makes everyone better, but it's orthogonal to this issue; there are people that will very quickly outperform someone who has honed their skills for years, and once they have honed their skills in that domain they might perhaps start outperforming them by the mythical 10x ratio.


I guess it depends on how one defines 10x or "high performer". Prodigies and maestro's will always be few and far in-between, is that what is meant by 10x? I don't know. But given the relative abundance of 10x'ers anecdotes in discussions in places like HN, I always just take that term to mean "really good" or perhaps just fuzzy romanticizing-- and not literally able to do the work of 10x "mortals".


Well, he became 10x in the domain, and the other did not become 10x, it's not like he was born with this knowledge, he just took it more seriously and went deeper


No, some people are a lot more productive across broad range of tasks. Often they are assigned tougher/critical stuff though because it doesn't make sense them do trivial tweaks.


Ensuring people work on what they are comparatively best at is a feature. 1x engineers would also get a lot less done if they had to clean the toilets and sweep the floor and many of the other low end tasks others do, instead they assign people who cost less to those tasks.


That’s argumentum ad absurdum though. There may well be people that are useless in a given profession, my point was not about that. My point was that 10x occurrence should be analysed within specific project, work division within the team, etc. For most 10x programmers in a project it does not guarantee repetition of 10x on a different type of project or problems. Matching problem with a team member and ensuring he has a chance to become 10x at it is something that good managers do.


Isn't it insane that there are many 10x engineers who have created enormous amount value (creating patents, leading and executing projects, innovating etc.); Yet, the world will only know about the company or the CEO and never the engineers behind it.


How do you expect the world to know about the others? The CEO is public facing by definition of their duties and the charter. Any other public presense from the organization technically falls under marketing of some sort, even teaching useful generic skills for free (say a publisher promoting literacy in third world nations) is in service of this.

It requires looking into arcane details to know about the engineers behind it. I mean software, especially media productions often include outright credits but few would remember any but leads usually. Precise attribution would get downright absurd in a pure data sense to give coverage that few care about. Say for just a simple who tightened the screw on this part of the cloth mill during its production run, who made the screw, who farmed the cotton, made the irrigation means....

Replicability and productivity atr what leads to technical obscurity ironically - because the automation and scale means fewer people are even in the position to know what to even ask about the details relative to the numbers served. Thus the knowledge remains arcane. Not many people would even know say, that DRAM tries to minimize capacitance and inductance but it needs some of both to function. Let alone who was involved with what subsection of the chip design and design testing process.



The trick is to be a 10x dev and work 0.2x of the time, remotely of course. Everyone thinks you're decent and you get a full salary working 3hrs per day.


Not only are there 10x engineers, I personally know an objectively measured 500x engineer. He is humble because he knows someone who produces 10x what he does (albeit spending twice as much time at it).

The measurement happened as a result of a joint venture between Siemens AG and Ericsson called Ellemtel. Each company sent 250 [edit: not 500] engineers. It was a six month project, the classic death march: if it did not deliver on time, the parent companies would not be paid.

At the end of the project, half the code delivered was his. Had he not been on the project, it would not have been completed on time, so no product would have been delivered. [Edit: Thus, it is not really the line count that makes him a 500x engineer.]


> I personally know an objectively measured 500x engineer. He is humble because he knows someone who produces 10x what he does (albeit spending twice as much time at it).

So your 500X engineer knows a 5000X engineer and he wrote as much code as 999 other engineers combined? (That would make him a 999X engineer, FWIW)

A 500X engineer (per your measurements) would have to write 500 lines of code every day without fail, while all 500 other engineers in the entire company could only average 1 line of code per day. And the 5000X engineer they know would have to write 5000 lines of code per day while everyone else was only limited to 1 line of code per day.

Not just one day, but every single day for six straight months. And all of their managers would have to somehow not notice this disastrous situation for the duration of the project. Come on.

I think you've been fed some exaggerations.


Measuring programming progress by lines of code is like measuring aircraft building progress by weight.

- Bill Gates


And I bet an in progress airplane that weighs a 1000lbs is further along than an airplane that weighs 1.


Not if they have the same wingspan; the "1000lbs" airplane is 0% done because it will never fly.


What were you trying to say? You realize a Boeing 747 weighs over 400,000 lbs. And a tiny Cessna 172 weighs ~1500 lbs.

If the planes have the same wingspan, it's likely they're in the same class, and weight is a perfectly reasonable measurement of completion percentage.


A 450-gram partly completed airplane probably has a wingspan of about 1 to 3 meters. If you have a partly completed plane whose wingspan is of about 1 to 3 meters, and it weighs 450 kg, it will never fly. You need to redesign it. Otherwise you have a rocket, not a plane (and there's no guarantee that it's a working rocket).

Maybe, in exceptional cases like the Gossamer Condor, a 450-gram partly completed plane might have a larger wingspan, like 30 meters. With enough thrust and wingspan, you can definitely get a plane weighing 450 kg to fly (or even one weighing much more, like your Boeing 747 example). But if your Gossamer Condor competitor is partly completed and weighs 450 kg, again, you are going to have to redesign it, because a bicyclist will not provide enough thrust to keep it airborne.

If your Boeing 747 assembly is running behind schedule, you probably cannot catch up by adding more ballast to the wings, or prioritizing ballast over riveting, even though lead or DU weights are quick to install, and rivets do not weigh very much. X-ray inspection doesn't add any weight to the airplane at all, but it's the only way to find certain cracks. If your Boeing 747 weighs 500 tonnes, that does not mean that it's a super-complete plane. It won't be able to take off.

So, no, weight is not a perfectly reasonable measurement of aircraft completion percentage.


sure, because they are measuring progress towards completion, rather then the ability to fly

i.e. if a finished plane weights 10,000 lbs all put together, then a in-construction plane currently at 1000 lbs is clearly further along towards completion then one at 1 lbs


Note this applies to the manufacturing,not the design.

It is actually a wonderful analogy with software:

* to a first order, cost of the materials in an airplane are proportional to the weight * at design time, the weight of the aircraft is minimized. thus, political and management forces cannot change it.

just like software, each subsection that is bolted on has different weights; but if you average it out it is a good measure of progress. and cost.


And if I build a paper/balsa wood airplane that's 1 pound and can carry a mouse?

It all depends on what the actual "airplane" (product) that's being built is.


It's a nice aphorism, but it's a very bad analogy. Before the build of an aircraft is started, the target weight of the assembled product is (roughly) known. Therefore, in the process of building an aircraft, the assembled weight at least goes up from 0 to $target -- in an erratic fashion, but it's still a continuous measurement.

I have never seen a program design specification that even attempted to quantify the lines of code of the end product, let alone be accurate.


The initial comment was related to attribution for "who built" some piece of software based on lines of code. The analogous argument would then be assigning attribution for the built aircraft to whoever produced the heaviest components. Given that that would be illogical, I think the analogy is apt.


The person who told me about this was the person who counted up the code at the end of the project. And, yes, it was 250 from each, not 500 from each parent company. (Memory is funny that way.)

I do not doubt that the numbers were rounded for simplicity. It is meaningless to talk about a 499x engineer.

As was explained to me, this engineer assigned two-week work units. If the work was not ready at the end of two weeks, he wrote it himself over the weekend. So, a fair bit of code was written that did not make it into the final product.


That's a ridiculously wasteful way of managing work. I too can be a 10000000x engineer if I never let others actually merge their code and just write it myself instead.


If you hired engineers like they hired them before coding interviews combined with a decade of the dead sea effect I can easily see a team of 500 barely getting anything done at all. Big organizations are often grossly mismanaged like this which is why smaller organizations can beat them.


mismanaged, yes. But also risk-adverse and encumbered with process. At a big corp you may need 5 or more sign offs on a single merge. I probably spend a good 40% of my time herding cats and babysitting the merge pipeline. There is a lot of overhead you simply won't find in a startup.


It was a way that delivered product on deadline, for exactly that project. Every project has specific needs. If you code to some other project's needs, you do the wrong thing.


> If the work was not ready at the end of two weeks, he wrote it himself over the weekend.

Using no code or knowledge from the past 2 weeks?


That would have taken longer.


Using it or not using it would have taken longer?


Trying to use somebody else's code that does not solve the problem generally takes longer than writing it yourself.


Solving a problem isn't all or nothing.


For it to matter, it is.


Nonsense. A house without electric outlets and switches isn't ready. It's much closer to ready than empty land.


But looking at someone elses code first generally makes you faster even if you end up not using any of it.


For any positive real number X and employed engineer A with positive productivity, I can find an employed engineer B where productivity of A is more than X times the productivity of B.

Proof: Pick B to be an engineer with productivity 0. 0 * X = 0 for all X. Productivity of A is defined to be positive, so is greater than 0. Hence productivity of A is greater than X times the productivity of B.


And then there's people with negative productivity.


I remember a day when one of my engineer's full days of work was one line of code. Not all lines of code are made equal


And, not all projects are death marches. It is generally hard to measure value, which is one of Dan Luu's points. Counting lines of code rarely produces a very good answer, but sometimes that is the best you have. Company revenue can be meaningful. When a contribution that makes the difference between $X million revenue and $0, against 250 years worth of engineers' salaries, it is hard to quibble. 500x is as good a number as you can get.



By measuring productivity on lines of code written you show just how inexperienced and naive are.

Are you HR, by chance? Have you ever coded something in your life?


The multipliers are all relative and seldom in simple metrics such as lines of code. If you wanted to inflate the numbers in a technically truthful way stick in a complete novice capable of preparing (so they are not negative) but not prepared for a complex field so their multiplier will be low. Use them as your 1X and even burnt out and demotivated employees who don't stand out could wind up performing 50x relative to them.


You don't measure code by the number of lines written, you measure it by amount of productive value. Early engineers at Google were easily 500x ( keep adding more zeros if you want ) more valuable to google than a random swe today


If you thought this was about lines of code, you were not paying attention.


LoC is a terrible metric - did they count the lines other engineers removed?

I was half of a very productive duo on a greenfield project subsystem - a project I joined midway: my partner wrote a lot of code, I estimate ~70% of final lines in the code base were his. What the LoC count won't tell you is all the refactoring, deletion, tests and error handling code I had to add, because his code only worked for the happy path. Can you say he was being 2x more productive than I was? I say no, because he was breaking the nightly build at least once a week before I joined, blocking the rest of the team, this ended when I added pre-commit tests.


When the numbers are large enough, the details don't matter much. Maybe he is really only a 250x engineer? A 100x engineer? It doesn't change the fact that without him no product would have been delivered.


> It doesn't change the fact that without him no product would have been delivered.

I agree. I'm only arguing that there are times when engineers who enable "10x/100x" engineering don't get the visibility they deserve, sometimes until after they quit.

This hits close to home for me as I witnessed my partner being showered with praise for being "super productive" based on LoC alone, code which wasn't close to being production-ready. If you don't care about code quality, and want to be seen by management/people outside of your team as a 10x engineer with minimal effort: you can follow the same playbook.


Agreed. It is rare that you can get objectively meaningful numbers. So, while it is convenient that half the code delivered was his, that is not the meaningful measure.

When I was in school, the standard for engineer productivity was 10 lines of tested code per day, averaged. Maybe we do better today, with fewer footguns and faster compilers. But we expect more meaningful results from a line of code, too.


no, no, no, no.

if you deliver the product only by taking shortcuts that impede other engineers you do not get credit for ‘delivering’ the product.

having been the next engineer to come along, this attitude drives me up a wall.


This really isn't my experience with super productive engineers. Usually they're solving high level technical problems for the company that most employees wouldn't touch with a ten foot pole. It isn't the raw LOC they produce but their ability to translate complex technical problems into elegant solutions for everyone else to take advantage of.


The Death March is not a usual circumstance. In usual circumstances, different practices are indicated.


Maybe he was an amazing engineer 100s of times better than anyone else on the project...or maybe he was a bottleneck for everyone else.

The latter I've seen. A lot. The former I have not.


Not having seen it does not mean it does not exist. I have seen it more than twice. I hope to see it more times.

I have also seen -10x engineers. Generally the best you can do is stay well clear.


I'm not saying it doesn't exist. I did say 'maybe' after all.

I am also implying the likelihood of it being that, rather than from a particular perspective an organizational detriment looks like a personal positive (somewhat akin to the 'heroic' team constantly responding to pages in production for their services; not like that lazy team that only works 8 hours a day and never gets paged), seems low. As mentioned, when one person seems to be doing all the work, yeah, it might be they're just amazing, or it might be that the project is badly managed, and so the work can't actually be distributed well. Both can also be true.

I too have seen -10x engineers. Interestingly, others in the company also saw them as +10x. Someone who was the silo for a notoriously difficult part of the system was viewed by management as amazing (after all, he just went and got things done! They could focus their attention elsewhere!). When I then had to dig in, with actual production requirements, I found nothing really worked, nothing was designed well, nothing was documented, and the person was impossible to work with.


Assuming you can objectively measure someone like this, either by LoC or delivery times, this is the wrong way to approach any project.

Having a 10x engineer(or even worse, a 500x engineer in this alleged case) is a huge risk for the company, should the engineer want to leave or if they are incapacitated in a tragic event, the company is severely handicapped, ideally a so-called 500x engineer should spend less time writing the actual code and instead mentoring/managing others to scale up their knowledge, should the company do this right, they might not deliver on time, but they'll have a much wider array of experts when something breaks or for the next projects, reduces overall company risk and it's more profitable in the long run.


Yet, they in fact delivered and got paid, and (pay attention!) would not have delivered and not got paid, otherwise. Risk is speculation about the future. Here we have full benefit of hindsight, and the choice taken was manifestly correct, despite all counterfactual speculation.


It’s incredibly reductionist to think that productivity is inherent to an individual when the world is never that simple and there are always a lot of factors involved in any outcome. Even the people that you think are “10xers” will stumble under the right circumstances, and the converse is also true about the people you think are incompetent.

It’s not so much that we built a culture that disallows these things to be said—I’m sure you have the freedom to say that to people if you’re prepared for the consequences. It’s just that it’s such a hasty, unnuanced thing to say, and business decisions should not be made on the basis of rash remarks that aren’t very well thought-out.


I remember finding a site (a design patterns repository page of all things) that explained the nuance of different people having different expected outcomes on different domains well.

But despite searching for it for years I haven't been able to find it again - web searches tend to be bad at finding things that you found before, again.

Anyway, this was described as the "movie producer pattern" (maybe it was director)

I remember it going something like this:

As opposed to the factory worker pattern which describes people who perform simple tasks that are straightforward and are easy to learn and perform and are hence interchangeable, it is more accurate to use the movie producer pattern.

A producer will have shown his or her abilities in a specific set of movies, each with a certain style and genre, which will lend credence to their ability to perform similar work in a similar genres. It's clear however that the specific director will make a large impact to the final movie and will have a personal touch.

For engineers, Susan, who has spent the last decade honing her skills on language VM implementations is expected to be an all around star resource, but would probably be a more trustworthy choice for more VM work as opposed to implementing a graphics engine or database.

(In analogy to a director with a string of science fiction movies who might not be the best choice for a romantic comedy)


> It’s not so much that we built a culture that disallows these things to be said—I’m sure you have the freedom to say that to people if you’re prepared for the consequences.

When people say that "you aren't allowed to say" something, they don't mean the government uses magical mind control rays to prevent your mouth from physically producing the words. "Consequences" are the mechanism by which speech is prohibited in societies without access to magical mind control rays.

(Not to pick on you specifically; I've heard this line a lot lately.)


I mean, I get your point about the government but now you’re just complaining about how being insensitive to other people has the consequence of them fighting back.


Now you’re moving to assume that everything that has consequences is due to somebody being insensitive. It could also be, for example, that the person initiating consequences is entirely too sensitive.


So you’re gonna go around the office to point fingers and tell on people that they’re not 10xers, and then call them too sensitive if they react? You’re talking in abstracts but if you put what you said in context (ie this discussion) it doesn’t make sense.


> So you’re gonna go around the office […]

This discussion is not about me, nor did anyone advocate that behavior. You are making up scenarios in your mind about what other people in this thread are thinking and saying, but these things are all imaginary on your part.


> Even the people that you think are “10xers” will stumble under the right circumstances, and the converse is also true about the people you think are incompetent.

Right, the 10x engineer isn't benching 10x more than you or running 10x faster than you, nobody thinks that 10x engineer means 10x at every possible task.


Nah, it's beyond that. I know a dev that is the most brilliant ux dev I've ever met. He can create beautiful, dynamic, understandable UIs literally 20x than I can.

However, he is just medeicore at must other tasks- constructing a common data model, scaling the backend or analyzing the data be is slower than I am, if he engages at all.

More recently I told my manager that I was intimated by how effective one of my coworkers was at his job (data science and BI.) He laughed and said my coworker basically thought the same of me (doing more standard software engineering.

Highly effective engineers are often only effective at limited aspects of the business of software engineering and it takes a good team structure of diverse talents to make everyone effective, even in the domain of software.


That was my point, arguments such as yours are just arguing with strawmen. 10x is compared to another professional in the same domain. Saying that the engineer isn't as effective at another domain as a professional of that other domain is arguing with a strawman.


It's not really a strawman considering it's EXACTLY what most companies are trying to do: make programmers fungible across domains. Critically; they're doing this because they typically have no visibility into these skillsets from the managerial level, and they typically only have one or two programmers "in a given domain" on a team - even in a very, very large company. The company would like to pretend these people are fungible, and can be interchangeably swapped out, but the reality is they have no immediately replacements on the team.

There's no sense in doing an apples-to-apples comparison when you've only got one apple, an orange, and a pear.


But then you have to ask what metrics are being used to define a 10x engineer. You’ll see that everyone has a different version of that and therefore whether a 10x engineer exists solely depends on the ontological argument for a 10x engineer. By the end of the day 10x is subjective because teams have different needs.


If you can replace an entire team of 10 engineers paid to work on something with a single engineer then that engineer is a 10x engineer, as long as the "10x engineer" didn't originally write the things they work with. That is my definition.

> By the end of the day 10x is subjective because teams have different needs.

Replacing 10 salaries with 1 salary isn't subjective at all.


Of course it is subjective. This is literally what you said:

> That is my definition.

You obviously care about optimizing for salary expenses. Most companies have room to hire more people who can do a few things well, so their definition of 10x would be different because they’ll have different expectations of their employees.

And really, if your definition of a 10xer is some poor fool who’s willing to take the job of 10 people for a single person’s salary, good luck finding someone who wants to spend their lives living that way.


> And really, if your definition of a 10xer is some poor fool who’s willing to take the job of 10 people for a single person’s salary, good luck finding someone who wants to spend their lives living that way.

Right, they are paid more. The going rate for good people is around 1.5x up to 10x for exceptional cases.

Edit: And I am not talking about minimizing cost of salaries, I am talking about how much a good software engineer should demand. If he can replace 10 salaries with one then he has a lot of leverage he should use to get a higher salary, if the company isn't paying him then he should leave for a company that appreciates his skills. Plenty of companies pays premium money for premium talent.


I mean, if all you’re saying is that “better programmers deserve better pay”, then you’re not exactly saying anything groundbreaking and the concept of “10xer” is not going to be necessary to make that point. It should also be noted that the salary that you get isn’t just a product of your talent but also of how well you sell yourself. Amongst many other factors, of course.


Salary isn't just a factor of skill, but willingness to pay high salaries is the same as belief that skill matters a lot. A manager who doesn't believe in high developer skill variation will not pay significantly above market rate, while a manager with strong beliefs in skill variation will pay huge amounts for the right people. Therefore I see any arguments against 10x developers as an attempt to supress wages, likely managers who wants to hire good developers without paying them more than average developers, or developers who are jealous of others salaries. Luckily a lot of companies acknowledges that talent matters a lot and pays a lot for it, and today the highest valued companies in the world belongs to that group.


So y’all don’t disagree with the main point.

There are some specific individual engineers who will get a specific individual task, faster than some other specific engineers.

If those same specific engineers get done many general tasks faster than another group of specific engineers on general tasks than they are just better in general. If some other specific task gets done by the other specific engineers better then it is just different domains.

Either way the individuals matter.


So a fast programmer is necessarily better than one who takes a little more time but pushes out stabler code?


Touché, same quality just one done twice as fast let’s say. Just a hypothetical.


> will stumble under the right circumstances

Exactly. Not every task or goal fits every person equally well. A good leader understands this and does their best to find that fit.

But it is in my experience not considered okay to talk about this too openly because people get offended.

You wouldn’t ask your best engineer to lead a marketing campaign or your best marketer to design your servers. They’re smart and would figure something out eventually, but who gets the task matters.


The irony here is that the point of the article isn’t that “10x engineers” do/don’t exist, it’s that “things are more complicated than that”.

Assigning arbitrary labels (like 10x engineers…) so it’s “easy to understand” results in over simplified models that lead to faulty decision making based on invalid assumptions.

…treating everyone equal is perhaps also a faulty assumption, but it’s easy, and dealing with complex systems is hard.

Maybe instead of bitching about equality, which is just a symptom, we should promote using complex models instead of easy trivial ones.

…because just using different easy trivial modes is stupid; it won’t get you any better outcomes.


"10x" is still treating people like cogs, it's just having cogs of different size.


I like being treated like a cog instead of playing pretend-games of making me feel like a unique flower (but truth is still that I’m a cog). I prefer honesty. I prefer the brutal, unvarnished reality over executive bullshit.

A cog means I have specific responsibility and I will make sure I don't hog down the entire machine. I work well with other cogs - we mesh perfectly. Being treated like a daisy with beautiful narrative of lies would eventually lead to a delusional state of mind, dissent and ultimately negative spiraling burnout.

Former is peaceful, the latter is deceit.


But one of you really is a daisy, people are not equal, and those daisies are actually what's responsible for most of this machine and it's origins in the first place. Without daisies there will be no place for cogs, the cogs come after the daisies


Even if there aren’t 10x engineers, there are still engineers with different levels of skill and knowledge in different areas.

One of the best engineers I ever worked with was terminated (he was a contractor) as he spent his career on the backend, was told he would work on the backend, and they assigned a complicated React feature to him over his objections that he had no knowledge of the framework or frontend dev in general.


HR didn't care that the person made the company more money than HR saves by doing location adjustments for all international employees combined because HR at the company had no notion of the value of an employee, only the cost, title, level, and location

This is common in large, dumb corporations: HR is the Blob. And if you are being recruited by a company that exemplifies that kind of culture, run away, far, far away.


A 10x'er is by definition an outlier. It would be absolutely silly for a business to build its planning on the existence of outliers in its staff, unless the company is small (< 20) and that individual is a co-founder or someone you can really rely on.

People leave companies for other opportunities even when they like their current job. I have to plan for that, whether it hurts someone's ego or not.


Isn't the "10x" label contingent on engineers being functionally indistinguishably, except some are allegedly 10x more productive? Specialization is what I figure has highest impact on turnaround times in a team setting. Just because an engineer is the most familiar with a component/subsystem - which allows them to make changes to that subsystem faster, doesn't make them an all round 10x engineer.


IMHO it's also an useful illustration that being able to replace people is asymmetric.

It may be that Bob can do Joe's specialization at half speed, but it's plausible that Joe can't do Bob's specialization properly at all, even after a year of training; so replaceability only works one way.

And I have worked with engineers that could do improvements to an unfamiliar component/subsystem faster than the current engineer who is the most familiar with it; i.e. their time of learning+adaptation+implementation was faster than the other persons' implementation alone. And it's not that the other engineer was incompetent, they were quite reasonable.


It refers to people with the same experience with the system. For example, lets say you have two persons working with a system and have worked with it for two years. One of them is 10x as productive in that system than the other. Neither of them had experience with such systems prior to this, so both were equally productive when they started, but one of them grew much faster and is now 10x the other.

Of course if you took those two and put them to work at a new system both would have 0 productivity initially as they learn the new system, but as they grow the differences starts to appear and soon you have a very stark contrast again.


I'm "10x" when working on one part of the system that I'm extremely familiar with but "1x" when it comes to other areas. Similarly, I have teammates who are "10x" in those other areas but wouldn't know where to start when it comes to my specialty.


You make it sound like you shouldn’t get credit for knowing where you provide the most value and putting yourself in position to be most effective. :)


What you cannot say is that there are 0.1x engineers.


In my experience there are plenty of -10x engineers.


That's acceptable if they're interns/juniors. If you only hire the best people for the job, you're never going to get any new people.


1x is defined as the least productive engineer in a team. But I know what you mean. Sometimes a team can be more productive with fewer people.


Maybe a mix of x0.3 and x3 engineers.


> But we’ve constructed a corporate culture where this is not allowed to be said. So we bend over backwards to pretend everyone is equal and capable of the same things in all areas. Then we secretly make sure somehow by magic the truly critical projects are routed to the people and teams with more reliable outcomes.

Do you really think that was the motivation? That someone is going to bat for Bob at Alice's expense?

Or do you think it more likely that "equality" is another way of saying both Bob and Alice will never threaten someone in management enough to cost them even a minute of sleep on any given night, and that's all management really cares about at the end of the day.


> But we’ve constructed a corporate culture where this is not allowed to be said. So we bend over backwards to pretend everyone is equal and capable of the same things in all areas.

http://www.tnellen.com/cybereng/harrison.html


This is pretty much exactly true. Though I must say being a person who comes in and get plonked on the underperforming team. It'd be really progressive if the Alice character had to take on some fresh blood to share around the knowledge and let new people build rep. Nothing sucks more than being on an underperforming team.


It may be a culture thing, but across the three companies I've worked at every estimate has been explicitly assuming a specific person handles it. Sometimes we've even given several estimates for the same task depending on who it gets assigned to. No one has ever found this odd. It's just obvious that different people have different skills and familiarity with different technologies or parts of the project.


There's no need to be offended either. I will gladly estimate a task taking longer for me to do when I'm not the original author or would be using languages and frameworks I don't have much experience in. We just give the estimates and let the PO prioritize what they want.


That's brilliant. So much bike shedding about what complexity a task has could be avoided.


This is how planning should be done. Gauge people's expertise, put them on the path they can be most effective and then ask for their estimates. Take that to upper management and negotiate.


One problem with that is sometimes the estimates are done long before the work starts so when that item eventually gets to the top of the priority stack the person estimated for is working on something else instead. At this point things need to be re-estimated which can cause friction if the new estimate is longer (“but last time, you said…” or “when we asked Bob, he said…”).

What I've done in the past is give an estimate based on what a “standard” dev can be expected to do (everyone understands a junior is expected to be slower as they are new, that is why they are currently a junior and when they get up to speed they'll be promoted) with a comment on the ticket that the expected time will reduce by × if a named resource, or one of a group, is available to work on it. That way, medium term planning can be done on the basis of a “reasonable case” scenario and if the right people are available things will go better (and if there are multiple items in that state, short term planning will include deciding which ones being sped up, by using that person's time, confers most extra value).


Right, things are always probabilistic when it comes to us Humans :-)

I like to think of it like Algorithm Analysis; Best-Case (estimate by the expert mentioned above), Worst-Case (estimate by Noob who just joined the project) and Avg-Case (estimate by person who is already part of the project but is not responsible for that module). Add a fudge factor based on your reading of the circumstances and then haggle with Management. You now have a band with a upper bound and lower bound which can be realistic.

PS: You may find Douglas Hubbard's How to Measure Anything: Finding the Value of Intangibles in Business useful in this regard.


> things need to be re-estimated which can cause friction

But, but ... isn't every estimate supposed to be provisional? Aren't you supposed to be re-estimating regularly?


> But, but ... isn't every estimate supposed to be provisional?

Heh, no. It is an estimate when you are making it, but ten minutes later it magically becomes a commitment.

"Tasks like this usually take two days, sometimes one or three, very rarely more... so, two days on average."

"Okay, I am writing down: two days."

...two weeks later...

"How it is possible that the task took three days when it was estimated at two? You made the estimate! And you all were there at the planning, and no one said anything! As senior developers, you should make better estimates, this is unprofessional."


In an ideal world, yes, especially if requirements/scope/environments change. But the world is often not ideal. Often unless there is what they see as good reason (the definition of good may vary widely), managers & business planners don't like estimates going up in the short/medium term and pressure to try stick to the original estimate may happen.


That's exactly what I was thinking of when I said we sometimes give estimates depending on who it gets assigned to. "It'll take a day if X does it, but probably three if another SE does it".


In my manager days I simply assigned a factor to each team member based on the type of work, so one person may be baseline hrs * 1 and another hrs *.8

This had to be accurate, as it’s consulting, if the hours are wrong we lose money.

But only a direct line manager can do this, anyone else won’t have the knowledge of the staffs capabilities.


it's even more complicated by knowledge/experience in certain areas.

Fire me into some unknown terraform and I'll be able to orient myself faster than someone who only does C# every day.

Send me into my own terraform and I'll be faster still. Not all things are equal.


It's not even necessarily about skill, could easily be that someone is already spearheading a higher priority or whatever.


The best teams I've ever worked with, that were the most productive and also had the best team work and team spirit, was when we assigned tasks in planning. And gave the tasks to whoever was most suitable to work on it.

Unfortunately we were never allowed to do that, because of Scrum, and were only able to do it on the low down for a short time until management cracked down on it and enforced "anyone who happens to be free works on whatever is on top of the backlog".


> Unfortunately we were never allowed to do that, because of Scrum, and were only able to do it on the low down for a short time until management cracked down on it and enforced "anyone who happens to be free works on whatever is on top of the backlog".

Ironically, this (what the management did) is completely against the rules of Scrum... in theory.

But it is what management typically does when they are doing "Scrum".


I "enforced" this as a manager at my last position. But I quoted the word "enforced" because this wasn't something I had to argue with anyone.

I understood that it meant things might take a little longer, but it also meant that everyone on the team (which was small) would get exposed to all of the code we worked on. Specialization means speed, but it also means a lower bus factor.


I got around this, specially around 'planning poker' when I got to be lead in these scenarios that forced you to do it. Whenever there is a discussing on how long something should take, whoever says the least amount, is tasked with the job. After 1-2 of these meetings, amazingly, all estimates started to come back quite higher than before.

I still believe that whoever takes the task, should be the one deciding how long it will take, and only after understanding the scope of the work. Planning poker is the most useless piece of shit I ever seen, and still, it is used all around by idiots. If I am asked to estimate something, I will always give the highest possible value and justify with "I don't know enough about it to estimate". If I am managing and I have a top down force pushing for this, I will always make sure that the stupid process is obvious how fucking broken it is.


The original idea was that "planning poker" should estimate the tasks in "story points", which are absolutely NOT supposed to correspond to days. It is just a way of saying "it seems like the task X will require twice as much work as task Y". Some teams do not use numbers at all, and estimate stories in "t-shirt sizes": S, M, L, XL, XXL.

But of course, most companies want to have their Scrum and micromanage it too. So they estimate in days, and call them "story points". Or sometimes they don't even bother to pretend, and estimate directly in days.

(So, how can you estimate how much gets done during the sprint, when all you have is the "story points"? You keep the records from previous sprints, and see how many "story points" got done back then. Adjust the number if someone takes a vacation, etc. This is self-correcting in long term: if someone starts pushing developers to estimate low story points, you will see that fewer story points get done per sprint, so your estimates of how much work gets done will remain correct.)


In my experience it still makes sense to estimate together using the same story points (or T-shirts) when there are people ranging from almost no experience to very senior ones working on a project.

1 SP for a senior may take 1h of his time and for a junior that would be 2-3 days but it's still 1 SP - a relatively simple task. This is in contrast to a fallacy of recalculating SPs to time-based units cause if we do that we might as well just estimate in hours/days.

It's about agreeing on some baseline first (what does 1, 2, 5 SP task look like?) and going on from that. We just need to remember that velocity will be different for different people so team capacity calculation is going to be all over the place but I think this approach can be useful.


This comment made me laugh because it’s so delightfully insightful. You are absolutely right and I’ve never thought to pose the question.


Whenever I ask an expert how long it'll take someone new to the their code base to add feature Y, I mentally double whatever estimate they give and share _that_ instead.

I haven't overshot the estimate yet.


I am a security engineer but have been a business leader from time to time. Business leaders often need to plan around dates- eg ”should we spend $50k announcing at conference Y in month Z, or should we wait until month A?” “Our competition just launched; will we be able to launch this quarter (the board wants to know, and we have to report material financial impact items quarterly or face SEC fines)?”

Every team I have ever worked with hates planning; every team hates their methodology and thinks it’s stupid and inaccurate and why are those pinhead business people insisting on a date; it’ll be done when it’s done.

One of the primary jobs of managers at all levels is to plan and then execute in accordance with the plan. Some managers are good at it, many aren’t- the world is populated with people nearer the center than the ends of the bell curve.

So show me a methodology that mere mortals can implement successfully. If all you can do is complain and point out unicorn 500x engineers (yeah try hiring for that characteristic, good luck), then I don’t want to hear it. But if you have a practical idea on how to “solve” planning, then you have my full attention.


> So show me a methodology that mere mortals can implement successfully. If all you can do is complain and point out unicorn 500x engineers (yeah try hiring for that characteristic, good luck), then I don’t want to hear it. But if you have a practical idea on how to “solve” planning, then you have my full attention.

TFA doesn't suggest hiring 500x engineers, it suggests taking steps to retain highly effective engineers (and highly effective teams) by not ignoring the evidence that they are not fungible.


A point the article also alludes to: often people are only “unicorns” due to the specific context they’re working on. Move them to a different project, and your high value person may be a net negative. And it’s not possible for people who aren’t familiar with a person’s work to anticipate how making that person switch projects will affect the quality or quantity of their output.


I just went through this, like... today.

"Tell me what date task X will occur on." -- where task 'X' takes 5 minutes, but has a long list of pre-requisites that take 1-4 weeks each, sequentially, of which 100% our out of our control.

...

That's not planning, that's fortune-telling. You may as well ask an Ouija board.

Planning is making sure the the pre-requisites happen before you attempt to start the things that depend on them. It is making sure that everyone is unblocked. It is making sure that nobody is wasting time going down a dead end. It is making sure that everyone is rowing in the same direction.

What I see from PMs is that they just want facts from the future, instead of solving problems in the here and now.

Until today, weeks into the project, I could not access the system that I needed. This was the key pre-requisite for 4x FTEs progressing on their own tasks.

The only thing the PM did is repeatedly ask me if he needed to move the date for the completion ETA.

I solved the problem. He did nothing to expedite progress.

Does it really matter which specific date this occurred on? No. It just had to happen as soon as possible. The trick is to make it possible, not to try to pin down exactly when "soon" will occur by repeatedly asking the same question in every daily stand up.

Why do we pay these people, again? Remind me?


Like the parent poster said, people are on a bell curve. It sounds like you may only have been exposed to mediocre, passable, or plain bad PM's so far in your career.

So I'll remind you: the reason we pay PM's is because good PM's can, and do, exist. I've only worked with a few great PM's, but they outshone their competition with just as much brilliance as the 10x among us engineers outshine the 1x. It's ironic that you would reduce PM's to a single heterogeneous caricature in reply to an article that is essentially saying that it's harmful to do so.


Woops -- *homogeneous!


That was the glory of the good ole Gannt Chart in what I might call Microsoft Project Based Project Management.

If you set your dependencies right, the dates would just slip by themselves, and it was easy to tell the bosses what slipped. Required a lot of printing and taping every week, and caused a ton of headache whenever people lied about their progress, and didn’t really work without a FTE project manager, but I have yet to see a supposedly better system actually work better on big projects.


>One of the primary jobs of managers at all levels is to plan and then execute in accordance with the plan

"Plans" can never be set in stone. They evolve based on the people involved and circumstances. A Manager's job is to understand his people and then Plan accordingly; not the other way around.

>If all you can do is complain

This is exactly the wrong way to frame the discussion. Pointing out that you are clueless is not complaining but raising issues which if unaddressed, will most probably result in failure of what is attempted.


> "Plans" can never be set in stone

Setting plans in stone was the entire Waterfall Methodology where contracts had requirements and milestones locked in and any deviation meant heavy penalties.


Absolutely Categorically Wrong!

This has been so endlessly repeated without thought that people assume it is a fact when the Truth is far from it.

Excerpts from wikipedia - https://en.wikipedia.org/wiki/Waterfall_model ;

* In 1983 the paper was republished with a foreword by Benington explaining that the phases were on purpose organised according to the specialisation of tasks, and pointing out that the process was not in fact performed in a strict top-down fashion, but depended on a prototype.

* Royce's five additional steps (which included writing complete documentation at various stages of development) never took mainstream hold, but his diagram of what he considered a flawed process became the starting point when describing a "waterfall" approach.

* In 1985, the United States Department of Defense captured this approach in DOD-STD-2167A[citation needed], their standards for working with software development contractors, which stated that "the contractor shall implement a software development cycle that includes the following six phases: Software Requirement Analysis, Preliminary Design, Detailed Design, Coding and Unit Testing, Integration, and Testing.

The "Waterfall" is what is imagined as a "Ideal and Rational" process (see D.L.Parnas' paper A Rational Design Process: How and Why to Fake it for motivation - https://ieeexplore.ieee.org/document/6312940). The stages in the model and the issues to be considered in each stage are what is important NOT their order. In practice it was always a iterative spiral model described by Barry Boehm - https://en.wikipedia.org/wiki/Spiral_model


Maybe you've never done big government contracts.


Totally irrelevant and no Ad Hominem please.

FYI, D.L.Parnas and Barry Boehm defined the field of Software Engineering. Almost all Govt./DoD standards are based on their research and writings.


TIL: "Winston W. Royce's final model, his intended improvement upon his initial "waterfall model", illustrated that feedback could (should, and often would) lead from code testing to design (as testing of code uncovered flaws in the design) and from design back to requirements specification (as design problems may necessitate the removal of conflicting or otherwise unsatisfiable / undesignable requirements)"

https://en.wikipedia.org/wiki/Waterfall_model#Modified_water...

Interesting because that's definitely not what's taught in the handful of Software Engineering books I've read, and steps backward are not canon (rather, they're called something besides Waterfall i.e Spiral or Iterative).

Looking at that page again, it looks like what I describe is called "pure waterfall".


This is a good article on the topic http://www.bawiki.com/wiki/Waterfall.html


That is indeed a Great Writeup!

Instead of getting lost in the comments, You should post it to HN and invite discussions with a title like "Most of what you have heard about the Waterfall Development Model is Wrong!" or "How the Agile folks have misled you about the Waterfall Development Model" :-)


Most books on Software Engineering are mere compendiums with nothing much to recommend them eg. the texts by Sommerville or Pressman. Two exceptions that i know of are those by Ghezzi,Jazayeri,Mandrioli and Pankaj Jalote.


The first formal detailed diagram of the process later known as the "waterfall model" is often cited as a 1970 article by Winston W. Royce. However he also felt it had major flaws stemming from the fact that testing only happened at the end of the process, which he described as being "risky and invites failure". The rest of his paper introduced five steps which he felt were necessary to "eliminate most of the development risks" associated with the unaltered waterfall approach.

Royce's five additional steps (which included writing complete documentation at various stages of development) never took mainstream hold, but his diagram of what he considered a flawed process became the starting point when describing a "waterfall" approach.

https://en.wikipedia.org/wiki/Waterfall_model#History


Not when I have done waterfall - each waterfall phase can iterate


Show me a Software Engineering book that calls Waterfall that can iterate "Waterfall" rather than "Spiral" or "Iterative".


There is a big difference between the stages involved in "Waterfall Model" and the various techniques of combining, using and transitioning from one stage to another.

"Waterfall" specifies the What while "Spiral and Iterative" specify the How.


This mentality of thinking is exactly the problem, I think. You want a tool that can solve an entire class of problems. We are telling you that no such tool can exist to do what you want, the problem and the tools don't work that way. Each project should be planned as a snowflake. Each project is different. Each team is unique. Every individual performs differently, even one day to the next. Stop looking for this tool to make these plans. It can't exist.

Do the hard thing and plan projects individually.


>This mentality of thinking is exactly the problem

Damn right!

>We are telling you that no such tool can exist to do what you want

This is exactly right and is the biggest problem with "Management" types. They want a "cookie cutter methodology" to solve all their problems so they can be spared thinking through each one. Hence the various "Management" fads and buzzwords.

The core of the solution lies with the Individual; understand their needs, wants, motivations, practice "Empathetic Management" and you will be successful.


Leaders may need to know some specific dates for some specific purposes. Responding to that need by demanding your methodology deliver a schedule for everything in case you need it is lazy and wasteful.

If your engineers are part of the same team, working on the same business goals, they'll be glad to contribute what you need to the decision about whether to announce at conference Y, and may even be able to suggest relevant aspects you haven't thought of.


> So show me a methodology that mere mortals can implement successfully.

Commit to a deliverable or a deadline, but never both.


I would say an approach closer to the Heisenberg uncertainty principle would make more sense. The more information specified that can't be changed about the expected product the less information is available about the deadline, ans vice versa. Thus, the desired balance could be used depending on the situation, goals, budget, etc.


That was briliant and is already added to my quotes list.

Should I attribute it to xvilka or did you get it from somewhere else?


I think, it's my own idea but you never can be 100% sure, some kind of uncertainty always persist.


I'm not all to familiar with this kind of thing so I could be missing something, but what is a deadline without a deliverable? Surely "We will do something (literally "something", not a stand-in for X) and it will take a month" is worth nothing?


I worked for several years on an extremely large and popular sports news/results website, meaning all our deadlines were absolutely set in stone by the outside world – sporting events start on specific dates. The Tour de France sure as hell ain't gonna postpone a few days until we've finished our team profile pages.

So we committed to a deadline, but not a single deliverable. Scope would shrink and grow as delivery of each component progressed. Well in advance, for each major sporting event in each country where we operated, we would scope out literally every single thing we'd like to deliver, and then start work on the components in priority order. In each planning session as the event approaches we'd appraise whether we still have time to realistically deliver the next priority thing, and if not we'd skip it and move to the next - those that got missed out could wait until the following year (when the major features already delivered would need to evolve, not be implemented from scratch).

I learnt a lot from working on sports. Having third party deadlines that no-one could bitch about made us an extremely effective team at planning, estimating, and ruthless scope reduction.


You can have a fixed scope with a flexible timeline, or a flexible scope with a fixed timeline. If you try to have both, you'll incur an additional cost, which most companies avoid. It's a well known law of project management and software development.


“Ok awesome! Glad to hear you’ve committed to deliver widget, when do you think it will be done? We have four business units that were going to use wedgie but that’s getting decommed next year and they’d much rather avoid a pivot.

Oh and change restrictions start in six weeks, don’t forget that. BTW what’s your team’s vacation schedule looking like? We only get to roll over 7 days this year, hopefully they took some this summer haha!

Ok so anyway really would like some estimate that i can take back to product, you thinking January? Maybe get something up in test that they can kick around in what, a month?”

Etc etc.


"No."

It's remarkably powerful.


Stop using methodologies actively preventing any kind of planning (mostly agile stuff). Return to waterfall, write lots of documentations, spend time planning architecture, resist urges to rewrite non-ideal solutions. Do not allow changes.

It'll take more time and result will not be as clean.

Basically learn from older engineering disciplines.


The two replies below yours at the moment capture what you're trying to say...

> This mentality of thinking is exactly the problem, I think. You want a tool that can solve an entire class of problems. We are telling you that no such tool can exist to do what you want, the problem and the tools don't work that way. Each project should be planned as a snowflake.

> This is exactly right and is the biggest problem with "Management" types. They want a "cookie cutter methodology" to solve all their problems so they can be spared thinking through each one. Hence the various "Management" fads and buzzwords.

Which is another way to say... if there was a system to do their thing, they wouldn't have to pay smarter people a lot of money to do it. Reliance on a system (any system) tells you that the people don't value your expertise, but rather see you as a cost to be minimized.


Also, build several prototypes of every important part of the product in order to learn how long they will take to be made and how each variant will perform, so when you make estimations they are as effective as possible; and then, make integration tests on the selected variants so you can reduce estimation risks due to integration. Just as in every other engineering discipline.


I can't really speak about managment here, but when I organize projects the three most important things are:

1. Create the room for every member of the team to comfortably do their job (what this means depends on the persons needs and at the work environment, communication structure, tools you provide them). Room not only means physical room, but also time, frame of mind etc. If everybody has 10 other daily things on their list they won't have the (mental) room to work on the project.

2. Communicate clearly why you think this is a workable plan and ask for feedback whether this is realistic. Communicate what happens if you are faster, what happens if you are slower. They are helping you, you are helping them, ideally both sides take away something from the project beyond purely finishing it.

3. Adapt, Improvise, Overcome. The primary goal should always be to finish the project in a good way, especially if the deadline is not a hard deadline, but one arbitrarily set by someone else. Defend the team, create the room for them. Don't let them slack around too much. A bit of slacking around is not too much, but precisely the right amount – this is the space needed if something goes terribly wrong.


A technique I read once (and lost the link) was to track both the estimated time metrics and the error in estimation for every engineer. Over time you could build reasonable error bars around every engineer's estimations, and then sum the estimates _with the confidence intervals_ together and figure out the probability of achieving a certain ship date.


> A technique I read once (and lost the link) was to track both the estimated time metrics and the error in estimation for every engineer.

To do this you need to communicate very clearly why are you doing it, and if it will have any influence on performance reviews. But I do think that monitoring estimates in this way will affect the quality of estimates.

A manager in my previous company noted everyone's estimations during sprint planning in an Excel sheet. No-one knew why, so I found myself thinking more about that Excel sheet than about making an well-founded estimation.


That's what Fog Creek Software's FogBugz tried to do. I liked it a lot, it also allowed for some team structure planning (e.g. giving you a chance to see if your team consists of pessimistic estimaters or positive ones, and mix accordingly). Unfortunately, their marketshare got gobbled up by Jira.


I feel like pessimistic estimators are way more accurate and probably more intelligent than optimistic ones. I'd probably use software like that to fire half the team.

(edit: of course then I'd have to fire half the team again... and again... until only one or two incredibly depressed pessimists remained... tough call)


Why would you fire the team? The software shows you how their estimates relates to real world timelines, just adjust their estimate accordingly and the problem is fixed.

I never understood why managers get so upset over consistent time under estimates, just track it and add the relevant factor without telling the team and it should on average be on point.


I was sort of just reducing the idea to absurdity. I only work in small teams - everything I do is by feel. It's easy to tell if things are behind or not. Easy to tell if someone is wasting time, or if they're stuck on a problem, and extrapolate a new ETA. Honestly, the idea of trying to feed that into software seems heartless and inevitably wrong, but if I were going to do it, I'd opt for the pessimistic analysis.


> But if you have a practical idea on how to “solve” planning

Seems pretty straightforward to me - just don't use dates in your plans. That means don't announce features which aren't complete. Don't plan marketing campaigns for unlaunched products. Embrace "Now, "Next" and "Later" as headings on your roadmap. There are many successful companies that operate like this, Nintendo being a famous example. It doesn't seem to hurt their bottom line - quite the contrary.

The usual issue that folks have with planning is that business leaders are simply not willing to spend the resources to do it accurately enough to answer the questions they're asking. Think how much time it would take to break 6 months of work for several teams into detailed stories and estimate each one.

It therefore seems they're basically wasting everyone's time, since dartboards and magic-8-balls are just as good as engineering estimates without details.


> So show me a methodology that mere mortals can implement successfully.

There's an impedance between "Bob can do task of type A really quickly" and "we need to make sure that people other than Bob can do the task or else we have bus factor = 1 and this poses systemic risk". Clearly these goals are not really in conflict. In general, assign the work to Bob, but understand the effect on timeline in case Bob is unavailable. How long would it take if Bob isn't available? Is it worth the inefficiency from cross-training Mike? Is Mike even interested?

Modern militaries are not majority staffed by combat soldiers. Less than 10%. The rest are support of one kind or another. Smart engineering leadership in large companies, if they care about shipping on-time, eventually realize that roles like PMs are less effective if they understand themselves to be bosses and more effective if they understand themselves to be support staff.


> One of the primary jobs of managers at all levels is to plan and then execute in accordance with the plan.

Yep, just as I thought. This is why those teams hated plans - because once there is plan they will be beaten and abused to make it, despite the plan being unrealistic from the start.

> Every team I have ever worked with hates planning; every team hates their methodology and thinks it’s stupid and inaccurate and why are those pinhead business people insisting on a date; it’ll be done when it’s done.

In that case, teams in which you worked had stupid methodology about planning. It sounds like your plans did not accounted for uncertainty at all. They did not accounted for what if we are not making it, which features will be cut.

> Some managers are good at it, many aren’t- the world is populated with people nearer the center than the ends of the bell curve.

And many of them are abusive or exploitative about it and there is nothing in business organization to prevent or at least acknowledge that.


I'm really confused what this comment has to do with the article (not about planning) and why it's the top comment on HN.


A lot of my planning is making sure the most effective engineers are working on the most important things.

It is about making sure resources are most efficiently allocated to meet the business objectives.


I'd imagine the corollary to this is assigning each of them the task you think they're most suited to. I think that's what used to be called "management".


I'm speaking as someone who has handled a fair share of timelines (with reasonable success) you have pointed out.

To begin with, it is interesting to see you lumping up different kinds of timelines. For example, the cost of not meeting SEC timeline different one compared to demo to be shown in a press conference.

> should we spend $50k announcing at conference Y in month Z, or should we wait until month A?

What is it that you want to announce? Product launch perhaps? Then let's work with the product folks to design it and then take it to engineers to figure out work estimate. Give them time to estimate; if the timelines don't match then reduce the scope.

> Our competition just launched; will we be able to launch this quarter

Sure, they launched this quarter. Do you know how long have they been working on it? If not then it's a similar exercise as above.

> we have to report material financial impact items quarterly or face SEC fines

Why are you telling me this? SEC doesn't ask for such reports overnight. You messed up by not telling us so fine it is. OR there is some human at the SEC with whom you negotiate.

> So show me a methodology that mere mortals can implement successfully.

If there were such a methodology we wouldn't be having this discussion to begin with. It would have been commoditised, similar to a car manufacturing assembly line.

What business people don't understand (or internalise) is software is a truly a new beast. It is a tool that can be applied in just about every domain. No such tool has existed ever in human history. If you want to disrupt a domain then you either develop expertise in it or hire them from the industry.

> If all you can do is complain and point out unicorn 500x engineers (yeah try hiring for that characteristic, good luck), then I don’t want to hear it.

In some cases that is indeed the reality. If you don't even want to acknowledge the reality then good luck hiring good people. If you say point out how Apple launches products like clockwork then I'll point out how they have had close to 50 years worth of experience and all the associated optimisations they have done with their supply chain and what not.

Reality is, whether you acknowledge or not, is full of detail[1]. It can't be bent to your convenience, unfortunately.

[1] http://johnsalvatier.org/blog/2017/reality-has-a-surprising-...


> What business people don't understand (or internalise) is software is a truly a new beast. It is a tool that can be applied in just about every domain. No such tool has existed ever in human history.

That's not quite true: the inventions of mathematics, writing and especially affordable material to write on were probably even larger culture shifts, but software and computers are of the same magnitude - perhaps it's easier to realize the shift needed in corporate culture when you compare it to those earlier changes.


You can just give a random guess on the timelines and save the developers time.


This is cathartic to read, but I also despair at getting the people who need to hear it to take it seriously.

> But many people want the world to be simple

This is the source of so much insanity in the world, not just with regard to allocating labor. Details matter, but people who plan "timelines" desperately don't want to hear it. They can go through whole careers without being forced out of the cozy illusion that the world is simple. It's hard to get a man to believe something when his salary depends on it not being true, the market can stay irrational longer than you can stay solvent, etc.


> Details matter,

You are on the money[1]. People want to estimate work without even telling what is it that needs to be done in the first place.

[1] http://johnsalvatier.org/blog/2017/reality-has-a-surprising-...


Knowing what needs to be done is insufficient in programming too. You need to do careful archeology on the code base as well. Yes that code base you work on every day.


knowing what needs to be done is impossible without considering the means at hand.

It's not just wishing for a goal - a three year old can do that - but enabling to go the way there.

But a statistical estimate may be possible indeed.


There's a great book about this called "Seeing Like a State".


On that subject - I have read the original yet but I did enjoy this take https://www.ribbonfarm.com/2010/07/26/a-big-little-idea-call...


Weirdly I find "legibility" a little ... reductionist.

It's super-easy to identify the problems with e.g. Stalinism or modern China along these lines. The problem is that humanity is constantly failing in far more chaotic ways too, and what a surprise those are more associated with anarchist capitalism or imperialism, but since they don't reduce to a nice formula you get this somewhat smug analysis of human behavior. Where is the "legibility" problem of the US invasion of Vietnam for instance? There is none because the interests (contain China, destabilize the region) were quite clear, and were achieved, despite the US "losing" the war.

(I'm also really sick of the "Gervais Principle" blather so that may be biasing me against the ribbonfarm blog though)


I cannot recommend this book enough.


"There is always a well-known solution to every human problem—neat, plausible, and wrong" - H. L. Mencken


One thing that I always think is undervalued is how variable a single persons output is. A bad day, illness, life changes, etc all dramatically impact a person’s efficiency.

Treating even the same persons output as abstract is fraught with issues. One month a rockstar the next a schlub.


Some of the most capable people I've ever worked with have been "bursty" in that they would go through intense periods of high value output and then need to almost go dormant for a while to reset. As long as the "high value" phase was uniquely and significantly valuable it wasn't a problem so long as management understood and planned their assignments appropriately.


I'd like to think I'm capable, but whatever I am, it's certainly bursty with periods of dormancy. To the other comment, it's probably on the bipoloar spectrum. Some of it is self-inflicted. Most of it isn't.

Before covid, I'd had 2 managers who knew something of what I was dealing with and gave me the space to deal with it and encouragement that my work was good enough often enough not to worry. With some 5+ other managers, I believe I successfully masked it and that it would have threatened my job had I failed.

In the remote world, it takes almost no work at all to manage around my work schedule. I don't even feel like I'm masking anything, just living. Weirdest part is I've now fallen into a far more social role.

Who would have thought remote work had such hidden benefits?

/...almost everyone


congratulations on finding a comfortable way to work that works for you, allows you to be productive, as well as more socially fulfilled. as someone currently attempting to find a nice niche for myself as well, much respect.


I'm like this. Not just in a commercial context, but also at home with pet projects. I go through phases of being extremely creative with things I come up with, for about 2 or 3 days, then I go back to normal for about 30 to 60 days before I get to that state again. Luckily I've been able to notice this behavioural quirk so I try to code/write as much as possible down to use as building block to use on my "boring" days, but sometimes it feels like I cannot remember doing it or it was a different person doing it, kinda baffling to be honest.

During the bursty periods, it affects both my creativity and the amount of work I output. I haven't found a way to trigger/force myself into this state yet. I've tried different sleeping patterns, food, sex, drugs & caffeine, different kinds of music etc, to no effect. Music has come the closest to getting me to that feeling/state.

Anyone else have more things to try?


I have to note that I've been diagnosed with Adult ADHD earlier this by a psychiatrist. No bipolar, depression, anxiety behaviours present.


I was just about to say that sounds very adhd like (I’m diagnosed as well). Have you tried adhd medication? Not sure if that was inferred by your comment on drugs.


Yeah.

Concerta messed me up so badly for about a week, then I stopped taking it. I want to try Vivance but it is not available in my country.


Not to lean too much into my armchair, but the phenomenon you describe sounds like some mild form of bipolar.

Periods of very high output, and then periods of slump. Not much of a long term stable in-between.

I wouldn't be surprised if that's very effective for the right kind of project.


>some mild form of bipolar

Please no; we don't have to stigmatize normal waxing and waning of mental/physical energy.

There are a lot of "normal" factors involved in any Individual's productivity and pathology should be consulted only as the last resort.


Thank you. Everyone has up days and down days. Some of them can even be kind of extreme like not wanting to get out of bed. Variation is normal, we are not robots.


I am bipolar and this is completely wrong. People have variable output. Motivation comes and goes. Live circumstances change. People burn out.

These are not bipolar. The name "bipolar" is very misleading. One book I've read has called with multipolar disorder, which is far more accurate. There isn't just mania or depression. There is a whole world of possible dysfunctions that come with it: Anxiety, ADHD, insomnia, psychosis, and the list continues. There can be different moods, stages, and flavors of mania and depression in one person!

On top of this, these symptoms need to be severe enough to impair normal daily function to be diagnosed.


Motivation is a big one for me. Some tasks (or projects) just don't motivate me at all, and they turn into a dreadful slog. Others are captivating and I have a hard time logging out at the end of the day. I think there's easily a more than 10x difference in my own performance between those. Could be closer to 100x.


Completely agree, and reminds me of how much I hate the common Agile terminology of "sprints".

Sprints are an extraordinary effort and are by definition not sustainable. If you run a sprint, you have to recover for at least as long before returning to baseline.

I know it's just a word and doesn't literally mean to sprint, but I feel like it still subtly infects how development is viewed and approached. Even replacing it with something like "iterations" still implies that every 2-3 week period is cookie-cutter and predictable.


"Who can run at the top of their ability? Right. A short distance runner. You can’t run far at that speed. We programmers have figured out how to fix that, though. We just fire the start pistol every hundred yards and call it a new sprint!"

Rich Hickey

https://www.youtube.com/watch?v=SxdOUGdseq4


This right here is what everybody needs to factor into their planning. For some reason management doesn't seem to understand this. IMO this is one of the main reasons for failure.

As an example; i was once complimented (backhanded?) as "you are brilliant but moody" :-) It really made me realize the variation in my productivity which others had picked up on.

Another example; in one project there was a real smart and knowledgeable programmer who had taken up a lot on his own shoulders. I was skeptical on whether he would be able to deliver on it and had tried to raise it diplomatically with management. Of course they didn't understand the human ramifications; result? A week before the deliverable, the guy cracked under the pressure and did not show up to work for the next two weeks. IMO, Management was squarely to blame for this since they did not understand the psyche of the people involved.


Realizing this is important for retention. It's damaging when upper management falsely thinks people are interchangeble, which is a common view among non-technical types and HR. This leads to 10x people feeling underappreciated and resentful, ultimately causing them to resign for higher compensation and more appreciation elsewhere. It can literally destroy small companies if an individual's unique contribution isn't properly understood and valued.

Managers should err away from language about "the group", "the team" or "collective" and really drill down to the level of individuals as much as is practical. This is the correct resolution for most decision making. "The team" is just an abstraction that's useful to a small extent for a certain class of decision making, but not beyond that.


What I've experienced at companies on a death spiral is that there are a few people everyone can agree are useless, and beyond that you start picking people based on your poor understanding of how the sausage is actually made.

Once someone really useful has been let go, you have the sudden realization that your situation isn't that different than theirs. If management can misunderstand Tim's value, they sure as hell can misunderstand yours. At which point everyone's productivity is compromised by existential dread, and the wheels just start coming off faster.


Yeah been there, and instaquit. That company seems to be a shell now.


This experience contributed greatly to How I Learned to Stop Worrying and Love the Severance Check.


> It can literally destroy small companies if an individual's unique contribution isn't properly understood and valued.

It's generally cheaper to poach engineers than to buy a company. Just food for thoughts.


Is this really true for small companies?

A senior at FAANG is worth sometimes well north of 500K/yr. There are plenty of folks strewn about small software companies that do similar work to a senior or even staff/principal at a faang at wildly huge discounts.

It's hard to find numbers for the value of small software businesses (OP's quote), but this article [1] puts the number at $667k. If that's true, the engineer is SUBSTANTIALLY more expensive than the business (you're not just renting the business for a year).

[1] In the period between 2013 and 2016, the average sale was $667,000. While some sales were obviously much higher, and some were actually a bit lower, this must be an encouraging figure for a business owner to see.


> A senior at FAANG is worth sometimes well north of 500K/yr. There are plenty of folks strewn about small software companies that do similar work to a senior or even staff/principal at a faang at wildly huge discounts.

Those discounts are why it's easier to poach the employees.

If a company has 10 engineers earning $200K/year, why would you buy the company for $667K per person and then pay the employees on top of that?

Just offer the employees $500K/year and they'll stream right over.


Oh, I misinterpreted GP. Yes, agreed: for small software shops, the key senior ICs are probably worth more than the company itself.


And when acquiring an existing company, the buyer is typically interested in keeping a lot of the engineering staff. I've only seen a few acquisitions where there was no interest in keeping the engineering staff (North comes to mind; this one was strictly for Google to get its hands on the patent the company had acquired from Intel).


There are only so many $500k spots available. If every engineer in the world said “I’m moving to SF and applying to Google” and assuming visa allowed that you’d see Google paying a lot less for talent! Which means that while some people earning 200k are underpaid, they can’t all be underpaid.


Big Tech and most established companies make billions in profits off software products developed by engineers. Engineering Software Products is a highly specialized skill and absolutely isn’t compensated to the same degree as its impact; Silicon Valley was the first to realize and reward this somewhat adequately (IMO still not enough).

It’s really great for management types that they’ve managed to restrict the median compensation at fairly low levels; this is also the case for software outside of the well known tech hubs.


This might be true, and I agree SWE should always push for getting a decent slice of the pie. However how much of the 'value' is establishing a monopoly in some area of tech, rather than the tech itself. The mysterious "good will" or "intangible assets" of the brand value, institutional knowledge, having the right software and hardware in one place etc.

There is only one Google, but there are plenty of bright people who are capable of learning SWE.

If all the little tech companies were making $1m revenue per SWE too, then yes you'd probably see tech wages raise in line with that.

However those little tech companies haven't solved traction and growth yet (if they are aiming to at all), so they can't compete with SV and stay profitable. They don't have $100M in funding to throw into salaries.

Or from another angle - a individual SWE starting their own mini SaaS makes $2k a month. They are happy for this as a start, but on the other hand they are extremely underpaid!

An analogy - shouldn't Amazon warehouse workers be on double what they are paid, as without them Amazon can't ship anything!

At the extreme, workers getting the full value of what they are putting in would be something different to a corp, more like a co-op.


Amazon warehouses is not a good example. Amazon can and does build warehouses where it can get cheap labor. Whereas most Big Tech firms are based in high CoL cities. Why? High skilled labor has much better leverage due to being in short supply.

I do agree with the point that many of these firms are operating under monopoly conditions. However, for them to be continue to be monopolies requires them to either hire or acquire the best talent that’s possible. The monopoly cannot run itself, and that’s the leverage that software professionals aren’t utilizing fully yet.


The larger worry for petite capitalists is not competition with large tech, but rather the possibility that senior engineers at small firms realize that they are the firm and have enough savings to jump ship, build an mvp, and cannibalize the old business.


Salary is per year, buying a company is a one time cost. Retention agreements are a part of the purchase so they know the employees they got will be forced to stick around if the purchase goes through.


Not everything is just about the salary


Gelled teams are an actual thing though.

A good team can be better at something than all it's seperate members.


And a bad team can be worse at something than all it's separate members.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: