The project I got transferred to was the thing of nightmares.
Not deterred, I hacked into it a shitty solution and shipped it very fast. I shipped it so fast that suddenly I had everyone's attention. And I shipped another thing super fast and got more attention. One day, I said "this needs to go", and everybody listened, architects and directors alike. 6 months later, most of the code was replaced by my code or something originating from it. Every projects and features delivered on time with great appreciation of the clients.
You have to make it like software development is not a problem at all in the eye of your client and never never go behind the line where this is not true. The day software development is a problem, you lose. You must deliver software like you're delivering a book from amazon, no matter what. Because then, you got credit to make things better, which creates a positive loop. In that particular instance, I used some rushed victories to get more credits to make things clean later on. The guys who say they can make things clean but never ship and never win any battle against a deadline are just funny anyway.
To be honest, I took some fights in my career. I was fighting some dudes in every project. But don't fool yourself: if you're not really capable of making things better, then fighting is useless, just improve. You win the fights because the managers are on your side and you get them on your side by making software development not a problem at all.
> You must deliver software like you're delivering a book from amazon, no matter what.
This particular story provides an important refinement to this point. Success isn't always possible. Delivering "no matter what" is part of what engenders trust, but an even more important component is being ahead of the ball.
If your manager comes to you saying "you're not matching expectations", whatever explanation you might have will be read as an excuse. If you proactively tell your manager "hey, this framework seems hellish, we might face some problems", you're leading the discussion in how to recover from a bad situation — You redefine "success" early enough in the game that you can actually deliver it. Knowing how to have this conversation (and the self-reflection necessary to understand you need to have it) is one of the most important parts of a "true" 10x engineer.
> Not deterred, I hacked into it a shitty solution and shipped it very fast.
And moved the burden of maintenance to someone else? If so, this is one of the things people are complaining about 10x dev on twitter. You may look good, but the team / dept / company is worse off, and someone else has to clean up.
100% true. You don't get to replace a pile of shit or even to call it a pile of shit before you demonstrate that you can navigate the pile of shit and teach it new tricks, otherwise you have no credibility. This of course means, at least theoretically, that a sufficiently big pile of shit never gets replaced (since nobody can (or wants to) be sufficiently productive with it to gain the necessary credibility) and might sink the company which made it. But there's no other way. There are always 10 people telling that the code is shit and the only reliable way to tell that some of them are trustworthy is by observing their ability to get things done in the existing code base.
The story has survivorship bias. I have similar stories that are exactly the opposite. Started on a prohecr, refused to ship crap, shipped the right thing late to the delight of customers and supporting staff.
The other main point is that while I'm doing this thing that gained cred and leeway, at the time I'm just trying to do the right thing in the eyes of people who have to deal with it first hand over the long term including maintainers of the software. At no point dud I think if I do this and look good I'll have the points to fix my mess later or any sort of gaming strategy at all.
I find comments like these, which boil down to “stop complaining and hack a solution already” to reinforce the problem identified by TFA, which is that context matters. I feel like OP has elided that fact; the context is that a hacked up solution was acceptable here. That is not always the case, and sidesteps the point that context is king
"There is hardly ever lock contention, so I just ignored locks in my coding. It really sped up my deliveries and I got a good reputation for moving quickly. Sure there were some corner cases to clean up later, but by then I had moved onto another project where I moved fast and broke things!" - fictitious person we've all known
Let me congratulate you. I'd be very yealous of such an achievement. You probably had things on your side, like being able to ship/deploy when you wanted and cooperative colleagues letting it pass review quickly. As for the 'just improve' part, few people can. Even experienced people like myself who are not at all bad programmers. Some things just take talent.
Sounds like you’ve advanced in your career by undermining your teammates and sacrificing professionalism in order to win praise from people who are willing to put systems and users at risk without understanding the co sequences.
I understand your point, which basically boils down to the axiom of managing expectations. But sacrificing professionalism is not something that should be accepted as normal, let alone celebrated as clever. It’s the oldest trick in the book.
You shipped hacky software very fast, and you think this is a good thing? Sounds like you got ahead personally at the expense of anyone who had to use what you wrote :/
In my personal opinion, the fact that in discussions about 10x engineers, many of the anecdotes and ideas try hard to discredit/disprove the concept¹ rather than presenting real-world examples of very productive engineers, indicates the fundamental will not to recognize them, simply because of pride.
So I'll give a short and sweet argument: read John Carmack's biography and code (both in detail), then feel free to argue that he's not a 1000x engineer, and/or that he's the only one in the engineering world with such capacity.
¹: I agree, though, that "10x" is a profoundly misguided label
The project I got transferred to was the thing of nightmares. It was a C++ project and all the bad things that have ever been said about C++ were true about that code base. There was not much code but it was utterly incomprehensible. There were massively deep inheritance hierarchies, compilation speed was measured in minutes for even the most trivial changes, and so on. It was managed by an architecture astronaut that, as one is wont to do, rewrote existing mature libraries as header only template libraries that were buggy and untested (one could even say untestable).
Oh no, it seems like a hyper-modern-C++ developer lead the project and transformed the code into template-metaprogramming madness... (inferred by the absurdly long compile times) Deep condolences to all the people who worked on the project.
I’m a definite believer in 10x developers because I’ve seen these mythical beasts with my own eyes.
For instance, dev teams of 20+ where one person is the absolute backbone of the team and churning out features faster than the rest of the team put together.
I’ve seen maybe 5 instances of this across hundreds of teams I’ve worked with (I was a developer turned consultant so have a lot of data). They are rare beasts but 10x devs absolutely exist.
I am not saying you are wrong, but could it also be:
1. the person had been there the longest, and had the most context on the code base.
2. There was very little docs on the code base, so new people had to go to them.
3. This person would just do the feature instead of helping the other person implement the feature, and ensure their position as "top feature churner"
If these are true, they may be 10x of the others on the team, but they are holding the team back by not dropping themselves to 4x and lifting up the other team members to 2x.
> For instance, dev teams of 20+ where one person is the absolute backbone of the team and churning out features faster than the rest of the team put together.
I also have seen that. And, when that person leaves is another one from the group that took the role. Because you can have so many roosters in a flock.
It is so important to be able to lead as to let other lead you. Too many people, especially managers, does not understands potential. They see the result without taking into account any context.
Can be even bad. In one team, there was this guy that was more productive than the rest. He was an asshole. Everything has to be done his way, so, it was clear why he was the fastest one. Without him the team will have been faster and the product delivered earlier. But, the manager only was comparing outputs and the asshole that did not let the rest of the team work had higher output.
So, yes, there is people that are 10x. But, they are the ones that share knowledge, that put the team needs above her owns. It is that person that everybody wants to work with. And usually has little to do with personal output and more with improvements in the overall team performance.
Too many times I have worked with self-proclaimed 10x that are just making other people lives miserable and are surrounded with people that is new because his previous colleagues have left the company.
So, you are right. I just wanted to make clear what, at least for me, it means to be a 10x developer.
Lots of conceited sounding comments here from devs who either have an inflated sense of communication skills or stopped reading the article quite quickly.
In my personal experience, the author's anecdote rings very true. At my first and last corporate job, I was handed a thick af HP laptop that could barely be used anywhere but in the cube, a hideous screen, 30 min build times, and a java stack that made testing/understanding the existing YUI (JS) codebase a brutal activity. It took almost my entire first 6 month contract to just get minimally productive, and that's without accounting for meeting interruptions. Another frontend fella was hired on shortly after me, and we worked together to test and get productive with this codebase which was great, until a month later the manager who popped his head in every so often to check that things were running to his measure, decided to shake things up and dismantle all the teams, re-positioning them on different projects for no apparent reason. My colleague and I were split up, me on the new project that he had been prepping for through requirements gathering and UX stuff. Starting from square one, on a team whose members had barely met, in a different part of the codebase that I'd never touched, and with a 2 month arbitrary deadline, all while everyone was moving from SVN to git, and the feedback loop on a frontend change (locally) being 5 - 10 minutes. Shocker, the project failed, I was fired, and much like the author, I wanted to get the fuck out of the industry.
Edit: I think it's important to note sometimes the nature of what you're working on or the company you're doing it for can be extremely constrained. That in and of itself isn't unsurmountable. But when the expectations, compensation, budget, and measure of output aren't balanced, or if the constraint is poor management that don't understand or care about the people they're managing, then it's just a tire fire.
I'm sorry but the author misunderstood the situation:
- He explained to the manager that a simple Hello World took a lot of time bla bla bla. The manager already knew this, that was his "achievement". He also took it personally as most people do, because when you tell him that something was bad, indirectly, you criticized his work (and so him) in the last years maybe.
- The author tried to explain rationally the situation. The manager didn't want to hear it because he was already desperate. The manager knew that the end was close. A desperate man does not think rationally. All you can say is that you will fix it and then proceed as normal. They just want to hear that everything will be good even if you know it will not be. You are his psychologist/priest now.
- The project had to failed. When you as a developer are in a situation when management is bad you should not do your best to save the project. The badly managed projects and companies must fail in order for the sane ones to survive. If you save a bad project/company you are the reason why there are some many bad jobs everywhere. Also this is the reason there is so much burnout in this industry.
What are the common "safe" traits of a 10x developer?
So far everyone I have met with traits like
- produces working feature/code faster than anyone else
- delivers stable massive projects on time
- can carry a whole team through fire and hell
- praised to produce masterpiece*
Are the same people everytime who are just
- good at playing office politics
- are excellent at cutting major corners
- knows when their project will fall apart and leaves before
- are in league with upper management, so can't callout
I have yet to met a real developer who when left team/project/job didn't leave a massive trail of destruction but up until they were present everything was a-ok-top.
May be someday I aspire to meet one, but so far, most pseudo 10x are just people knowing how to play right politics and hide the skeletons really well :(
Some times ago I was working in one company. We were building some platform and have the big task to integrate with another technology. I was involved in an absolutely different field and only participated in some meetings during the planing phase. The discussion lasts for a few months and when I completed my other project team already spent some sprints on development. When I have joined I wasn't familiar with underlying libraries and spent almost the whole week to improve my knowledge. When I have started to coding I found that whole project size is only 3-5 days of productive coding including tests for one person. My firsts thought was "I don't understand something", but when I ask some other guy to do pair coding during a day he barely did one class during 6 hours without tests and other things. And it was their normal pace for the whole team. But they get their bonuses and endless meetings.
Definitely, I feel myself as a 10x developer that days working with my normal 1x speed.
Are there general work practices of yours vs theirs which you can share that would give insight into why their pace was so much slower? Or was it all meetings :)
A lot of this rings true for me. A few years back I worked for a company that seemed hell bent on utterly demoralising its engineering organization. Think endless rules (even down to which HTTP verbs you were allowed to use), a Macbook Air for development work, releases that very literally required manager signoff coupled with a company culture that was very partial towards throwing engineers under the bus. Of course they were crippled by technical debt, outdated development practices and regularly plagued by production fires. They did make a lot of bad hiring decisions - helped largely by not conducting technical interviews. But even those of us who were competent felt like 0.1xers.
There are indeed a lot of factors involved and a good environment/stack/management can result in a lot of productivity from the team or at least multiple individuals. There are probably a handful of people in your city who could even do good work with spaghetti stacks and chaotic management.
But if your software requires a Spaghetti-Wizard, you're in deep doo-doo when he/she leaves because Spaghetti-Wizards are rare and hard to identify up front. It's a safer bet to clean up your organization and processes by listening to multiple people and not getting caught up in hype. Non-friends give you the most useful advice. If you gravitate toward people who only tell you what you want to hear, you'll have a biased perspective.
Another thing, sometimes a given stack or org is just not a good fit for you. People think in different ways. The author perhaps should have looked around and if other devs were doing fine with the odd stack, just say, "for some reason I find this particular stack confusing and difficult." Be honest and don't bash the architect if it's only you struggling.
I started my career on a 1.5 million LOC project that only had 5 developers working on it. It really influenced my development methodology, and I've always thought working on messy code bases was fun and challenging.
So when I started my consulting company I thought about marketing it as something like "Spaghetti-Wizard". Similar to the "we buy ugly houses" but "we work on ugly code. never surrender. never rewrite.". Couldn't think of proper way to find clients though, so with one exception mostly been working on greenfield projects or as an expert on Oil and Gas IOT systems.
I’ve worked with people who are the “10x developer” people are talking about. I hope I can explain the confusion.
First: let’s just replace that with “much more productive than average” developer. 10x is a silly statement, a bit like saying someone is a 10x footballer etc.
It’s correct to say these people get a lot more done than others. They often have admirable traits, such as great focus or enthusiasm for their job. They’re dedicated and will work long hours to get things done. Great for a CEO or investor to have. On solo projects, they’re exactly the man for the job. And startups usually begin as solo projects.
The reason there’s such a backlash on Twitter is that there is a huge cost to the rest of a software engineering team when working with such a colleague. Every instance I’ve seen of this situation has a common factor: as others joined the team, the MPTA developer monopolised the codebase. They won’t delegate, and preferred to spend time coding rather than helping others do their job.
And here’s the thing: The productivity gap is mostly a function of this dynamic
Try to take ownership of something, and the MPTA dev will use the time in the evening to rewrite your code in their style. They are extremely opinionated (though often correct) and unwilling to delegate and bring in ideas from others. Make a mistake (inevitably as you pick up the codebase) and the MPTA will roll their eyes at the CEO and replace your code. Working in a team is not about who writes more code, it’s about how to work together to move the company forward. And a happy team building a large product will always outperform a MPTA developer by long-term measures.
With no documentation, strong communication, team ethic, and delegation, employing a MPTA is unsustainable in the long term. If you’re a VC or early stage startup you probably don’t care about that. But most developers are in teams in bigger companies, and perpetuating the 10x myth makes their lives worse, and makes them look bad.
Moving on from the idea that a 10x developer is good for a sustainable development effort is a significant step in the maturation of software engineering as a field. They have their place and can be an incredible asset, but great software engineering is about teamwork and communication.
This is a nice anecdote, but it misses the mark a little bit.
A 10x developer is 10x compared to his peers under the same conditions. Comparing across project conditions like this is talking about a different concept.
That depends on whether you consider 10x as to be a context-based quality or person-based quality, and IMHO the later is the thing normally discussed. A python dev might be 10x in python, but they'll drop to 0.1x when doing JS for e.g. the first month. Does that make them a 0.1x dev? I'd argue not.
New programmers on a team eventually affect the quality of the code as they work, and thus the project conditions. Project conditions can also include how easy it is to work with others on your team, which depends both on the new dev and the existing team. So that definition misses a lot.
This story also raises an interesting point for development managers; When you transfer a dev to a new project, it's a lot like getting a new job - you ( probably ) won't have the domain knowledge, knowledge of the tools in use, will have to prove yourself to the other developers on that project before anyone takes anything you say seriously - etc; with one key difference - when you get a new job, you would usually expect a pay rise. I think this is a massive problem in larger orgs where developers may be seen as an interchangeable resource, and can be a major contributor to staff turnover, and loss of critical knowledge. Soon all your developers will be 0.1x.
If the definition of a 10x developer is 10x more productive than the least productive member of the team, then I’m at least a 10x engineer.
We had a story to build a relatively simple go web server and deploy it to kubernetes one of my teammates got it, and basically got no where with it for a couple of days so I thought I’d get it started for him.
I got a basic hello world server set up and deployed along with a ‘ko’ setup so he could do hot rebuilds and deploys with a keypress.
I sent him the git repo and instructions for how to get it working.
While I was waiting for him to get it working, I was kind of in a groove so I kept adding features from the story.
By the time he got it compiled (with me coming over and just walking him through everything because he couldn’t follow the same docs I used to get started), it was already 90% finished.
If I had waited for him, he’d still be working on it for another 2 weeks at least.
It’s not that I’m a genius or he’s an idiot, he’s just fairly new on the team and I built our whole stack from scratch more or less and know it like the back of my hand.
You could have been a 10x developer if you taught him how to do it. A single developer can only scale so much, a true 10x developer is one that scales the output of those around as well.
What about the infinity X developer. I’ve seen time and time again situations where a developer simply didn’t have the skills to complete a task. You could give that developer infinity time and it would never be completed.
And then you hand it to someone else, and it gets done.
There are some problems that are just really hard, and some folks just aren’t cut out for those problems.
Infinity X developer? If true, I'd say that team has a professional development and growth mindset problem, one symptom of which is a productivity problem.
Also,if one is a kind of mediocre developer but gets thrown into the team,where standards are high, the productivity of such a person would be higher than in a kingdom of spaghetti code..
I think the author raises a very good point. Developer productivity does not lie in a vacuum, this is overlooked a lot mostly because for small teams most developers manage their environment and toolings and for big teams there usually are standards to follow but there is a huge gap in the middle where if a developer is not vocal enough or has sway in a toxic team a good developer could spiral downwards in productivity.
As to a solution to what the author asked: "What could have been done". I think the way to handle that situation is to approach the manager with a solution. Tell them, if you give me A, B and C I will be productive, I do not have these now and they are causing me pain. To do this one has to have self-awareness and experience in what they need for a productive environment. one also has to be vocal and willing to fight for it.
I think the 10x developers are a myth if you compare the whole output versus another developer whole output.
But it is very common that a developer can fix a problem or build something 10x or even 100 times faster than others. Simply because they know the project, the language, understand the problem already, have experienced that problem before.
I have many anecdotes where I was stuck on something for hours and a colleague solved it in 10 minutes. But I have also counter anecdotes where 2 colleagues were stuck a whole day trying to solve a problem while I was out of the office and the next day I solved it in less than 5 minutes. The multiplication factor of that is insane, but it really happened.
It looks like the real 10x debate is not so much "do these people exist" (yes) or "is it context dependent" (yes), but the more subtle questions of how to identify one by any other means than working with them for weeks, and what a 10x developer (or salesperson!) is allowed to get away with in terms of not following the rules.
There is also the Stakhanov question about how to attribute the work of supporting and being supported by others, and how this can be used for propaganda.
[+] [-] quadcore|6 years ago|reply
The project I got transferred to was the thing of nightmares.
Not deterred, I hacked into it a shitty solution and shipped it very fast. I shipped it so fast that suddenly I had everyone's attention. And I shipped another thing super fast and got more attention. One day, I said "this needs to go", and everybody listened, architects and directors alike. 6 months later, most of the code was replaced by my code or something originating from it. Every projects and features delivered on time with great appreciation of the clients.
You have to make it like software development is not a problem at all in the eye of your client and never never go behind the line where this is not true. The day software development is a problem, you lose. You must deliver software like you're delivering a book from amazon, no matter what. Because then, you got credit to make things better, which creates a positive loop. In that particular instance, I used some rushed victories to get more credits to make things clean later on. The guys who say they can make things clean but never ship and never win any battle against a deadline are just funny anyway.
To be honest, I took some fights in my career. I was fighting some dudes in every project. But don't fool yourself: if you're not really capable of making things better, then fighting is useless, just improve. You win the fights because the managers are on your side and you get them on your side by making software development not a problem at all.
edited
[+] [-] pdpi|6 years ago|reply
This particular story provides an important refinement to this point. Success isn't always possible. Delivering "no matter what" is part of what engenders trust, but an even more important component is being ahead of the ball.
If your manager comes to you saying "you're not matching expectations", whatever explanation you might have will be read as an excuse. If you proactively tell your manager "hey, this framework seems hellish, we might face some problems", you're leading the discussion in how to recover from a bad situation — You redefine "success" early enough in the game that you can actually deliver it. Knowing how to have this conversation (and the self-reflection necessary to understand you need to have it) is one of the most important parts of a "true" 10x engineer.
[+] [-] mugsie|6 years ago|reply
And moved the burden of maintenance to someone else? If so, this is one of the things people are complaining about 10x dev on twitter. You may look good, but the team / dept / company is worse off, and someone else has to clean up.
[+] [-] yosefk|6 years ago|reply
[+] [-] karmakaze|6 years ago|reply
The other main point is that while I'm doing this thing that gained cred and leeway, at the time I'm just trying to do the right thing in the eyes of people who have to deal with it first hand over the long term including maintainers of the software. At no point dud I think if I do this and look good I'll have the points to fix my mess later or any sort of gaming strategy at all.
[+] [-] wbronitsky|6 years ago|reply
[+] [-] shoshin23|6 years ago|reply
As a manager, I'm more inclined to trust someone who's delivered results even in challenging codebases. It's human.
[+] [-] UK-AL|6 years ago|reply
He couldn't get things released quickly because he couldn't even get the program compilied without serious effort involved.
[+] [-] m463|6 years ago|reply
[+] [-] indogooner|6 years ago|reply
[+] [-] unknown|6 years ago|reply
[deleted]
[+] [-] timwaagh|6 years ago|reply
[+] [-] unknown|6 years ago|reply
[deleted]
[+] [-] bongobongo|6 years ago|reply
I understand your point, which basically boils down to the axiom of managing expectations. But sacrificing professionalism is not something that should be accepted as normal, let alone celebrated as clever. It’s the oldest trick in the book.
[+] [-] patientplatypus|6 years ago|reply
[+] [-] pif|6 years ago|reply
If you are taking responsibility to maintain it for 15 years, feel free to go on. Otherwise, please step down and let professionals do their work.
[+] [-] pizza234|6 years ago|reply
So I'll give a short and sweet argument: read John Carmack's biography and code (both in detail), then feel free to argue that he's not a 1000x engineer, and/or that he's the only one in the engineering world with such capacity.
¹: I agree, though, that "10x" is a profoundly misguided label
[+] [-] lasagnaphil|6 years ago|reply
Oh no, it seems like a hyper-modern-C++ developer lead the project and transformed the code into template-metaprogramming madness... (inferred by the absurdly long compile times) Deep condolences to all the people who worked on the project.
[+] [-] benjaminwootton|6 years ago|reply
For instance, dev teams of 20+ where one person is the absolute backbone of the team and churning out features faster than the rest of the team put together.
I’ve seen maybe 5 instances of this across hundreds of teams I’ve worked with (I was a developer turned consultant so have a lot of data). They are rare beasts but 10x devs absolutely exist.
[+] [-] mugsie|6 years ago|reply
1. the person had been there the longest, and had the most context on the code base.
2. There was very little docs on the code base, so new people had to go to them.
3. This person would just do the feature instead of helping the other person implement the feature, and ensure their position as "top feature churner"
If these are true, they may be 10x of the others on the team, but they are holding the team back by not dropping themselves to 4x and lifting up the other team members to 2x.
[+] [-] kartan|6 years ago|reply
I also have seen that. And, when that person leaves is another one from the group that took the role. Because you can have so many roosters in a flock.
It is so important to be able to lead as to let other lead you. Too many people, especially managers, does not understands potential. They see the result without taking into account any context.
Can be even bad. In one team, there was this guy that was more productive than the rest. He was an asshole. Everything has to be done his way, so, it was clear why he was the fastest one. Without him the team will have been faster and the product delivered earlier. But, the manager only was comparing outputs and the asshole that did not let the rest of the team work had higher output.
So, yes, there is people that are 10x. But, they are the ones that share knowledge, that put the team needs above her owns. It is that person that everybody wants to work with. And usually has little to do with personal output and more with improvements in the overall team performance.
Too many times I have worked with self-proclaimed 10x that are just making other people lives miserable and are surrounded with people that is new because his previous colleagues have left the company.
So, you are right. I just wanted to make clear what, at least for me, it means to be a 10x developer.
[+] [-] craigzucchini|6 years ago|reply
In my personal experience, the author's anecdote rings very true. At my first and last corporate job, I was handed a thick af HP laptop that could barely be used anywhere but in the cube, a hideous screen, 30 min build times, and a java stack that made testing/understanding the existing YUI (JS) codebase a brutal activity. It took almost my entire first 6 month contract to just get minimally productive, and that's without accounting for meeting interruptions. Another frontend fella was hired on shortly after me, and we worked together to test and get productive with this codebase which was great, until a month later the manager who popped his head in every so often to check that things were running to his measure, decided to shake things up and dismantle all the teams, re-positioning them on different projects for no apparent reason. My colleague and I were split up, me on the new project that he had been prepping for through requirements gathering and UX stuff. Starting from square one, on a team whose members had barely met, in a different part of the codebase that I'd never touched, and with a 2 month arbitrary deadline, all while everyone was moving from SVN to git, and the feedback loop on a frontend change (locally) being 5 - 10 minutes. Shocker, the project failed, I was fired, and much like the author, I wanted to get the fuck out of the industry.
Edit: I think it's important to note sometimes the nature of what you're working on or the company you're doing it for can be extremely constrained. That in and of itself isn't unsurmountable. But when the expectations, compensation, budget, and measure of output aren't balanced, or if the constraint is poor management that don't understand or care about the people they're managing, then it's just a tire fire.
[+] [-] GoToRO|6 years ago|reply
- He explained to the manager that a simple Hello World took a lot of time bla bla bla. The manager already knew this, that was his "achievement". He also took it personally as most people do, because when you tell him that something was bad, indirectly, you criticized his work (and so him) in the last years maybe.
- The author tried to explain rationally the situation. The manager didn't want to hear it because he was already desperate. The manager knew that the end was close. A desperate man does not think rationally. All you can say is that you will fix it and then proceed as normal. They just want to hear that everything will be good even if you know it will not be. You are his psychologist/priest now.
- The project had to failed. When you as a developer are in a situation when management is bad you should not do your best to save the project. The badly managed projects and companies must fail in order for the sane ones to survive. If you save a bad project/company you are the reason why there are some many bad jobs everywhere. Also this is the reason there is so much burnout in this industry.
[+] [-] n_ary|6 years ago|reply
So far everyone I have met with traits like - produces working feature/code faster than anyone else - delivers stable massive projects on time - can carry a whole team through fire and hell - praised to produce masterpiece*
Are the same people everytime who are just - good at playing office politics - are excellent at cutting major corners - knows when their project will fall apart and leaves before - are in league with upper management, so can't callout
I have yet to met a real developer who when left team/project/job didn't leave a massive trail of destruction but up until they were present everything was a-ok-top.
May be someday I aspire to meet one, but so far, most pseudo 10x are just people knowing how to play right politics and hide the skeletons really well :(
[+] [-] xenator|6 years ago|reply
Definitely, I feel myself as a 10x developer that days working with my normal 1x speed.
[+] [-] C1sc0cat|6 years ago|reply
[+] [-] drited|6 years ago|reply
[+] [-] tjpnz|6 years ago|reply
[+] [-] craigzucchini|6 years ago|reply
[+] [-] arethuza|6 years ago|reply
I hope they only allowed GET?
[+] [-] tabtab|6 years ago|reply
There are indeed a lot of factors involved and a good environment/stack/management can result in a lot of productivity from the team or at least multiple individuals. There are probably a handful of people in your city who could even do good work with spaghetti stacks and chaotic management.
But if your software requires a Spaghetti-Wizard, you're in deep doo-doo when he/she leaves because Spaghetti-Wizards are rare and hard to identify up front. It's a safer bet to clean up your organization and processes by listening to multiple people and not getting caught up in hype. Non-friends give you the most useful advice. If you gravitate toward people who only tell you what you want to hear, you'll have a biased perspective.
Another thing, sometimes a given stack or org is just not a good fit for you. People think in different ways. The author perhaps should have looked around and if other devs were doing fine with the odd stack, just say, "for some reason I find this particular stack confusing and difficult." Be honest and don't bash the architect if it's only you struggling.
[+] [-] JamesBarney|6 years ago|reply
So when I started my consulting company I thought about marketing it as something like "Spaghetti-Wizard". Similar to the "we buy ugly houses" but "we work on ugly code. never surrender. never rewrite.". Couldn't think of proper way to find clients though, so with one exception mostly been working on greenfield projects or as an expert on Oil and Gas IOT systems.
[+] [-] nerdponx|6 years ago|reply
[+] [-] randomsearch|6 years ago|reply
First: let’s just replace that with “much more productive than average” developer. 10x is a silly statement, a bit like saying someone is a 10x footballer etc.
It’s correct to say these people get a lot more done than others. They often have admirable traits, such as great focus or enthusiasm for their job. They’re dedicated and will work long hours to get things done. Great for a CEO or investor to have. On solo projects, they’re exactly the man for the job. And startups usually begin as solo projects.
The reason there’s such a backlash on Twitter is that there is a huge cost to the rest of a software engineering team when working with such a colleague. Every instance I’ve seen of this situation has a common factor: as others joined the team, the MPTA developer monopolised the codebase. They won’t delegate, and preferred to spend time coding rather than helping others do their job.
And here’s the thing: The productivity gap is mostly a function of this dynamic
Try to take ownership of something, and the MPTA dev will use the time in the evening to rewrite your code in their style. They are extremely opinionated (though often correct) and unwilling to delegate and bring in ideas from others. Make a mistake (inevitably as you pick up the codebase) and the MPTA will roll their eyes at the CEO and replace your code. Working in a team is not about who writes more code, it’s about how to work together to move the company forward. And a happy team building a large product will always outperform a MPTA developer by long-term measures.
With no documentation, strong communication, team ethic, and delegation, employing a MPTA is unsustainable in the long term. If you’re a VC or early stage startup you probably don’t care about that. But most developers are in teams in bigger companies, and perpetuating the 10x myth makes their lives worse, and makes them look bad.
Moving on from the idea that a 10x developer is good for a sustainable development effort is a significant step in the maturation of software engineering as a field. They have their place and can be an incredible asset, but great software engineering is about teamwork and communication.
[+] [-] ramblerman|6 years ago|reply
A 10x developer is 10x compared to his peers under the same conditions. Comparing across project conditions like this is talking about a different concept.
[+] [-] franciscop|6 years ago|reply
[+] [-] kareninoverseas|6 years ago|reply
[+] [-] probablybroken|6 years ago|reply
[+] [-] empath75|6 years ago|reply
We had a story to build a relatively simple go web server and deploy it to kubernetes one of my teammates got it, and basically got no where with it for a couple of days so I thought I’d get it started for him.
I got a basic hello world server set up and deployed along with a ‘ko’ setup so he could do hot rebuilds and deploys with a keypress.
I sent him the git repo and instructions for how to get it working.
While I was waiting for him to get it working, I was kind of in a groove so I kept adding features from the story.
By the time he got it compiled (with me coming over and just walking him through everything because he couldn’t follow the same docs I used to get started), it was already 90% finished.
If I had waited for him, he’d still be working on it for another 2 weeks at least.
It’s not that I’m a genius or he’s an idiot, he’s just fairly new on the team and I built our whole stack from scratch more or less and know it like the back of my hand.
[+] [-] maaaats|6 years ago|reply
[+] [-] unknown|6 years ago|reply
[deleted]
[+] [-] lkschubert8|6 years ago|reply
[+] [-] UK-AL|6 years ago|reply
You know have another capable engineer. That's real 10x.
Your solution of just doing it by yourself is a short term boost.
[+] [-] jnwatson|6 years ago|reply
And then you hand it to someone else, and it gets done.
There are some problems that are just really hard, and some folks just aren’t cut out for those problems.
[+] [-] kevinconroy|6 years ago|reply
[+] [-] cosmodisk|6 years ago|reply
[+] [-] adim86|6 years ago|reply
As to a solution to what the author asked: "What could have been done". I think the way to handle that situation is to approach the manager with a solution. Tell them, if you give me A, B and C I will be productive, I do not have these now and they are causing me pain. To do this one has to have self-awareness and experience in what they need for a productive environment. one also has to be vocal and willing to fight for it.
[+] [-] Kaotique|6 years ago|reply
But it is very common that a developer can fix a problem or build something 10x or even 100 times faster than others. Simply because they know the project, the language, understand the problem already, have experienced that problem before.
I have many anecdotes where I was stuck on something for hours and a colleague solved it in 10 minutes. But I have also counter anecdotes where 2 colleagues were stuck a whole day trying to solve a problem while I was out of the office and the next day I solved it in less than 5 minutes. The multiplication factor of that is insane, but it really happened.
[+] [-] dikei|6 years ago|reply
[+] [-] pjc50|6 years ago|reply
There is also the Stakhanov question about how to attribute the work of supporting and being supported by others, and how this can be used for propaganda.