25 ms·

A personal story about 10× development

• choeger 7y ago
  Well, but C++ does take a lot of time to compile. The whole meta language implementation is relatively dumb for a lack of another word. So should every C++ product now be scraped and rewritten either in rust, ocaml, or C? Or is it upon the Developer to see these problems and find a workaround?
  • Crinus 7y ago
    The problem didn't seem to be that C++ was slow to compile but the manager' inability to understand that C++ was slow to compile (i'm ignoring the whole "architecture astronaut" and "untestable code" angle because it relies on the author's ability to judge that and from my experience people need a lot of time to become familiar with non-trivial C++ codebases and way more often than not they blame the codebase itself and whoever wrote it for that). Considering the project folded it might also have been a sign of bigger issues with management there.
    • acqq 7y ago
      What you ignore is: "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)." I'd like here to quote this: https://blogs.msdn.microsoft.com/ricom/2007/02/08/performance-problems-survery-results/ https://blogs.msdn.microsoft.com/ricom/2007/02/08/performanc... "Which of the following is more likely the culprit of this crisis that has your boss in a panic: 1) A developer failed to code a good algorithm in some module and now a very smart person must come along and replace that module with something much better. 2) The project has far too many layers of abstraction and all that nice readable code turns out to be worthless crap that never had any hope of meeting the goals much less being worth maintaining over time." "Of 27 responses at this writing 8 didn't specify #1 or #2 at all or were balanced 4 went clearly for #1 15 went clearly for #2" I've had my own experiences of #2 on different occasions (I work for decades already).
      • Crinus 7y ago
        Yes, without having enough information to judge for themselves people tend to assume the worst. This applies to both the poll you linked and to people coming head first to a new complex codebase they have no idea about (yet need to learn fast due to boss pressure).
        • deleted 7y ago
          [deleted]
        • acqq 7y ago
          My experiences do confirm that there are developments which are indeed “worthless crap that never had any hope of meeting the goals much less being worth maintaining over time.“ There is a real problem of making unnecessary and long-term bad abstractions, and there is a lot of such often in the code using Boost, as an example.
  • arethuza 7y ago
    I suspect projects in a new language always look better for a while as there simply hasn't been the time for cruft to build up, everyone is excited about the new language and learning how best to apply the new features. NB I'm saying that things Rust aren't 'better' than C++ - just that initially all new project in a new language have a positive bias (as do new projects) and that time will tell how big the advantage really is.
  • dep_b 7y ago
    This article doesn't feel like an attack on C++ but rather C++ written by incompetent people.
  • Traster 7y ago
    Large codebases can take a long time to compile, but if, as the article claimed a simple new Hello-World example is taking minutes that's because your build system is unnecessarily rebuilding everything every time.
    • mbeex 7y ago
      I know not all things should be attributed to technical causes. But I'm a consultant and I often have to deal with - to me - new MLOC piles of C++ code. These code bases are of course almost always non-trivial and my first approach is most of the time - If I am permitted - to analyze the include structure and to optimize it. Removing headers, pimpl, basic things. Only then would I even begin, to explore particular problems. Side effect is an intermediate 500 feet view, that develops along the way. Many developers are too hasty, taking too narrow an approach.
    • C1sc0cat 7y ago
      People need to remember that in the old days several minuets to compile was the norm and you might have to wait your turn in the queue. I recall working in my first jobs terminal room and one of the engineers came in to login to AUWE ICL - and shaking her head after seeing 38 jobs in the queue in front of hers
  • slavik81 7y ago
    C++ is never fast to compile, but some design decisions will make it much slower than it needs to be. The less stuff you put in your headers, the faster it will build (for the most part). You can also sometimes make templates slow by programming horrors like iteration through repeated template instantiation. There's an old joke about those sorts of problems. "Doctor, it hurts when I do this," says the patient. The doctor replies, "then don't do that."
  • lasagnaphil 7y ago
    There are many techniques to combat compile times in C++. One of the more easy solutions is to not use heavily templated header-only libraries too much, which is precisely what the architecture astronaut mentioned in the article did. Many people say that templates in C++ is a zero-cost feature, but it slows down compile times so much up to the point that you can't call it "zero-cost". I think it's just another tradeoff that C++ developers have to make - between generic code, performant code, and fast-to-compile code.
• cosmodisk 7y ago
  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..
• gbersac 7y ago
  It's easy to be a 10x developer if you don't write tests, no documentation and don't design anything, don't do any code review...
  • philjohn 7y ago
    And yet there are just people out there that do ALL of that, play well with others AND have high productivity.
    • quickthrower2 7y ago
      The question is how do us 1xers avoid getting compared to them ;-)
  • dikei 7y ago
    Well, they might as well fire their in-house devs, outsource those jobs to some third-world developers for half the cost. Same result: no tests, no docs, no design, no code review
  • thedjinn 7y ago
    That will make you a 10x developer today but a 0.01x developer when shit hits the fan.
  • chippy 7y ago
    I worked with a developer and he wrote the best tests and coverage. He encouraged me to also write tests that covered everything as he would often re-implement something somewhere else and it would break my code, but there wasn't a test that showed it being broken. I wrote tests to protect my contributions!
  • thecatspaw 7y ago
    Thats what I think when I hear rockstar developer. They truly are rockstars. They come in, give all and accomplish great things, but you have to clean up the venue the next day
  • Udik 7y ago
• pizza234 7y ago
  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
  • robteix 7y ago
    I don't think anyone doubts that outliers exist. That is obvious and true in any profession. It's more about what a "10X" is. If someone comes up with "10X developers use black background and their x key is more worn out than the e key," I think it's not unreasonable to question that. Also the question of whether someone who's able to spit out great code really fast but is incapable of testing, documenting, or architecting something is indeed "10X". So the question is not "do outliers exist?" but "what qualities do outliers exhibit?"
    • mattbuilds 7y ago
      I doubt that it's about writing code quickly but instead about how they architect the system. They build in a way that makes the code easier to use, easier to add features, and less prone to errors (because it's more straightforward). I always think of it as someone who lays a solid foundation that lets them build quicker and better.
      • xeonoex 7y ago
        I'd say it's this, but with a couple more thing. One is a lot of experience with the tools they are using. Not having to learn something new saves time. The other is not over-engineering. They have a great idea of the scope and scale of the project, and avoid programming for things that would be out of scope.
  • spion 7y ago
• Gin1234 7y ago
  The 10x comparison makes only sense if you compare developers on the same project. If there are colleagues that perform much better, try to learn from them
• ramblerman 7y ago
  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.
  • franciscop 7y ago
    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.
  • kareninoverseas 7y ago
    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.
    • ramblerman 7y ago
      Everything you said is true, but I didn't make up the definition :) This term was coined many years ago to highlight one simple idea. That you can hire someone tomorrow that would have 10x the output of the average hire. Basically that such people exist. Cross team productivity, and inter team dynamics are very interesting topics, perhaps more interesting, but this label for this topic is pretty clearly defined.
      • themarkn 7y ago
        The meaning of 10x has blurred considerably - when coined, as far as I can tell, it seemed to mean that sometimes the most productive developer on a team is 10x more product than the least productive developer, not the “average hire“ - which is a very different claim.
• artsyca 7y ago
  you fools still believe it's an innate characteristic that only a few can possess; it's something anyone of us can achieve as a form of transcendence
  • mbrumlow 7y ago
    Just wondering. Can we all be J. R. R. Tolkien? Other industries have people who are clearly Superstars. Why would they not hold true for development?
    • Aeolun 7y ago
      Nah, I expect not. But we can probably all be Jim Butcher or Robert Jordan.
      • artsyca 7y ago
        You're still trying to be anything but yourself, why not start at first principles?
    • artsyca 7y ago
      JRR Tolkien worked closely with CS Lewis and they formed a powerful workflow -- go ahead and believe whatever you want but each of us has a unique ability and we're superstars in our own right but we rely on context which is sorely lacking in the technological industrial complex
• benjaminwootton 7y ago
  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.
  • barking 7y ago
    Maybe you're only aware of these beasts because their codebases need disproportionately more maintenance? Please say yes. :-)
  • mugsie 7y ago
    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.
    • laichzeit0 7y ago
      It's so weird to see so many people argue so hard that the Usain Bolt's of the programming world simply cannot / should not exist.
      • mugsie 7y ago
        Sprinting - individual sport. Development - team sport. You could put Messi on my company's 5 a side lunch time team, and we still wouldn't win the champions league, and the skill of the others on the team would atrophy, and they would become over reliant on a single person. Not a great thing for a team. A true "10x" engineer raises up the team by 10x by doing the things a lot of devs hate doing - docs, mentoring, guidance (without taking over someone's feature), and knowledge sharing. Not shipping :all-the-things: on their own.
• probablybroken 7y ago
  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.
• dikei 7y ago
  On a lighter note, iIf you don't see any 10x developers around, maybe you're the one :D
• yomly 7y ago
  I have maybe seen two people I would characterise as what other people might call a 10x developer. One of those 10x was truly someone who was worth 10 developers (at least!) given that not only was he capable of holding the entire business in his head, but he could also mentor and bring people together. At crunchtime he could also shield the rest of the team by churning out features at triple speed while still keeping them in a mostly maintainable fashion. He brought the best out in everyone. The other 10x was a silo of knowledge, was terrible at mentoring and wrote code which was neither readable nor high quality. That said, he was unmatched in his ability to ship and solve problems in distal regions of the codebase. In my evaluation of him, although he was 10x more productive than everyone else, I can't help but wonder how much less productive everyone was around him (and the team was larger than 10!). So tl;dr YMMV. They definitely exist, when they work right then probably can set up systems/organizations that can scale around them and generate tonnes of value. When they're egotistical/insecure vampires, their global value will be questionable but they will definitely look good relative to everyone else! I think moral of the story is don't hire assholes...
• quadcore 7y ago
  Let me tell you about one of my personal stories. 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
  • UK-AL 7y ago
    I really don't get your point. How does this help this guy's situation? He couldn't get things released quickly because he couldn't even get the program compilied without serious effort involved.
    • huffmsa 7y ago
      If there was minimal code and a lot of the dependencies were unmodified forks of common things, the GP here is likely of the opinion that he should have started ripping the wiring out and replacing it with something that works.
      • UK-AL 7y ago
        That generally takes a while. Not great if you want quick results.
• empath75 7y ago
  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.
  • UK-AL 7y ago
    Have you considered actually teaching and paring that developer for a few weeks? You know have another capable engineer. That's real 10x. Your solution of just doing it by yourself is a short term boost.
    • empath75 7y ago
      He didn’t want to pair, I asked. He also never asks for help when he’s struggling.
  • maaaats 7y ago
    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.
    • kevinconroy 7y ago
      Yep. And if you're a 10x developer who becomes a manager or team lead, your best bet to maintaining your 10x effect (or increasing it to 100x) is to grow and support your team. You might not say that they are each and all 10x, but if you can grow them from 0.01x-2x range up to the 1x-10x range, then multiple by n team members and you get the net effect of a 100x-1000x dev.
• strictfp 7y ago
  This story is basically about a 10x coder and architect which acheives his 10x by belittling others by means of architecture astronauting and personal job security.
• noir_lord 7y ago
  I inherited a similarly Kafkaesque codebase where I work now and yes, iteration on features went down dramatically from previous workplace. It's just so difficult to do anything without something completely unrelated breaking. Enough that I have considered simply leaving.
• n_ary 7y ago
  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 :(
  • BigJono 7y ago
    This is a complete guess just based off my experience, but I know a couple of devs I'd bet on to 10x the worst of the devs I've worked with (over a long sample period), and the one thing they have in common is that they keep their code simple moreso than the average dev does. One part of that is they all seem to err on the side of less code (including dependencies) over quicker implementations. The other part is a few times I've shot them a piece of code and they've come back with something simpler that I've overlooked. I.e they seem to have good fundamentals, good algorithm knowledge, good understanding of the language etc. It makes sense to me, because I think this is the only vector you can 10x somebody in. You can't generally 10x somebody early in a greenfield project because everyone is smashing out work. You can't 10x somebody in a hellish project like in the OP because everyone is struggling with the same cruft. The only way you can really 10x somebody over a big sample size is by keeping every project you work on simpler for longer. So that's what I look for when I'm looking for 10x devs. I might be completely wrong but it's the best indicator I've found yet.
    • Nyandalized 7y ago
      You can absolutely beat people in greenfield projects with experience; choosing and designing business data structures optimally so that not a lot has to be refactored. I don't really buy into the idea of attributing "x speed" to a developer, the idea is trying to oversimplify what is really a function of experience in- and the complexity of current task
• tjpnz 7y ago
  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.
  • arethuza 7y ago
    "which HTTP verbs you were allowed to use" I hope they only allowed GET?
    • Elixyrs 7y ago
      Nah, only DELETE
      • IggleSniggle 7y ago
        If this was the case the poster wouldn’t be complaining about the limitation, but celebrating!
    • IggleSniggle 7y ago
      If they only allowed POST, there would be actual good reasons for it.
    • tjpnz 7y ago
      For those interested it was HTTP DELETE. The kicker was that they disallowed it due to "security" concerns.
  • craigzucchini 7y ago
    I feel you. See me other comment itt.
• austincheney 7y ago
  Here are my brief incomplete thoughts on becoming a 10x developer writing JavaScript. In summary, become comfortable with how the technology actually works. Hoping something else will solve your problems for you makes you less productive (I've heard all the excuses). * Understand that super productive people likely do things that aren't the popular way of doing things. If the super productive way of doing things were the most popular way of doing things then everybody would be more productive. Be critical about why a productive person intentionally does something in defiance of popularity. * Become comfortable reading code. Frameworks, unit tests, processes, and tools are not there to make sense of the code for you. You cannot be a 10x developer if you are intimidated by reading code or expect something else to do it for you. * Learn to organize to the scope model before adopting any other convention. This will reduce the amount of code in a given application. In many cases it will also greatly increase code performance. In JavaScript OOP concepts and inheritance are conventions that can be avoided, but not scope. Scope is always present and not hidden behind a code convention that can be avoided. Don't be afraid to nest functions and try to declare references as locally as possible and share where necessary as this greatly increases maintenance speed. * Write original code. In JavaScript invented here syndrome is exceedingly common. In many cases it is faster to write original code for a given problem and in many cases that original code will execute orders of magnitude faster than misunderstood dependencies downloaded from NPM. If writing code is intimidating you will always be less productive. If you want to write clean maintainable code solve a given problem as directly as possible and then later, after clearing your mind, refactor the code to achieve simplicity. Simplicity almost always takes extra effort, but reduces maintenance time down the road. * Master the DOM. The DOM is still the ultimate backbone that glues all things together in the browser. The DOM is not some strange React fiction. It is a language agnostic standard. Learn the standard DOM methods and node relationships. The DOM methods execute thousands of times faster than query selectors and faster to maintain for code where sections of the page are in flux. https://dom.spec.whatwg.org/ https://dom.spec.whatwg.org/ * Become comfortable with callbacks. Node is callback driven. If you cannot figure out callbacks or passing by reference your code will be a struggle to write and look like spaghetti. * Learn to write your own tools. It is nice to increase your own performance because you have learned to automate part of your daily tasks or parts of your job away. This isn't something that comes naturally and it does take practice to become efficient write quick tools on the fly that doesn't burn up all your time. * Take ownership of test automation. Some developers want to test everything because people have told them testing is somehow important but have never learned what is important about testing. Tests are a form of debt that. Test what your application claims to do opposed to what it literally says. Test features, options, and output. Test that collisions of features do not produce unexpected results. If you are confused about what to test ask for guidance from your QA team. Ensure your tests automation executes as quickly as possible so that it isn't a swamp holding back the productivity of your team. Slow test automation is worse than unnecessary unit tests. * Most importantly accept that you are fallible and that you are probably wrong more than you are right. Learn to appreciate negative feedback and criticism as gifts of guidance. If you drink your own Cool-Aid believe you are too good for improvement you aren't improving. The soft-skills are perhaps the most important part of becoming more productive.
• pjc50 7y ago
  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.
• lasagnaphil 7y ago
  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.
  • karma_fountain 7y ago
    I have done this when I was younger, after reading Modern C++ Design and the Template Metaprogramming book. I am sorry. Please not I'm not saying those books are bad, just blindly apply stuff because you think it is cool and fancy is probably not good leadership.
    • bdavis__ 7y ago
      How do you know how to use the new shiny things without real practice? My friend, we have all done this. (after about the 10th time the 'new technique' turns to a mess, you become very conservative about 'new things').
      • TomMarius 7y ago
        I consider this one of the milestones leading to the senior title
      • microtherion 7y ago
        Ideally, I prefer to practice radical new approaches on hobby projects, or single person explorations, rather than team projects.
    • cgh 7y ago
• Kaotique 7y ago
  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.
  • jonathanstrange 7y ago
    I don't think it is a myth. If you look at coding challenges and live coding, there are developers who can churn out correct and well-documented C or C++ code while speed typing and without making any substantial mistakes. Not every developer can do that, no matter how experienced he or she might be with the language. I'm not one of them, but to give an example, I find some of Bisqwit's live programming on Youtube pretty impressive - and he works as a bus driver during daytime!
    • Kaotique 7y ago
      Yeah, but what if you shove some other language/problem in front of them? Will they still be 10x more effective than another developer? I don't think so. My point is that you can become very good in a specific area so much that you are able to outproduce the average developer by an enormous amount, but it may very well be the other way around in another area.
    • randomsearch 7y ago
      They’re a 10x code typer then. This is not development in a general sense, which involves working with people.
    • GuB-42 7y ago
      Doing coding challenges is a special skill. To be fast you need to: - Have all the boilerplate code almost memorized. By that I mean things like parsing a simple file, opening a display, etc.. - Know the relevant techniques, and train. For example, if you are doing a coding competition, dynamic programming algorithms are a classic. If pretty pictures are your goal, fractals and raytracing are a good start. Neither is likely to be of much use for you in the real world. What coding challenges don't require is the ability to think long term. That code is likely to be thrown away after the challenge is completed. Managing complexity is maybe the most important part of real world programming, and for technical reasons you have very little of it in coding challenges. As for Bisqwit's videos, they are awesome, and he certainly is very talented. I actually learned a lot from him. However, all his videos are about toy projects, not building complex applications. BTW, I think this is the reason he is a bus driver. He doesn't enjoy coding in a professional setting, because it is a different kind of work.
• craigzucchini 7y ago
  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.
  • nerdponx 7y ago
    Is this a communication issue? When you realized the codebase was a mess and that it would take you forever to reach productivity, did you reach out to the manager and explain the situation? Did you push back on splitting up the teams, and explain why splitting the teams would be a bad idea? Etc. Unless a manager is truly incompetent, in my experience they usually listen to technical people when they speak up on these kinds of topics.
    • pavel_lishin 7y ago
• stanislavb 7y ago
  I’d like to highlight this part: “But even more important than technical issues are things that promote healthy team dynamics. These include things like blameless postmortems, openness to ideas from everyone, permission to try new things even if they may fail, stern weeding out of jerk behaviour and, ultimately, trust.” It’s just so important.
• jnwatson 7y ago
  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.
  • kevinconroy 7y ago
    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.
    • username90 7y ago
      Having expectations that any person should be able to teach what they can do to the rest of the team in a timely manner is unreasonable. Problems like "Make X take less than Y time to run" or "Reduce binary size to Z" or "Design a fault tolerant system accomplishing Q" etc are often impossible for most to solve since they simple don't have enough foundations and intuition to solve them. You'd have to spend years drilling fundamentals to get people to that level if they are even capable of gaining the same intuition, most developers never gain those skills no matter how many years of experience they get.
      • kevinconroy 7y ago
        Who says you have to be the one to do it? What conferences exist? What books? Online courses? You don't have to be the professor, but you do need to be their advisor and point them in the right direction to learn, grow, and thrive.
        • jnwatson 7y ago
          Sometimes there aren't conferences, books, or courses. There are lots of problems out there without solutions you can take courses for. Board bring up, performance, and lots of problems that fall into the bucket of "machine learning" require knowledge, cleverness, and lots of persistence. There's also the set of problems that are best learned at universities. Normally, one doesn't have time for a developer to catch up on their missing compilers or cryptography class (this is particularly a problem since perhaps a quarter of programmers have CS degrees, and a quarter of them went to a decent program). If I were asked to debug a clock skew problem on a particular VHDL design, it would take me a long time to learn enough to even approach the problem.
• randomsearch 7y ago
  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.
• xenator 7y ago
  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.
  • C1sc0cat 7y ago
    I think there are more < 1x teams out there than people think
  • drited 7y ago
    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 :)
• adim86 7y ago
  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.
• Nec28 7y ago
  Do 2x developers exist? And what about 5x developers?
  • Nyandalized 7y ago
    It's a matter of speech, not a concrete measurement. I'd liken the speed to a "compiled" version of the problem in your mind; if you've done it before, it's easier to apply it now, rather than to start from the beginning to understand the problem.
• qwerty9876 7y ago
  I imagine most 10x developers just have their life together as a whole and that's what allows them to be so productive. So many developers I see are overweight, drink alcohol often, play video games until 2AM and then sleep 5 hours, no exercise at all, bad diet, porn addiction. By having such a bad lifestyle they are really low energy and tend to go into "autopilot" which of course translates to worse output at the job.
  • C1sc0cat 7y ago
    Meow :-) What happened to being civil
    • qwerty9876 7y ago
      I don't see the issue as the statement is not targeted at any single person, just a generalization.
      • C1sc0cat 7y ago
        Doesn't work like that though does it
  • Nyandalized 7y ago
    I don't see a causation here, those things aren't specific to tech, and are in fact fairly common in other areas of work as well.
    • qwerty9876 7y ago
      Yes, and I bet there are 10x employees in all other areas of work as well.
  • deleted 7y ago
    [deleted]
• GoToRO 7y ago
  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.
  • commandlinefan 7y ago
    Yep, exactly. One thing I’ve learned over my 30-year career as a programmer is: never argue. It’s a waste of not only your time, but your credibility. If they say it has to be done in a week, and it’s impossible to get it done in a week (like, actually impossible), you have two choices: disappoint them in a week, or argue, make them hate you, lose the arguments and disappoint them in a week anyway.
    • GoToRO 7y ago
      More stuff needs to be written to teach well behaved people how to deal with all kind of toxic persons in the workplace.
  • nerdponx 7y ago
    My question is: why didn't the author express all of this as soon as he realized it was a problem? One would hope that the author didn't spend several weeks in silent frustration! "Hey, all this template stuff is cool but it's going to take me a long time to sort through and understand. I'm going to need to ask a lot of questions about functions and logic. It would also be helpful if you could throw together some kind of quick and dirty documentation for X, Y, and Z classes which I already know are going to be important and it will be much faster and easier for you to write that (15 min) than for me to reverse engineer your thinking (15 hours)."
• hyperpallium 7y ago
  I always thought the 10x developer was simply someone who sees the cleverer, simpler way to do it. Like in trick maths problems: software is the thing in the world that is most like math.
• bushido 7y ago
  Can't speak to what makes a 10x dev. But a 10x dev team is much easier. Where each member can carry their own weight, most of the time. -- I have been involved in seemingly simple projects that never seemed to end (and a lot did not or shipped with significant debt) and on other complex/novel projects (with many unknowns) which went really really smoothly and shipped on time. Successes are oft attributed to a 10x developer or a high performing individuals contributors. But, then I've seen the same 10x devs go to 0.1x and 0.1x to 10x and back. My anecdotal observations on what sets successes apart from the fails are: - A well defined problem: Well defined to the extent that this intends to solve X. It can easily solve y,z,a and b, but it will not and is out of scope/not expected to be delivered. - PMs with domain knowledge: An external aide who can step in and guide when asked, or if the visibility reduces. But understands the problem and technologies involved (task masters need not apply). No PM is often better too. Also the PM here is more like a sponsor, only steps in when asked, to recover failure. - Smaller teams: Structured like a cross-functional pod. For complex projects a senior dev, a not as senior a dev and a designer work well. A lone wolf + a designer works. A junior dev with high degree of domain expertise on the problem + a part time designer works too. No designer necessary if there isn't a front end. - Hard code reviews: Starts with a good convention that's documented, a style guide for programmers. Some languages have this baked in. This happens at the very end in the testing/cleanup phase. - Let the teams write out the task, then group these in to scopes. A PM or person with more knowledge outside the pod might be tapped in to help sub-divide scopes. - Let the team on their authority cut down on scope if it helps ship on time, with fewer unknowns, without changing what we were trying to solve. - No extensions: The project is done or its done. - Finished early? Free time to NOT write code. Usable as the team sees fit. A few other nuances, one could argue that this makes for good and consistent 1x dev. It definitely makes for a 10x team. aside: read a great book that summarized a lot of the successes as a plan they use in there team. Its an easy 60-80 minute read (I'm a slow reader). Highly recommend it if any of this resonates, high recommend if it doesn't and you want more ammo for a flame war. https://basecamp.com/shapeup https://basecamp.com/shapeup
• losthobbies 7y ago
  I think it’s not unreasonable to suggest that there are very productive people out there. They pick things up easier and they generally have an aptitude for the work and the environment. However, the original tweet that set this whole thing off listed out a number of attributes that 10x engineers are supposed to have. Things like having dark mode in their IDE, using the command line and never needing to read documentation. Which is nonsense of the highest order.
• phtrivier 7y ago
  Rather sureal to see so many blog post about a "10x" controversy, without anyone actually referring to controversy - therefore making it impossible to understand if people are even talking about the same thing. Without any snarkiness implied, I suspect not being on twitter anymore lately has spared me a few hours in this case. Maybe 10x programmers (I'm not one) don't have time to talk about 10x programmers.
• he0001 7y ago
  One serious side effect of these kind of discussions is that people tries to be a “10x” developer, and start producing like hell but it’s just garbage. Also it creates a culture of “I deliver, ergo it’s good”. And then you are in knee deep crap, and the guy moves, leaving everyone else with the shit.
• tmaly 7y ago
  I deal with this type of situation on a daily basis. It turns your team into firefighters instead of being able to focus on building more value. When I hire new people, I hammer clean code and TDD. I am not dogmatic about it, I just know from experience that maintainable code makes for a more enjoyable experience for everyone on the team.
• karmakaze 7y ago
  This is a great story as it illustrates how to make a 0.1x (or 0.01x) developer. The 10x version of that is one who created a codebase that's missing all the ineffectiveness of this one as well as adding sprinkles if well defined boundaries to work on parts indepently without complication. Setting up this sort of multiplier environment of code structure is how you achieve Nx output for onself or others. Most of the time you shouldn't even see the 10x'ers work because it's invisible what's not there is the magic.
• dep_b 7y ago
  The worst thing about 10x devs is that some of them work in places where the process or general dread reduces them to 0.1x to 1x developers.
• fareesh 7y ago
  I prefer the term Batman developer He doesn't play well with others and usually he'll just do stuff his own way without telling anyone. He's usually right and he's usually more effective than his sidekicks. Some villains need Batman, but after a while he can work on more pressing issues and the sidekicks can handle the weaker villains.
  • EnFinlay 7y ago
    Sounds like the same destructive behaviour that is commonly referenced as the bad 10x developer.
    • Traster 7y ago
      Yeah, the obvious point is that Batman is a billionaire businessman who could pay his taxes and get Gotham to hire some decent police but instead of actually focusing on the structural problems that cause crime in Gotham, he runs around banging models and beating up street criminals. The Batman comparison is a great example, because the criticisms of the 10x developer match exactly the problems with batman.
  • pavel_lishin 7y ago
    It's an apt analogy. A sociopath who refuses to work within a system, is accountable to nobody, and is arguably creates the very same villains that he is forced to battle.
• tabtab 7y ago
  "Wanted: Spaghetti-Wizard" 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.
  • nerdponx 7y ago
    It looks in this case like the manager was the spaghetti wizard.
  • JamesBarney 7y ago
    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.
    • tabtab 7y ago
      There is certainly a need for "spaghetti decoders". Being able to study and figure out messy systems is a fairly rare gift.
• mbesto 7y ago
  "10x developers" are about as well defined as the word "startup". Similarly they are often used by VCs (or similar stakeholders) to attribute causation to a highly complex system, which is basically a fool's errand. The description the original VC uses for a 10x developer (where the tweetstorm originated) is akin to a supply chain that just spits out masses of widgets to a nascent widget market. VCs love this because it means a quicker ROI on their investment.
• the_gipsy 7y ago
  I have personally witnessed 10x developers. The trick is making everyone else look like 0.1x developers.
• pixelbath 7y ago
  I am getting so tired of the term "10x" due to the past week. Some people use it as a synonym for "socially maladjusted" or "toxic," while others use it like "amazing developer." Just...stop. Some people are more productive than others; it happens. Some people are toxic and destroy entire teams. It doesn't make sense to lump all different kinds of "developers we don't like" into the category of "10x" because that's not what that is. There's another comment in this thread suggesting a change to "more productive than average," which is a term I could get behind. You can't measure productivity to multiply it by any number, so please just stop.
• ilaksh 7y ago
  Don't forget "competent managers". The manager blamed him even though the codebase was the problem. Or do competent managers even exist? Or we just assume that they usually aren't and we will have to work around them?