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.
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.
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.
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.
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.
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.
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
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".
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.
/s, obviously
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.
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.
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.
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.
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.
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.
>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.
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".
Jeff Dean is probably legitimately an outlier, though.
The same is true in nearly every field. Programming is not special.
The 10x programmer is real. The 5x salesperson is real. The 20x manager is real.
But however they got there it took time, it's something that can be cultivated as long as folks aren't treated as fungible.
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.
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.
https://www.dallasnews.com/news/crime/2021/04/27/allen-man-w...
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.]
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.
- Bill Gates
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.
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.
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
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.
It all depends on what the actual "airplane" (product) that's being built is.
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.
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.
Using no code or knowledge from the past 2 weeks?
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.
Are you HR, by chance? Have you ever coded something in your life?
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.
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.
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.
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.
The latter I've seen. A lot. The former I have not.
I have also seen -10x engineers. Generally the best you can do is stay well clear.
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.
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.
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.
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)
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.)
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.
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.
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.
There's no sense in doing an apples-to-apples comparison when you've only got one apple, an orange, and a pear.
> 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.
> 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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).
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.
But, but ... isn't every estimate supposed to be provisional? Aren't you supposed to be re-estimating regularly?
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."
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.
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.
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 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 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.
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.)
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.
I haven't overshot the estimate yet.