>> 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.

>> Greatness isn't about "team player", "hard working", (...) Greatness is a property of the person, a deep love of the craft, and a focus on "doing it right".

In your history I see a great deal of "hard work" and "team player". Moreover, to be able to perform like that, I'm quite sure he has been hard working for a long time. Of course, there is talent and virtuosity which I'm not downplaying. My point is that when people see such a virtuous performance (in all fields, like you mentioned), where there is clearly a lot of talent, there is a tendency to downplay the hard working part.

Hard work is the essence of what produces so-called talent. It seems to my understanding that talent is more so the culmination of a chain of clever thinking which ultimately derives more understanding and natural association with XYZ, than a deterministic natural born trait. Albeit, there are most definitely physical strengths tied to DNA, it wouldn't be entirely far-fetched to claim that different people have different mental strengths.

However, hard work doesn't always produce greatness. It would be misleading to say that hard work is equivalent to all other hard work. It's not. It's synonymous with the phrase, "practice makes perfect." Yet the phrase should really be amended to "perfect practice makes perfect." Aimless, bad practice will led to aimless, bad results.

Mental focus and barricades are huge components as well. The greats are just as human as the rest of us. Comparison is mentally debilitating for everyone, especially if "talented" individuals have a higher rate of growth than the average. Yet I have to wonder, does the individual who "desires greatness" aspire to achieve validation for ego-boosting fictional accomplishments or truly wish to push the edge of their capabilities to their respective human limits? The former have no chance at putting their energy into prospective efforts. The latter may continue to develop and create something the world hasn't seen before, and or realize that they can do things they had believed they couldn't before.

I agree - there's a huge different between wall-clock time spent on a task, and amount of actual progress made.

Perhaps a talent in an area is simply the ability to use your practice time on those things that actually take you further.

Can't speak for the OP but I read "hard working" in double quotes as something that's not the same as someone who spent a lot of time perfecting their craft. So in the Dilbert sense of the word.

I do notice the paper defines it as "someone who is willing to work for more than 8 hour days to deliver the software product". I'm thinking meh. I think hard work at some point is a requirement to achieving excellence in most disciplines, in something like martial arts, or music, pretty much everyone I consider to be great has spent some years where their whole life was the discipline. I'm not really aware of someone who got there by raw talent without the practice (there might be examples). My experience with software engineering is similar.

However that's not the same as saying you'll become great by working 10 hour days, i.e. that sense of "hard working". You need to be in the right mindset.

Also this sort of folklore is cool but you have to consider the context, great musicians are not necessarily great in any style of music or with any instrument. That said, some people are surprising skilled in broad areas and the skills do tend to transfer within the discipline to some degree. On top of that, to the novice, an intermediate may be considered great. You really need to have some perspective to be able to recognize greatness and appreciate it.

EDIT: random btw is that most 6 string guitar chords work just as well with a missing string. Most simple chords have 3 notes in them and so with 6 strings there's enough redundancy. If you know where the root, third and 5th are in the chord (which most intermediate guitar players know) you'll immediately know whether the missing string removes any of those (even if it does the chord will still sound fine, you don't necessarily need all those 3 notes). Transposing on the fly is a little harder, but you don't really need to be a master to do that... So stuff like that may seem like magic but isn't necessarily so... Playing by ear is cool, usually people who start playing young are better at this, especially if this is how they started. This skill, to some degree, is also reasonably common...

I think there's work and there's work. The people who've I've observed with great engineering talent have certainly worked to get it, but they have been selective to the point of selfishness about what work they do. That work might look like "fun" to colleagues, and so they are diplomatic about it, or don't do it completely out in the open.

Of course the proliferation of free engineering tools makes it possible for them to have two lives, one doing the "hard work" that satisfies colleagues during the day, and the other "hard work" that develops talent at night.

I've also seen many young engineers plunge straight into "hard work" consisting of running the CAD terminal and fighting fires, and those engineers were recognized as being productive but lost their fundamental knowledge and did not become great engineers.

This is a point where Part III of Scott Alexander's [parable of the talents](https://slatestarcodex.com/2015/01/31/the-parable-of-the-tal...) might be worth linking to.

TLDR: Scott and his younger brother were both enrolled in piano class. His brother took to it and is now an internationally known musician. Scott meanwhile started off trying equally hard but never got anywhere in music - but won writing competition after writing competition without it feeling like effort to him.

I like to compare endeavors to athletics. People have natural talent that, by itself, will take you so far. People with less natural talent can work hard and supersede people with superior natural talent that don't work hard.

To be the top of the top, you must have natural talent and nurture and bolster that with hard work. The common denominator of all the exceptional people is hard work.

I appreciated the first 90% of your comment, and consider the picture of greatness you painted therein something to aspire to. Deep thoughtfulness, personal responsibility, craftsmanship, and virtuosity are all traits I hope to one day embody. But as a matter of argumentation the last line is simply discordant, it does not follow from the anecdote (beyond the obvious fact that the anecdote is anecdotal).

In my experience the most brilliant people aren't brilliant individually or brilliant as a team player or brilliant at X or brilliant at Y, they're simply brilliant. The one exception to this observation, in my experience, is that I've met a few brilliant mathematicians who are very narrowly brilliant.

Isn't that what "Greatness is a property of the person" is saying?

It definitely could be the case that my last point and GP's last point overlap to some extent. I read it (with the sentence before it) more as a claim that certain characteristics aren't factors when it comes to "greatness".

I encounter so many bugs nowadays in my tools. I would probably spend all my time fixing those bugs in multi-million-LoC codebases (assuming that tool is open source). That story sounds like something that could happen back in the day, when things were simple enough. I wonder if it could happen today.

It's like with polymaths. The higher up the stack we move, in science, the harder it is to know multiple fields, let alone have a major impact on several.

Documenting bugs is providing a lot of value already.

It would be also inefficient for you to spend time learning how the tool works, setting up the environment etc. when there are people who know it already.

> 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.

That would be far more difficult if the source code was in a poor state. Some libraries are easier to patch than others, I can think of a couple of libraries I've wanted to quickly patch and soon (not soon enough) realised that it's unpatchable because it's a mess (or perhaps even worse, is too clever by half and has far too much indirection and not enough comments) and would need extensive surgery.

That's not to diminish the strength of your story about Bill Schelter but only to point out that it's easier to do your best work if others are doing theirs.

Personally, I think it's two things - working hard and lack of fear/anxiety.

In your example, this Emacs bug fixing, there is a lot of people who work hard but would just think that the bug is probably difficult to fix (they would fear of it taking too long to do) and decide not to do it.

I know personally how much anxiety can block you from doing things that help you progress. It also makes decision-making slower. I think playfulness can help to alleviate it, but it's hard to maintain in a "professional" setting.

It can also be important to let these things go sometimes. The rabbit hole is often quite deep.

Courage is not the lack of fear, but the conviction that something else is more important than fear.

> Great software engineers I've known seem to have complete command of all of the ideas, tools, and techniques. They understand their tools "all the way down to the metal" and all the way "up to the esthetics". You can see great people in all crafts (like woodworking).

Do people like this exist today? I mean, the complexity at every level in the stack seems to have grown exponentially(maybe?) for decades. Are there engineers who are experts covering every layer across modern hardware architecture, CPU instruction sets, modern operating system architecture, cybersecurity, networking protocols, web technology, database systems, file systems, cloud infrastructure, quality control, Data Science, AI, AR, VR, Machine learning, UI framework design, wireless interfaces, etc. And that's all before you even consider the non-technical skills of software engineering. The bar moves higher every day and I'm not sure this level of expertise is achievable/maintainable.

You don't have to excel at every layer. If you understand the basics of every layer, you're so far ahead in the game that you might as well be a magician.

You make a mockery of the original statement, if you focus on YOUR stack (not just any) then yes with a bit of focus it should be possible, but you need to stop learning yet another JS framework.

The thing is that even if you stick with one framework it changes. ReactJS/Redux is different from what it was 4 years ago.

I ain't mockin nuffin.

Never met one. I met many that looked very talented but once the stack changed they were completely fish out of the water. But they were very productive with what they knew, but at some point they got tired or didn't have enough time to reach again the same level of mastery. I'm talking mostly about web/UI work.

The variety of tools that many software engineers work with today is so large that I find it virtually impossible to fully master them.

Let's say a software engineer writes a C++ application that stores documents in an inverted index and he also takes care that the program is stored in a docker container and deployed to Elastic Kubernetes Service via Jenkins. Good luck understanding your IDE, C++, Tries/Radix trees, docker, Jenkins and EKS "all the way down to the metal".

It may be possible for a small subset of those but if the expectation for great engineers really is to deeply understand "all that they touch", I wonder how many can keep up with this standard.

After a few years focused on those areas, with a solid understanding of computers and software as a foundation, it may even be possible for many engineers. The issue is the tech landscape shifts so quickly that you probably won't be using that exact stack in just a couple years. Swap jenkins with gitlab ci, docker with podman, c++ with golang. Functionality is still pretty close, but implementation details are different. And the road to mastering them is reset.

I think a lot is also circumstances. If there is too much pressure from outside even the best engineers cannot do great work.

Yes I've long thought similarly that's its the ability to grasp, manipulate and convey multiple (if not all) layers of abstraction.

That's a very narrow way of looking at greatness, but I some how love your point.

That was a beautiful story. Thank you for sharing.

Don’t confuse familiarity with greatness. Of course if you wrote the damn thing you can demonstrate technical virtuosity.

Edit: Maybe I read too fast. Anyways, intuition is sort of the precursor to greatness. You know those designers that pick out colors innately? No amount of color theory studying will get you to that level. You are probably describing someone with an intuition for debugging.

One of those things in life everyone has to learn eventually. Don’t fight the tide, find the waves that are certainly for you.