Qualities that I believe make the most difference in programmers’ productivity

In this thread: mostly people responding to the headline, not the actual content of the article.<p>There&#x27;s some fantastic stuff in here about how great design is the key to increased productivity. For example:<p>&quot;It is very important for a designer to recognize all the parts of a design that are not easy wins, that is, there is no proportionality between the effort and the advantages. A project that is executed in order to maximize the output, is going to focus exactly on the aspects that matter and that can be implemented in a reasonable amount of time. For example when designing Disque, a message broker, at some point I realized that by providing just best-effort ordering for the messages, all the other aspects of the project could be substantially improved: availability, query language and clients interaction, simplicity and performances.&quot;<p>redis itself is a masterpiece of pragmatic design - the feature set is brilliantly selected to make the most of what you can do with shared data structures exposed over a network. Let&#x27;s talk about that.

Everything from the original post sounds reasonable, you should absolutely read it. Just some random thoughts to add to it:<p>* For most of my past clients, the skill &#x2F; output of their programmers was <i>not</i> the bottleneck, even though they thought so. As long as something is not a bottleneck, there&#x27;s not point in trying too hard to optimize it (since you can get better ROI somewhere else).<p>* Software is a team effort. Improving how the team works together &#x2F; how work flows through the system probably has a bigger impact than raw programmer output (unless you are already <i>very good</i> at that).<p>* Improving the quality of your software (minimizing defects and rework) will improve the output of everyone in the team, regardless of how good they are.<p>* I have heard of cases where removing the &quot;top programmer&quot; from a team made the whole team <i>more</i> productive, even though an important person was missing. I don&#x27;t have data to back that up, though.<p>Update: Thinking more about this... I have a talk called &quot;Your Company Will Never be Agile&quot;, where I talk about how most companies actively prevent their people from doing a good job (by having policies, procedures and a company structure that is not suitable for empowered teams). And then, those <i>same</i> companies complain that they cannot get good people and how all the hip companies can get the 10x programmers that &quot;we cannot hire&quot;.<p>I don&#x27;t have an English recording of the talk, but I started a series of blog posts about it: <a href="http:&#x2F;&#x2F;devteams.at&#x2F;your_company_will_never_be_agile_intro" rel="nofollow">http:&#x2F;&#x2F;devteams.at&#x2F;your_company_will_never_be_agile_intro</a> . I should maybe finish it some day ;)

This bit articulates what I consider to be the main advantage of experience in programmers:<p>&gt; Often complexity is generated when there is no willingness to recognized that a non fundamental goal of a project is accounting for a very large amount of design complexity, or is making another more important goal very hard to reach, because there is a design tension among a fundamental feature and a non fundamental one.<p>It happens all the time that requirements are very complex. Junior programmers will fail to implement them. Better programmers will manage to implement them, but it&#x27;ll take too much time to develop and especially to maintain their solution.<p>Experienced programmers recognize what&#x27;s happening and have the personality to stand up the project leader and get a simplified version of the requirements accepted.<p>It&#x27;s also why very large software projects fail, especially the type that is intended to save costs by replacing many different existing informal systems by a unified one. The requirements will be ridiculously complicated (have to do everything all the projects to be replaced do), and nobody in the software development part has the power to change the organisation first.

I started the week as an 1x programmer.<p>The lead on my current project micro manages every point of the code&#x27;s architecture. I have no freedom to make any calls, even on legacy parts of the code that could be refactored to better fit new requirements. None of the other developers &quot;own&quot; anything so no one can make any calls. Anything takes a week or more to be discussed. Arbitrary non-obvious decisions have been made in the code base and it&#x27;s up to you to figure them out. I am left fixing simple bugs and building things very slowly, treading very carefully rather than making it right. I am now a 0.8x programmer.<p>I look at my week&#x27;s schedule. I see that I have a lot of meetings and checkups that, while important, are unrelated to my current project and will only take a chunk of my time and energy. I am now a 0.6x programmer.<p>I work in an open space office where terrible music is played through its sound system the whole day. I have a hard time focusing and staying focused. I am now a 0.4x programmer.<p>--<p>While I enjoyed the article, I think it overlooks the fact that a developer&#x27;s efficiency is also often a factor of their environment (not just physical, but the project itself too). I&#x27;ve been 5x, I&#x27;ve been 0.1x, and the biggest contributing factor from project to project has been my environment. My experience and knowledge is also a factor, but this changed slowly, over time, while environment changes can mean I&#x27;ll go from being super productive to very unproductive in a month. More managers and leads need to be aware of that.

Taking myself as a 0.5x programmer, I have sadly encountered some 0.01x programmers. In fact it might be better to characterize them as -0.01x programmers, who I believe can work indefinitely without ever producing a working piece of software. Usually the best indicator of this is when the initial snaglist for a piece of work grows after the snags have been &quot;completed&quot;. Then each round of fixes becomes a kind of Hydra and finally we have to give up cutting off heads and start over.<p>I resisted believing in this phenomenon for a long time, especially because I&#x27;m no great shakes myself. But in the end it could no longer be rationally denied.

I don&#x27;t understand how anyone can say 10x programmers don&#x27;t exist. There are programmers who DRAIN value from projects and companies. The most insidious I&#x27;ve dealt with are people who assure everyone their part is going to be done on time, but come the deadline, they have nothing.<p>I am today, a 10x better programmer than I was where I started. In terms of quality, complexity, efficiency, readability, maintainability, everything. I was paid too much when I started and&#x2F;or not enough now!<p>Notch and Carmack are 1000x better game programmers than I am. Linus is a 1000x better file system and operating system programmer than me. Monty is a 1000x better database programmer than I am. DHH can build a website at least 10x faster than me and do it in a way that would contribute 100x more to the community than I could.<p>If you discard people with decades of experience. If you discard people who have specialized. If you discard the many geniuses in our field. And then if you start to make excuses at the other end, and if you narrow it to a specific set of tasks, with a specific set of complexity, then <i>maybe</i> there isn&#x27;t a huge gap. But even then, I feel that if you apply yourself to that task for a decade or two, you&#x27;ll find that you&#x27;re a 10x better programmer than you used to be.

I have a friend who is an amazing musician, fairly successful and quite inspiring. He&#x27;s no Wolfgang Amadeus Mozart and he knows it. Everyone can accept that fact.<p>Too many people approach &quot;programming&quot; like it is a simple execution of ideas. It&#x27;s more art than execution and I&#x27;ve been inspired by the creation of many amazing programmers in my long career. And in 35 years of developing technology to solve real-world problems I&#x27;ve managed to have a couple nice ideas that inspired others.<p>To me coding is a creative process, often I will code for many hours straight without a break, I will &quot;wake up&quot; afterwards like I was in some sort of trance. My wife laughing at me as I realize it&#x27;s dark outside, not because it&#x27;s still morning, but because the day disappeared and its night time again. For me coding is a form of meditation, it&#x27;s pure thought and comes from somewhere outside of my body out my fingertips like lighting into the keyboard. It&#x27;s a gentle dance with a computer to dialog with it about a problem I&#x27;m trying to solve and ways it can help me or many of its friends can help me.<p>If you don&#x27;t feel this way about coding, maybe something else is in your future, but for me coding saved my life and without it my soul would be trapped in a metal box without any way to express itself.<p>Am I a 10x coder, I don&#x27;t know, I don&#x27;t care. What I know is I am inspired by amazing coders and sometimes when I&#x27;m really lucky I inspire someone.<p>EDIT: PS: Antirez has inspired me every time I&#x27;ve looked at his creations. I wish some day others could feel that way about my work.

Speaking from my own experience, the truly amazing ultra-productive programmers often come with the caveat that they don&#x27;t spend much if any time mentoring, explaining, or sharing how they work and why. They can produce a patch in two minutes, or interactively fix up some corrupted data in a few seconds. But spending the time to demonstrate to everyone else how they did it so that the other members of the team could learn their own product better would take a lot more of their time. They&#x27;re always the ones to fix the unexpected problems, because they can figure it out and fix it before anyone else can even get a handle on what&#x27;s wrong. That&#x27;s great in the moment of crisis, but in the long run it can be devestatingly counterproductive.<p>So whether intentionally, tempermentally, just due to the constant demand for their services, or just because it&#x27;s tautological, the 10x programmers don&#x27;t actually contribute back to their team&#x27;s knowledge, which means the rest of the team stays at 1x, and whent he 10x programmer moves on to another project or company, the rest of the team flounders around while they have to figure out all the things the 10x programmer never bothered to share.

I think the phenomenon of the 10x programmer does have analogues in physical work. I feel a big part of this is having the ambition to absorb the entire problem domain. A 10x programmer does not work on just one part of a problem, they work on the entire product, each subproblem having a solution that simply flows from the constraints of the entire system. It&#x27;s this full comprehension that allows the programmer to work without costly analyzing pauses, which I bet is the root cause of the delays associated with the &#x27;regular&#x27; programmer.<p>I think I experience this in my hobby projects, when I fully own the project even when it is fairly complex, every time I spend an hour or two on an evening I pump out a few features that on a big team project would feel like they could&#x27;ve cost weeks.<p>The physical analogue I offer which might be a little far fetched is the construction worker. I have been renovating a house, doing demolition, basic construction, electrical, plumbing, and hopefully in the future finishing of the house. I&#x27;m a total novice, so obviously it&#x27;s going slow, but eventually I will have constructed (most of) an entire house. Because I do everything, there is little to no overhead (besides me having to learn everything) when switching between tasks, I own all of the project. I bet that someone who solo-renovates houses as a full time job is ridiculously productive, much more so than a general contractor managing a team of subcontractors.<p>Anyway, obviously this is all just hypothesizing based on anecdotes.

<i>&gt;The programming community is extremely polarized about the existence or not of such a beast</i><p>If we go meta and <i>generalize</i> the disagreement, the skepticism about &quot;10X&quot; is the same as the rejection of other labels such as &quot;ninja&quot; and &quot;rockstar&quot;.[1] For some, the idea of categorizing a subset of programmers with a grandiose label is psychologically distasteful. It doesn&#x27;t matter what the label is; <i>any label</i> that attempts to stratify programmers is a &quot;myth&quot;.<p>As for &quot;10x&quot; specifically, I&#x27;ll repeat what I&#x27;ve written before...<p>To make peace with the &quot;10x&quot; label, I suggest people just think of it as a <i>rhetorical figure-of-speech</i> instead of a rigorous mathematical term. We don&#x27;t get hung up when people say <i>&quot;Star Wars IV was 10 times better than Phantom Menace&quot;</i> or <i>&quot;I&#x27;m not even 1&#x2F;2 the football player I used to be.&quot;</i><p>Even if people were to use a new term such as <i>&quot;3-Sigma Programmer&quot;</i>[2] instead of <i>&quot;10X Programmer&quot;</i>, the ensuing debates would still be the same.<p>E.g. <i>&quot;Some people say 3-σ programmers write string parsing loops that are better in speed and quality than 99.7% of the other loops but that 3-standard-deviations-above-the-mean is a myth... etc&quot;</i><p>The argument pattern would be the same: take a label, <i>any label</i>, hyperfocus on some literal meaning to the exclusion of all other colloquial usage, and debate why that mathematical interpretation fails in the real world.<p>tldr: &quot;10x&quot; in discussions is more of an informal <i>ranking</i> of programmer ability and not a rigorous mathematical measurement of output.<p>[1]<a href="https:&#x2F;&#x2F;www.hanselman.com&#x2F;blog&#x2F;TheMythOfTheRockstarProgrammer.aspx" rel="nofollow">https:&#x2F;&#x2F;www.hanselman.com&#x2F;blog&#x2F;TheMythOfTheRockstarProgramme...</a><p>[2]<a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Standard_deviation" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Standard_deviation</a>

While I completely agree that some programmers can be 10x more productive than other ones, I think it&#x27;s far more common to see programmers who LOOK 10x more productive than others. It&#x27;s very hard to compare people who have different problems to solve. Solving 90% of the problem is not the same as solving 100% of the problem, and sometimes that 10% really is worth the effort.<p>I&#x27;ve seen cases where one ostensibly 10x developer comes in and solves 90% (the easy parts) of a problem. Management love him. Then he moves on to other projects and leaves a team of &quot;1x developers&quot; to deal with the 10% (which management still insist on having). This team now have to re-write everything this superstar did from the ground up without taking shortcuts this time. The time it takes makes them all look like 0.1x developers.

I&#x27;ve worked with people who could be classed as almost a 10x programmer.<p>Their code worked, but it was also incomprehensible to everyone else on the team.<p>I have found that high-speed programmers tend to develop a very personalised workflow style. They do things their way, they code their way and forget that other people may have to maintain that code.

I absolutely loved this article. Don&#x27;t get hung up on the &quot;10x&quot;, read it as &quot;good&quot;. All the characteristics Salvatore describes are the characteristics of every good developer I know, and that every developer should strive for. They make you a better artisan, but also increase your productivity. Who cares if it&#x27;s 10x, 100x or 2.5x? The important bit is growing to your personal full potential.<p>One thing that it&#x27;s missing from the post is a bit of focus on how good developers (and indeed good leaders) concentrate on <i>maximizing their impact</i>. Not only you want to be fast and reasonably accurate, but also make what you do matter. Sometimes shaving down compilation time by a couple of minutes will save each developer in the team two minutes multiple times a day for years, for example. Not all productivity wins are obvious.

10x what, though? No 10x engineer would accept a unitless quantity from uncalibrated measurements of terrible accuracy.<p>Yes, it&#x27;s obvious that some people are getting a lot more done, but it&#x27;s very hard to quantify and vulnerable to social engineering. It can be hard to spot quieter people working effectively, and it&#x27;s <i>really</i> hard to quantify those who spend their time helping others or improving team effectiveness or business communication.

I thought the research that produced the legend of the 10x programmer showed that he was 10x better than the worst programmers who were still good enough to be employed, and only ~2.5x better than the &quot;average&quot; programmer.

&quot;When the task at hand is much more rigid, with specific guidelines about what tools to use and how to implement things, the ability of a 10x programmer to perform a lot of work in less time is weakened: it can still exploit “local” design possibilities to do a much better work, but cannot change in more profound ways the path used to reach the goal, that may include, possibly, even eliminating part of the specification completely from the project, so that the goal to be reached looks almost the same but the efforts to reach it are reduced by a big factor.&quot;<p>This is one of the reason working in software sucks so badly these days. You&#x27;ll inevitably be forced to work with lesser tools in more ceremonial ways, which takes away most of the leverage from experience and skill; effectively dragging everyone down to the lowest common denominator where everything is done according to some stupid, over engineered specification.<p>And one of the beefs people seem to have when I share my code publicly. Cutting corners and side-stepping complexity is where coding turns to art for me, where the fun begins; which means that many of my programs look like toys in comparison to &quot;serious&quot; software. Yet they still manage to get the job done for less effort, and a closer look reveals that the simplicity is carefully engineered. I just don&#x27;t have much time or patience for ceremonies these days.

I&#x27;d argue that it&#x27;s greater than that these days, many programmers really just can&#x27;t do what a lot of good programmers can do. Even if they&#x27;re given all the time in the world they&#x27;ll just never get a result. So whats that make them infinityX programmers?

It seems to me a few people fit their jobs&#x2F;environment others don&#x27;t. The few who fit are productive, those who aren&#x27;t where they are supposed to be are not. We should be discussing how to help people learn what environment&#x2F;job works for them and empowering them, instead of trying to focus on the mythical 10x programmer. Don&#x27;t get me wrong some programmers are very talented (and thus more productive), but I think this is due in great part to their ability to add value in a particular setting.<p>A 10x games programmer in a small studio could easily become a 0.1x web dev in a big web dev team.

From what I&#x27;ve seen from working on two projects with more than 100 engineers is that they break down into these categories:<p>20% - Not productive. They can&#x27;t get their tasks done, and after awhile, no one even expects them to. They get routed around. 65% - Neutral. The quality problems and technical debt they incur matches their productive work. 12% - Net negative. They introduce hard to fix bugs and technical debt beyond their productivity. 3% - Gods. They do almost all the productive work. Without these types of people, no large project would ever get done.

There are so many factors at play in team and client environments, so the best benchmark to use is your own productivity as a programmer.<p>1. Solving problems for the Nth time instead of the first leads to substantial gains in productivity, easily 10X gains on your first attempt.<p>2. Architectural decisions add another multiplier on the above: picking the wrong database type, structuring and reorganising your models, spending time to design ahead vs coding right away, all can &#x2F;10 or 10X your project easily from fixes and re-dos alone - combine both 1 and 2, and you have potential 100X gains.<p>3. Risk-distributing the project work: eliminating the worst 5% as the author says, and&#x2F;or writing the most complex parts first to reduce risk of massive rewrites in case something doesn&#x27;t meet expectations in its most critical functionality.<p>4. Having competent business requirements providers who won&#x27;t move the ground beneath your feet. You can be 10X or 100X more productive when writing new code, and that much slower when rewriting someone else&#x27;s bad decisions. It&#x27;s no different than trying to build a skyscraper on foundations built for a garage.<p>Stack the above as A x B x C x D and you can see why you might be able to beat your past self 10X or 100X and more between projects. Having teammates who can beat you is even better if you can learn from them and accelerate your own progress by skipping time consuming mistakes.

Some productivity killers:<p>- Distractions<p>- Feature creep<p>- Poor code organization: coupling, action at a distance, cyclomatic complexity<p>- Noise: comments that do not get to the point. A tool to mitigate this is <a href="https:&#x2F;&#x2F;foxtype.com" rel="nofollow">https:&#x2F;&#x2F;foxtype.com</a><p>- Hacks and lack of consistency<p>- Lack of automation: tests, builds, deployments<p>Regarding hacks, imagine what would physics equations would look like if a fundamental constant was wrong. All equations would need to compensate for it by including some arbitrary constant making everything more complicated. That is what messy code bases look like, layers of lies to compensate for lies. Clean code is more straightforward, easier to work with.<p>Regarding iterations... does the army run an exercise with soldiers and trucks and live ammo each time a general wants to test an idea? No. They use simulations, and only the ones that look promising are turned into exercises. So rather than asking engineers to prototype some throwaway idea, get your hands dirty and use Powerpoint and your imagination, stress the idea, then build it. And if it&#x27;s built, keep it in a feature branch until you&#x27;ve actually decided to keep it for good.<p>When a car is built, engineers tell designers to modify their concepts in order to make the production more cost efficient. Same in software... be prepared to negotiate requirements if that is in the best interest of the project.

All programmers have different output. How is it even a debate? Some people are more productive than others. Just like one novelist takes 10 years to finish his novel another writes 2 every year.

The whole 10x programmer thing is just interpreted wrong. The original statement was that the best are 10 times better than the worst.<p>I&#x27;ve certainly worked alongside programmers who&#x27;s output is so bad that I would consider myself both 10 times better and 10 times faster. And I wouldn&#x27;t even consider myself a top teir programmer. They are often people who&#x27;s contributions to the project are net negative in that they actually require additional work from someone else to go clean up their mess afterwards.<p>Stop imaging a mythical coder who is 10 times better than everyone else, and instead think of the worst coder you&#x27;ve ever worked with who is 10x worse than everyone else. There is your 10x&#x27;er. We are nearly all 10x&#x27;ers when compared to the bottom few percent.

The programmer is only as good as his manager. If a 10x programmer is working under the leadership of a 1x programmer, he will probaby turn into a 0.5x (due to lost motivation). A 10x programmer in a decision-making position will actually bring up the output of all other programmers. In reality, a 10x programmer doesn&#x27;t have to be fast at programming themselves, they just have to be able to foster good habits which make everyone else faster. That&#x27;s why it&#x27;s dangerous to promote &#x27;fast programmers&#x27; to leadership positions. Fast doesn&#x27;t mean good - In fact, most of the time, &#x27;fast&#x27; is bad&#x2F;suboptimal (especially when it comes to design decisions).

You forgot one... sacrificing the efficiency of others to gain multipliers. By undermining team communication, future maintainability, etc, the 10x can appear much faster. This speed is gained not by truly being more efficient, but rather by the coding equivalent of maxing out your credit cards and mooching off your friends.<p>It looks good at the present, but the team pays for it in the long run - long after Mr 10x (it&#x27;s always a guy, right?) gets fed up with the process bloat and criticism and whining and leaves for greener pastures.<p>I&#x27;ve cleaned up after 10x programmers.

I think the significantly better performer is something we see in all areas like sport, music and craft.<p>I think Anders Ericsson does a good job of explaining the phenomenon in his book Peak: <a href="http:&#x2F;&#x2F;uk.businessinsider.com&#x2F;anders-ericsson-how-to-become-an-expert-at-anything-2016-6" rel="nofollow">http:&#x2F;&#x2F;uk.businessinsider.com&#x2F;anders-ericsson-how-to-become-...</a><p>What we should be doing is looking to create companies that can allow workers to reach and sustain peak performance in all areas, not just coding.

Antirez is a 10+x programmer in most peoples&#x27; definitions. Writing nice to read code fast. So it is good to read this from him but then again he always appears quite humble.

Somewhat related, there&#x27;s a very good post here: <a href="http:&#x2F;&#x2F;lesswrong.com&#x2F;lw&#x2F;l8&#x2F;conjuring_an_evolution_to_serve_you&#x2F;" rel="nofollow">http:&#x2F;&#x2F;lesswrong.com&#x2F;lw&#x2F;l8&#x2F;conjuring_an_evolution_to_serve_y...</a><p>It&#x27;s about the unintended side effects of trying to be a &#x27;Natural Selector&#x27;. One example is selecting individual hens on egg output to create a breed of high-egg producers. The result was mean chickens which had gains b&#x2F;c they were very aggressive. The breed needed to have their beaks clipped otherwise they would kill each other. When productive groups rather than productive individuals were selected though, they got the desired effect. (Though in another example I can imagine selecting for mean group behavior)<p>Another example was trying to selectively evolve animals that would self-limit reproduction. (to avoid overpopulation and resource over-consumption) The end result was selecting for cannibalism.<p>In organizations, the equivalent of propagating a feature are the hiring stage and the promotion stage. Whatever you hire for, or promote for, will be the trait that&#x27;s optimized. Whatever the side effects may be... (e.g. Enron)

The main difference I have noticed between programmers isn&#x27;t how fast they get their projects done, it&#x27;s the amount of technical debt they leave behind.

From experience, it comes down to luck, but in a sense luck = good preparation &#x2F; pre-built components toolbox.<p>I can be 10x, even 100x when working on something I&#x27;ve already solved &amp; have &quot;big&quot; set of components ready to plug in (with a little bit of tweaking). The more stuff you have, the &quot;luckier&quot; you are. It&#x27;s also ability to spot patterns &amp; good memory &amp; being in a flow.

Off-topic, but I know that Antirez has mentioned in the past he is always working on his English grammar.<p>&gt; Surprisingly the ability to use basic imperative programming constructs very efficiently in order to implement something is, in my experience, not as widespread as one may think.<p>Those words are spun better than I could do, and I&#x27;m a native English speaker. Bravo!<p>Maybe something missing from the list is hard work and long-term dedication ;)

I think this myth stems from a lack of understanding of what we consider to be &quot;work&quot;. For example, one developer could crank out 10x as many features as their peers, but never consider deploying or maintaining. The reality is that they are making everyone else slightly less productive. Similarly, they could work on 1&#x2F;10th of the features, but help their 10 peers become twice as effective. Taking this even further, there&#x27;s developers who can complete 1&#x2F;100th of the features as their peers, but help thousands of other developers become 5% more effective.<p>In my mind, the mythical 10x programmer is the person that can complete business objectives while helping make those around them more effective. This isn&#x27;t actually a myth, and &quot;10x&quot; is a completely arbitrary number that doesn&#x27;t mean anything. It might as well be 2x or 1.1x -- they all mean the same thing to me. They can do their work at 1x speed, a baseline set by the developer in question and not their peers, but they can simultaneously help others around them be more productive.

Two classics on design to flesh out Antirez&#x27; thoughts:<p>Parnas’ ”On the Criteria To Be Used in Decomposing Systems into Modules” <a href="https:&#x2F;&#x2F;www.cs.umd.edu&#x2F;class&#x2F;spring2003&#x2F;cmsc838p&#x2F;Design&#x2F;criteria.pdf" rel="nofollow">https:&#x2F;&#x2F;www.cs.umd.edu&#x2F;class&#x2F;spring2003&#x2F;cmsc838p&#x2F;Design&#x2F;crit...</a> [PDF]<p>Christopher Alexander’s Notes on the Synthesis of Form <a href="http:&#x2F;&#x2F;www.hup.harvard.edu&#x2F;catalog.php?isbn=9780674627512" rel="nofollow">http:&#x2F;&#x2F;www.hup.harvard.edu&#x2F;catalog.php?isbn=9780674627512</a><p>Both get deep into how a design emerges from the <i>relationships among</i> what Antirez is calling &quot;sub-tasks&quot;. Antirez refers briefly to these relationships in the &quot;Design sacrifice section.&quot; Parnas and Alexander put them, correctly I believe, at the heart of the craft.<p>Parnas was a software engineering authority. Alexander went on to write A Pattern Language, from which the software community derived &quot;design patterns&quot; as a foundational idea.

I like the article in general, however sometimes i think that an ideal solution in terms of design sometimes can&#x27;t exist, I mean a program mostly grows after usage and gets many changes over time. sometimes something which was quite good, is now rusty and bad.<p>I mean at the moment I&#x27;m actually changing my code that was simple at first, but over time more and more things were added and it started to complex. The thing I&#x27;m doing right now is getting rid of the complexity to add another future. Well mostly I think a big problem is that many people actually think about the design too much, since the design of a program will eventuelly be changed anyway. What worked for me was design something that works in most cases and grow that path or throw it away if it sucks.<p>btw. I love what antirez did and does for the community of programmers.<p>I always use a redis client to teach people more about network programming in java. It&#x27;s a extremly simple, but still powerful command set&#x2F;protocol. I hope he can keep up his work.

Productivity is all about the choices that you make.<p>It&#x27;s the essentially the same as optimizing a computer program: you can&#x27;t make it do more work faster, you can only make it do less work.<p>And if &#x27;less work&#x27; means the problem is solved anyway then you are a &#x27;faster&#x27; programmer, even if you produce fewer lines of code than your &#x27;slower&#x27; counterpart.

When the overall quality &#x2F; delivery metric of an individual &#x2F; team tends to 0, then the ratio between a good (normal) programmer over that will tend to infinity.<p>Probably the biggest aspect not dealt with in these writings along with the discussion around it (is there or is there not such a beast) is bias.<p>For example, selection bias: e.g. my view over what was the best &#x2F; worst programmer was much different when working in different teams. I found out there could be much worse than what I thought is the worse. Then I learned that there could be much worse... It&#x27;s like a fractal :) As you notice these differences a 10x difference doesn&#x27;t seem that crazy. It&#x27;s really things that should take a few weeks, which in turn take months or years or never get done.<p>Also like any other optimization problem, optimizing software development is about hitting a moving target. When the team is balanced, it may be the process that will become a bottleneck, etc.

Even though I agree with all the points made by the author, the notion of 10x programmer reminds me of one-man army movies like Rambo and it&#x27;s equally ridiculous. Software development is a collaborative effort, not a contest where whoever commits more LOC or finishes more tasks wins. It&#x27;s not that hard to be 10 times more productive than anyone else if you built something from the scratch, possibly reinventing the wheel instead of using common libraries&#x2F;frameworks, wrote no documentation and you&#x27;re not really willing to share your knowledge with other developers. Sadly, this happens - see e.g. <a href="http:&#x2F;&#x2F;thedailywtf.com&#x2F;articles&#x2F;the-inner-json-effect" rel="nofollow">http:&#x2F;&#x2F;thedailywtf.com&#x2F;articles&#x2F;the-inner-json-effect</a> [edit: added link]

I think the real key is simply experience. From what I&#x27;ve seen a 10x programmer is simply one who has worked on 10x as many projects as the baseline. The things the article points out are common traits of such people. A 10x programmer has worked on several teams and has lots of side projects.

Kent Beck has an article that is a nice complement to this one:<p><a href="https:&#x2F;&#x2F;www.facebook.com&#x2F;notes&#x2F;kent-beck&#x2F;mastering-programming&#x2F;1184427814923414&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.facebook.com&#x2F;notes&#x2F;kent-beck&#x2F;mastering-programmi...</a>

Perhaps it&#x27;s worth stressing organisational factors in productivity.<p>Often when you find someone who&#x27;s really good at what they do, they&#x27;re the type of person who loves their work, and they&#x27;ve managed to find employment in an environment that suits them. The two are of course mutually helpful.<p>Also keep in mind it can be very hard to find more than one space for such a person. It&#x27;s like how certain soccer teams are built around a particular star player; everyone else plays to suit that guy, and it would be hard to fit a clone if you had one. Others may well be suited to a star role, but happen not to have landed the role. Watch the Tour de France to see what happens when the lieutenant steps up to the captaincy. I can often be dramatic.

It&#x27;s like in driving - most people think they are above average, see <a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Illusory_superiority" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Illusory_superiority</a>

The few times I&#x27;ve had the luck of working with 10x developer (or Nx for some unknown value of N) what I noticed was raw intelligence, insatiable thirst for learning and curiosity, and an intense focus bordering on obsessive.

This was a great read.<p>BTW I have always known that the 10x programmer exists.<p>A sufficient proof is that on good days (with proper motivation, concentration, no interruptions, enough coffee etc.) I&#x27;m 10x the programmer I am on bad days :)

When considering the implementation of a new system, sometimes considering the relative value of the path is a better and more profound action than than taking it. Similarly, implementation of a system does not necessarily imply deep comprehension, correct or intuitive forward-looking design, composability, repurposability, security, or any other property.<p>In short, as the saying goes: <i>Decisiveness is overrated</i>.[0]<p>[0] <a href="https:&#x2F;&#x2F;github.com&#x2F;globalcitizen&#x2F;taoup" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;globalcitizen&#x2F;taoup</a>

Since people have been objecting to the title and objecting to objecting to the title, we replaced the title with a representative phrase from the article. Let&#x27;s focus on the body now.

The part on perfectionism is also well worth repeating; pretending to be perfect, and&#x2F;or bullying others into the same madness is a waste of energy and oxygen that could be better used to move forward.<p>&quot;Perfectionism and fear of external judice insert a designing bias that will result in poor choices in order to refine a design only according to psychological or trivially measurable parameters, where things like robustness, simplicity, ability to deliver in time, are often never accounted for.&quot;

Provided your business will never need more than one and only one expert programmer who may not work in a team and this expert programmer will never leave your business and will always be trustworthy to do the right thing and they can support&#x2F;maintain their own work in your production environment then a 10x programmer is a great idea.<p>Otherwise consider other human qualities such as communication skills, adaptability and critical thinking as more valuable than raw coding skill.

There is no such thing as a &quot;10x programmer&quot;, only &quot;1&#x2F;8 environments&quot; i.e. teams&#x2F;environments where the normal programmer is 1&#x2F;8th as productive as industry norms, such that a mere 1.25x programmer is 10x productive.<p>..and an environment that fosters such low productivity norms, probably also gets it&#x27;s developer productivity <i>measure&#x2F;metrics</i> wrong as well, so you don&#x27;t even need a 1.25x for the perception of a 10x...

&quot;The number of hours spent writing code is irrelevant without looking at the quality of the time. Lack of focus can be generated by internal and external factors. Internal factors are procrastination, lack of interest in the project at hand (you can’t be good doing things you do not love), lack of exercise &#x2F; well-being, poor or little sleeping.&quot;<p>Get your ass up from the chair and go outside to exercise if you wanna reach Antirez levels of mastery

The 10x&#x2F;-10x decisions are made by the architects, and the decisions tend to involve where network&#x2F;codebase&#x2F;layer&#x2F;service boundaries are drawn.

I&#x27;m not sure if it&#x27;s only me, but I started to see a lot of 1&#x2F;10x programmers in startups. They can know all newest &quot;cool&quot; technologies, go to various conferences, have a lot of followers on twitter and reputation on stackoverflow, but when it comes to the real work, their value for the company is around zero, usually can&#x27;t even solve simplest tickets (probably busy tweeting stuff?).

On a yearly task with little code reuse my productivity went from 3 weeks to 3 days the second time.<p>In another migration measured the time to cut and paste and concluded a day of grind was better than a week of scripting.<p>Many tasks have a thin path to completion surrounded by cliffs on either side. Experience teaches when to focus on the critical path only vs when to take a wider view.<p>There&#x27;s easily a 10x productivity boost there.

I would add &quot;reading the manual&quot; to the list of things that people don&#x27;t do enough of. I&#x27;m often shocked by people just diving into coding instead of doing the research to see if something has already been provided for you. You will go very far if you understand what the technologies you use are capable of doing.

10X? Steve Jobs said more than once in interviews that he saw a 200X difference among professional programmers.<p>Which I think is bull, of course. You can&#x27;t quantify things like that. Some people are better than others, but any claim of 10X or 200X is missing a much bigger picture of how humans contribute to each other&#x27;s work.

Honestly the section about debugging skills needs to be much higher in the article. Debugging skills are essential to learning legacy applications you are thrown into and understanding how your code works in general. It amazes me when I see an engineer with 5+ years experience who cannot hook up a remote debugger to their application.<p>My number one observation about productivity usually revolves around how an engineer attacks a problem and handles scope creep. There are some programmers who can get a set of requirements, and like a trained surgeon get in, fix the big bleed and get out. While they are in there they might fix a couple close issues but they are not re-architecting the whole application. Then there are others who see all the problems, they notice this problem there, and that problem here and keep asking what does this all mean and it eventually cripples them. They spend some much time seeing all the problems, that they never get around to solving the one they were tasked to fix.<p>Once you realize you won&#x27;t understand it all from the beginning and you can&#x27;t fix every issue you see. You become a much more effective engineer.

Being able to see edge cases and bugs before they happen will kill your productivity. I think the hardest part is to ignore those and deliver. If no one uses the software, then no harm done, and if the software get popular you will hopefully get funds to pay back the tech debt.

&quot;Sometimes in order to gain focus, extreme measures are needed. For instance I only read emails from time to time and do not reply to most of them.&quot;<p>This is far too extreme and turns you into a counterproductive team member. Like everything in life, a balance demands to be struck.

A good read but I doubt one of his assumptions:<p><pre><code> &quot;you can’t be good doing things you do not love&quot; </code></pre> I believe you can be very competent at doing things you tolerate. It&#x27;s time to dispel the notion passion == quality of work.

In my experience, there are 10x engineers but I often noticed they are 10x only because they tend to work alone. As soon as you start pairing them with another 10x engineer, they become 0x because they tend to fight about every decision.

This topic is addressed by Greg Wilson in his exceptional talk: What We Actually Know About Software Development, and Why We Believe It’s True<p><a href="https:&#x2F;&#x2F;vimeo.com&#x2F;9270320" rel="nofollow">https:&#x2F;&#x2F;vimeo.com&#x2F;9270320</a>

OP says 10X programmer is a myth. Then describes the exact characteristics that make some programmers 10 times more productive than others. Maybe not so much a myth.

10x programmer is like Linus, who programs and set structure of the working code. rest of the feature addition and bug solving can be done with 2x programmer.

I would mention also <a href="http:&#x2F;&#x2F;yosefk.com&#x2F;blog&#x2F;?s=10x" rel="nofollow">http:&#x2F;&#x2F;yosefk.com&#x2F;blog&#x2F;?s=10x</a>

Since this article relies on the premise that a &quot;10 X&quot; programmer makes any sense, I&#x27;m going to spend time refuting that central point.<p>If programmer productivity, or software developer&#x2F;software engineer productivity, is measured as a linear function, then it really does no service to the field. Beyond looking at network effects from the impact developers have on each other, there is no universal measure of productivity. It would be more believable to say that certain developers have twice as many or five times the number of lines of code produced that are defect free, than to say that they achieve a certain level of productivity.<p>The two reasons that this should be immediately seen as nonsense to anyone in the field is that first of all, computer problems deal with asymptotic complexity. In the asymptotic world, linear functions are outshined by constant, logarithmic, polynomial, and exponential functions. Furthermore, the prevailing wisdom among programmers is that &#x27;less is more&#x27;. That&#x27;s why we talk about minimizing lines of code and trying to avoid the most bugs by leaving the least surface area for them to exist to begin with. Introducing a measure where &#x27;more is better&#x27; is sort of at odds with this philosophy and should be viewed skeptically.<p>Finally, if you look at the great successful innovative products in software, and technology in general, you&#x27;ll see that they often make use of new inventions. There&#x27;s no way to compare an inventor in terms of productivity by saying one has 10 times as many patents as the other, or to compare a mathematician by the number of papers or pages published. The important difference is the quality of the invention or discovery. The engineers at AltaVista and Yahoo could have been extremely productive, but without a revelation like Page Rank, they never could have competed with Google back in the early days of search engines. Here, two college students writing a small amount of code outperformed larger companies. This has nothing to do with productivity and everything to do with talent.<p>This leads me to believe that the &quot;10 X&quot; slogan is a product of marketers, head hunters, and pop psychologists. It has no bearing on the field of computer science and it is a harmful concept because it perpetuates the idea that software developers are replaceable parts rather than unique contributors.

To me programmer that knows devops is the 10x programmer in the right company.

The article is unreadable on a mobile device.

The quantity and quality of grammatical errors in the piece were finely calibrated to keep me reading it to the end. A curious effect.

Maybe one things missing: &#x27;specific domain knowledge&#x27;.<p>At least 1&#x2F;2 of programming is learning. You can make a basic Android App, but have you learned how to do &#x27;deep linking&#x27;. Well, it can take a full day the first time because it&#x27;s awkward, and you have to understand a few things, and set a few things up server side.<p>Second time - it&#x27;ll take 1 hour.<p>There&#x27;s a lot of that.<p>If you&#x27;re really comfortable with XMLHttpRequest, and know the ins and outs of post&#x2F;form structures - well then you can do something quickly in it. If you don&#x27;t well, it could take a bit to learn for a new dev.<p>Those things add up a lot. It takes several years to get comfortable with the variety of tools and tech necessary to be good.

Fixed width font on a blog? Is it still 1983 out there somewhere?<p>Maybe you&#x27;d be 10x more productive if it didn&#x27;t hurt everyone&#x27;s eyes to read your writing.

Lol, HN, the place where people try to answer to an expression, a saying or an image by being technically correct.<p>Your comment could be a line from Sheldon in the Big Bang Theory :)

10x programmer = very good programmer. End of discussion.

I am the mythical 1&#x2F;10x programmer. Sadly currently not available for hire. :)

The 10x programmer is a myth perpetuated by senior management to get compliant submission from naive young code monkeys. End of discussion.

Sigh. Why do we keep perpetuating this myth? From the words of the greatest genius of the 20th century<p>“Right. I don’t believe in the idea that there are a few peculiar people capable of understanding math, and the rest of the world is normal. Math is a human discovery, and it’s no more complicated than humans can understand. I had a calculus book once that said, ‘What one fool can do, another can.’ What we’ve been able to work out about nature may look abstract and threatening to someone who hasn’t studied it, but it was fools who did it, and in the next generation, all the fools will understand it. There’s a tendency to pomposity in all this, to make it deep and profound.” – Richard Feynman, Omni 1979<p>Stop the pomposity. Please.