What distinguishes great software engineers? (2019) [pdf]

In 50 years of programming I&#x27;ve worked with a few. One characteristic is a deep understanding and command of all that they touch.<p>For example, I worked with Bill Schelter (GNU Common Lisp). In 1980, prior to the Internet, we were working on a problem (tail recursion). He was using the emacs editor and he found a bug.<p>Bill stopped what he was doing, fetched the sources for emacs (using ftp), found the source of the bug, fixed it, and sent off a patch. After that he restarted emacs and continued right where he left off. It was a virtuoso performance. It was like watching Victor Borga (<a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=dKeqaDSjy98" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=dKeqaDSjy98</a>).<p>I know a guy who plays guitar. He can listen to a performance and repeat it as easily as I can type what I read. He can transpose keys, add riffs, change tuning &quot;on the fly&quot;, and even play thru with a broken string, adjusting chords to the new &quot;5 string&quot; form. He also knows guitar characteristics, pedal effects, etc., basically &quot;all things guitar&quot;.<p>Great software engineers I&#x27;ve known seem to have complete command of all of the ideas, tools, and techniques. They understand their tools &quot;all the way down to the metal&quot; and all the way &quot;up to the esthetics&quot;. You can see great people in all crafts (like woodworking).<p>They also write beautiful &quot;crafted&quot; code. I&#x27;m keyboarding a FORTRAN punched card deck (for an historical museum). You can see from the code that the author wrote clean, careful, and clear code. You can almost feel how good he was.<p>Greatness isn&#x27;t about &quot;team player&quot;, &quot;hard working&quot;, &quot;good at time estimation&quot;, or anything &quot;social&quot;. Greatness is a property of the person, a deep love of the craft, and a focus on &quot;doing it right&quot;.

Can&#x27;t claim I read the entire thing, but I got down to methodology and must say it doesn&#x27;t look particularly impressive. The study is a survey sent out strictly to Microsoft employees asking them how they rank a set of pre-defined criteria about what makes a great software engineer. That criteria includes things like &quot;hard working&quot;, &quot;honesty&quot;, &quot;team player&quot;, &quot;creates a safe haven&quot; etc...<p>Obviously no Microsoft employee is going to say something like &quot;Lazy liars who treat people like crap make great software engineers.&quot;<p>At the very least you&#x27;d expect a study to have a control group in order to filter out these useless questions. For example send a similarly worded survey to a group of grocery cashiers and ask them if they think attributes such as &quot;Hard work, honesty, integrity, long term thinking, being a team player.&quot; make someone a great engineer.<p>My hypothesis is you&#x27;d end up getting similar answers from taxi drivers as you would from Microsoft employees and consequently that there isn&#x27;t much value derived from this survey or their selection of participants.<p>Anyways, I&#x27;m by no means an expert and could be misjudging this research but frankly it looks to be beyond useless.

It’s interesting there are so many different answers given to this question whenever it is asked. If we asked, “What makes a good surgeon?” or as pointed out in another comment, “What makes for a great basketball player?” it seems that there would be less debate.<p>It seems to me that this debate is related to another question, “Why do so many software projects fail when you don’t see any skyscrapers collapsing under their own weight?”<p>If you could build a skyscraper according to rules limited only by our imagination, then perhaps we’d see a lot more of them collapsing. And given that frequency of failure, we’d see a lot more debate about what makes for excellence in skyscraper-building.<p>Maybe a better question to ask is, “What makes for a poor software engineer?” That question seems a lot easier to answer. A poor engineer takes a long time to write unreadable, unmaintainable, buggy code that only partially solves problems that no one has. Ironically, such code often goes unnoticed by its very nature: it takes a lengthy period of time to even come into existence, when it does exist it is so buggy that its failure seems related to bugs rather than that it solves no problems, and the unreadable nature of the code is mistakenly attributed to essential complexity rather than incidental.<p>And that last point is where I think we get closest to an answer: Good engineers reduce complexity. Bad engineers magnify complexity.<p>Tolstoy wrote, “All Happy families resemble one another, but each unhappy family is unhappy in its own way.” It seems to me that the same could be said of software engineers.

As other commenters have noted, this is a quite generic article with very little specific to software engineering. For a much more informative take on the same topic, read &quot;Norris Numbers&quot; by Lawrence Kesteloot:<p><a href="https:&#x2F;&#x2F;www.teamten.com&#x2F;lawrence&#x2F;writings&#x2F;norris-numbers.html" rel="nofollow">https:&#x2F;&#x2F;www.teamten.com&#x2F;lawrence&#x2F;writings&#x2F;norris-numbers.htm...</a>

Imo great engineers produce a lot of good to great quality work fast. They care about the big picture and get involved with the actual domain they&#x27;re working in. They see code reuse opportunities and friction company wide vs only whatever team they&#x27;re on. Great software engineers will write tools, packages, and guidelines that the entire company can use- not just their small team. They know how to standup to management and produce quality work that users actually want.

A steaming dumpster fire of a paper that assumes greatness can be determined by a ranked numerical model, then smears this assumption all over the floor and carpet.<p>The algorithmic HR startup that inevitably follows will be gamed into oblivion.<p>Greatness is by acclamation, not quantification.

I think if you follow John Carmack&#x27;s finger files and his Twitter account you can form your own opinion as to how it works.<p>That guy is clearly a top 10 engineer and he hides little about his thought process. His appearance on the Joe Rogan Experience was great too.

Great software engineers create&#x2F;build software only as a last resort, once all other options have been exhausted. :)

A bit OT - but...I find it a bit interesting, even fascinating, how people in the field of software seem to absolutely obsess over <i>greatness</i> in individual engineers.<p>You see this is in many shapes and forms - whether it&#x27;s a discussion what makes one a true &quot;10x&quot; engineer, what lifestyle habits will result in excellent engineers, what personality traits to look after when searching for world-class software engineers. etc.<p>Having been in many other (technical) fields outside software engineering, I&#x27;ve never seen the same mentality or obsession there.

The more experienced I get, the more doubtful I am about every code. In the end I will be an ermit on a mountain imagining a code base that does not evolve into a monstrous mess.<p>Honestly, I envy the young Mavericks who code shit and get work done. They at least sleep at night.

Weird to me how down these comments are on what I read as the main message of the paper, i.e. that engineers aren’t just code monkeys.<p>Being a “great engineer” is not strictly determined by technical ability; in fact, social ability plays a big role in a so-called “individual contributor role.”

Question for everyone. Doesn&#x27;t everyone know in the industry what makes great software engineers? And that usually there are only &quot;blockers&quot; that stops you from being great?<p>Let me give an analogy. If you&#x27;re paid to play basketball wouldn&#x27;t you know what makes a great basketball player? If you&#x27;re playing pro basketball, you can be a great basketball player. The only reason why you can;t be great is because there are certain things outside of playing basketball that you have to worry about.<p>I guess i&#x27;m asking cause it&#x27;s kinda annoying when people tell me what makes a great engineer. Anyone I know who has been doing this a few years knows what makes a great engineer. It doesn&#x27;t mean they want to be a great engineer because the trade-offs arent just worth it

A good engineer will prob write some code instead of reading this nonsense

The ability to negotiate and to get properly paid for all the hard work and education they invested in over all the years.

I think this thread is not defining ‘greatness’ well enough. If we’re <i>really</i> talking about greatness, there should like 0.5% of HN that fit the bill, or something like that across the industry.<p>Reframe the question, who are our Bachs and Beethovens? Were they great because they created a lot of good work fast? Is good even enough? None of that shit defines greatness.<p>Our best developers came from open source. The stuff they made was undeniable. Is being super productive the same as making undeniably useful programs(languages, tools)?<p>Look at our greats and I think you’ll see they made a breed of work that sits outside workplace metrics of productivity, the same way a Hitchcock was genre defining.

(skimming intro &amp; conc) reads like a joke paper:<p>- their top characteristic is &quot;writing good code&quot;<p>- they censored the specific VCS<p>- they describe their insights as (<i>inter alia</i>) &quot;ecologically valid&quot;<p>----<p>This is HN, so... I&#x27;d approach the title as &quot;when is x10 possible?&quot;<p>- insight of a far simpler or faster etc implementation (e.g. better choice of modularity, factoring out hidden commonality, dynamic programming);<p>- insight about a better way to achieve the end result - might be no code at all<p>So I&#x27;m talking about insight. What personal qualities lead to insight? (note that there isn&#x27;t always a better way to be found, so personal qualities don&#x27;t guarantee it)<p>- be really really smart. Especially, large working memory, to be able to see connections. Or at least be able to load in (cram) the information temporarily.<p>- the ability to step back and notice the bigger picture. Executive function.<p>- ability to manage stress, so they have the breathing space to do that (the wisest engineers will choose a workplace that makes this easier)<p>Skill in proofs is a predictor: flexibility, handling complexity, managing the top-level purpose as well as the detail (forest-for-trees), noticing connections. Mathematical knowledge itself can help sometimes too.<p>But probably the skill in any intellectual discipline is an equally good predicator e.g. philosophy, history, law

OK, so I admit I just started with the abstract, but the first item listed is &quot;writing good code&quot;. Umm, I would hope that is kinda part of the definition? I was actually looking for some valuable insight (e.g. <i>how</i> are great software engineers able to consistently write good code) but I didn&#x27;t see it in this report.

Warning: this is a survey on what people THINK makes great engineers.

There&#x27;s only 1 rule: Shipping code that delivers value to users.

The word &quot;retirement&quot; doesn&#x27;t appear in this document.

Well I guess that makes me about average.<p>I&#x27;m generally liked where I end up working, but tend to just do stuff on my own. I&#x27;m polite, but don&#x27;t go out of my way to interact with others typically.<p>I do check the boxes on the code quality stuff however, especially writing code that plans for the future.

&gt; 1. Introduction<p>&gt; “At the end of the day, to make changes [to software], it still takes a developer, a butt in a seat somewhere, to type [Source Control System] commit. — Dev Manager”<p>Not entirely relevant, but this opening comment just struck me as funny.

&gt;&gt; Two attributes received negative ratings —“A great developer should not have this; it isnot good” [...] and hardworking [...]<p>I found this amusing but not necessarily wrong.

When they&#x27;re the users of what they make.

Asking a broad sample of people seems like a approach that would get you “how to be a good engineering” at best.

Alternative title: What makes me a good software engineer?

and here I always thought the answer was Adderall

&quot;You are a product of your environment&quot; --Clement Stone (b. 1902)<p>The Pygmalion effect, or Rosenthal effect, is a psychological phenomenon wherein high expectations lead to improved performance in a given area<p><a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Pygmalion_effect" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Pygmalion_effect</a>

Great software engineers know not to create PDFs when HTML works fine.

I&#x27;m surprised there is no reference to time estimation. An important part of their role is estimating how long a task will take to complete, and I&#x27;ve found many people, even engineers with a lot of experience, are terrible at this.