(public).sospep.subjects ~ view article ~ the-mythical-10x-programmer

<h1 style="text-align: center;">the mythical 10x programmer</h1>
<h2>[WHAT]</h2>
<ol>
<li>] by antirez @ antirez.com - dev at redis.com, explains what he feels are the traits that make a highly productive programmer</li>
</ol>
<h2>[WHY]</h2>
<ol>
<li>]&nbsp;</li>
</ol>
<h2>[WHERE]</h2>
<ol>
<li><strong>] READ THE FULL ARTICLE</strong></li>
<ol>
<li>]&nbsp;<a href="http://antirez.com/news/112" target="_blank">http://antirez.com/news/112</a></li>
</ol></ol>
<h2>[WHEN]</h2>
<ol>
<li>] 2016-01-0d</li>
</ol>
<h2>[EXAMPLE]</h2>
<div>
<p><strong>A 10x programmer is</strong>, in the mythology of programming, <strong>a programmer that can do ten times the work of another normal programmer,</strong></p>
<p><strong>The programming community is extremely polarized about the existence or not of such a beast:</strong> who says there is no such a thing as the 10x programmer, who says it actually does not just exist, but there are even 100x programmers if you know where to look for.If you see programming as a &ldquo;linear&rdquo; discipline, it is clear that the 10x programmer looks like an irrational possibility.</p>
<p><strong>Even when a programmer does not participate in the actual architectural design of a program, the act of implementing it still requires a sub-design of the implementation strategy.</strong></p>
<p><strong>So if the design and implementation of a program are not linear abilities, things like experience, coding abilities, knowledge, recognition of useless parts, are, in my opinion, not just linear advantages, they work together in a multiplicative way in the act of creating a program.</strong></p>
<p><strong>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: i</strong>t can still exploit &ldquo;local&rdquo; 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.</p>
<p><strong>&gt;&gt; CHECK OUT THE FULL ARTICLE TO DIG INTO EACH ONE OF THESE AREAS</strong></p>
<ol>
<li>* Bare programming abilities: getting sub-tasks done</li>
<li>* Experience: pattern matching&nbsp;</li>
<li>* Focus: actual time VS hypothetical time</li>
<li>* Design sacrifice: killing 5% to get 90%</li>
<li>* Simplicity</li>
<li>* Perfectionism, or how to kill your productivity and bias your designs</li>
<li>* Knowledge: some theory is going to help</li>
<li>* Low level: understanding the machine</li>
<li>* Debugging skills</li>
</ol></div>
<h2>[HOW-TO]</h2>
<ol>
<li>]</li>
</ol>
<h2>[REFERENCE]</h2>
<ol>
<li>] # # - CREATE-article# 5624 (this) - the mythical 10x programmer</li>
<li><strong>&gt;td]&nbsp;<a href="http://antirez.com/news/112" target="_blank">Qualities that I believe make the most difference in programmers&rsquo; productivity</a>&nbsp;(antirez.com),SRC=bohn-2017-02-28(#)/<a href="https://news.ycombinator.com/item?id=11859395" target="_blank">comments</a>(#)&nbsp;</strong></li>
<li><strong><br /></strong></li>
</ol>
<h1 style="text-align: center;">&nbsp;</h1>

~ view article ~ Chapter] index FROM [ Book] analysis-software-developer IN [ libraries] technology-developer-software