8 ms·

In 50 years of programming I've worked with a few. One characteristic is a deep understanding and command of all that they touch. For example, I worked with Bi

by daly 6y ago

In 50 years of programming I've worked with a few. One characteristic is a deep understanding and command of all that they touch. 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. 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 (https://www.youtube.com/watch?v=dKeqaDSjy98 https://www.youtube.com/watch?v=dKeqaDSjy98). 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 "on the fly", and even play thru with a broken string, adjusting chords to the new "5 string" form. He also knows guitar characteristics, pedal effects, etc., basically "all things guitar". 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). They also write beautiful "crafted" code. I'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. Greatness isn't about "team player", "hard working", "good at time estimation", or anything "social". Greatness is a property of the person, a deep love of the craft, and a focus on "doing it right".

chokeartist 6y ago
That was a beautiful story. Thank you for sharing.
runawaybottle 6y ago
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.
idolaspecus 6y ago
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.
- hvidgaard 6y ago
  Isn't that what "Greatness is a property of the person" is saying?
  - idolaspecus 6y ago
    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".
pelario 6y ago
>> 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.
- YZF 6y ago
  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...
vbezhenar 6y ago
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.
- oblio 6y ago
  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.
- galoisgirl 6y ago
  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.
bottled_poe 6y ago
> 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.
- wrnr 6y ago
  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.
  - bottled_poe 6y ago
    I ain't mockin nuffin.
  - myth_drannon 6y ago
    The thing is that even if you stick with one framework it changes. ReactJS/Redux is different from what it was 4 years ago.
- hvidgaard 6y ago
  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.
- myth_drannon 6y ago
  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.
legulere 6y ago
I think a lot is also circumstances. If there is too much pressure from outside even the best engineers cannot do great work.
brigandish 6y ago
> 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.
js8 6y ago
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.
- Aeolun 6y ago
  It can also be important to let these things go sometimes. The rabbit hole is often quite deep.
- galoisgirl 6y ago
  Courage is not the lack of fear, but the conviction that something else is more important than fear.
vorhemus 6y ago
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.
- tacitusarc 6y ago
  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.
alexpetralia 6y ago
Yes I've long thought similarly that's its the ability to grasp, manipulate and convey multiple (if not all) layers of abstraction.
namelosw 6y ago
That's a very narrow way of looking at greatness, but I some how love your point.
deleted 6y ago
[deleted]

by daly 6y ago

chokeartist 6y ago

That was a beautiful story. Thank you for sharing.

runawaybottle 6y ago

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.

idolaspecus 6y ago

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.

hvidgaard 6y ago
Isn't that what "Greatness is a property of the person" is saying?
- idolaspecus 6y ago
  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".

pelario 6y ago

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

YZF 6y ago
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...

vbezhenar 6y ago

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.

oblio 6y ago
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.
galoisgirl 6y ago
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.

bottled_poe 6y ago

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

wrnr 6y ago
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.
- bottled_poe 6y ago
  I ain't mockin nuffin.
- myth_drannon 6y ago
  The thing is that even if you stick with one framework it changes. ReactJS/Redux is different from what it was 4 years ago.
hvidgaard 6y ago
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.
myth_drannon 6y ago
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.

legulere 6y ago

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

brigandish 6y ago

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

js8 6y ago

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.

Aeolun 6y ago
It can also be important to let these things go sometimes. The rabbit hole is often quite deep.
galoisgirl 6y ago
Courage is not the lack of fear, but the conviction that something else is more important than fear.

vorhemus 6y ago

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.

tacitusarc 6y ago
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.

alexpetralia 6y ago

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

namelosw 6y ago

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

deleted 6y ago

[deleted]