4 ms·

Reading the original article, I can't help recalling what David Cutler said in an interview, that whenever he completed a piece of code, he always ran it in his

Reading the original article, I can't help recalling what David Cutler said in an interview, that whenever he completed a piece of code, he always ran it in his head a few times to make sure that nothing could go wrong, and then submitted (presumably for testing). His NT code had very few bugs as per say. I think 10x programmers are indeed usually smarter than ordinary programmers. They don't work out 10x amount of higher quality code, or 10x quality of code, but work in COMPLETELY DIFFERENT DOMAINS -- OS, Compilers, Emulators, etc., they simply solve tougher problems. And they also have the capacity to hold a lot of code in their brains. This is so amazing. I usually lost myself after just maybe a couple of dozen lines, or a few function hops. Admittedly, my program uses more libraries so TBH the brain trace just stopped whenever it went into a 2000 line long library function. But my project is more trivial than theirs.

Matthyze 2y ago
There was a blog post the other day arguing that great developers aren't 10x but infinity-x. It sounds ridiculous, but their point was that great developers don't simply program faster but solve problems other developers are entirely unable to solve. And that makes sense to me. It's the difference between an AI boot camp graduate and someone with an ML PhD. They might apply a sklearn function at the same speed, but as soon as complex problems appear, the former hits an unsurpassable wall. edit: https://www.seangoedecke.com/weak-engineers/ https://www.seangoedecke.com/weak-engineers/
- ukuina 2y ago
  Do you happen to have a link?
  - Matthyze 2y ago
    https://www.seangoedecke.com/weak-engineers/ https://www.seangoedecke.com/weak-engineers/
- bilekas 2y ago
  > It's the difference between an AI boot camp graduate and someone with an ML PhD. They might apply a sklearn function at the same speed, but as soon as complex problems appear, the former hits an unsurpassable wall. I'm sure you're generalizing to make a point but I can assure you this is often not the case, I know several PhD's who have a very hard time dealing with real-world problems that any practical engineer would catch. There is a lot to be said for theory, but there is also a very hard limit.
  - markus_zhang 2y ago
    > I know several PhD's who have a very hard time dealing with real-world problems that any practical engineer would catch. I don't know the details, but this could exactly be the proof, not the counter-proof. They do different things, but they may not perform ordinary jobs very well. What if we ask John Carmack to play with CSS, move those pixels so the UI looks "perfect"?
    - bilekas 2y ago
      You might be right, point for giving me a good goggle thinking of John Carmack pulling his hair out over CSS :)
      - markus_zhang 2y ago
        Yeah would love to see that too...but Casey venting is good enough.
- codr7 2y ago
  I'd say my most valuable skill is identifying and making problems disappear completely, but it's more a result of having an extensive experience to pull from and pattern match against.
- mindcrime 2y ago
  OTOH, I've interviewed folks with CS PhD's that literally could not write fizzbuzz. And that's given a head-start with a template program in an IDE, where all they needed to do was flesh out the core algorithm. Not necessarily to disagree with your overall point. But having a PhD is maybe not always as significant as we think it is. Getting a PhD (usually) means extreme specialization in a (possibly highly niche) area, and may well leave someone without a lot of basic skills you might expect them to have.
  - Matthyze 2y ago
    Right. My point isn't that doctors are particularly good at programming (they're probably not). I mean that some people have skills, or raw talent, that allow them to do what others simply cannot at all.
    - mindcrime 2y ago
      Fair enough!
  - NoMoreNicksLeft 2y ago
    I don't have a PhD, so I'm hesitant to comment, but I've always had the impression that it was more like grinding in some video game than it was anything truly intellectual. Then at the final boss battle, can you or can you not have ready answers for ridiculous questions.
    - snowfarthing 2y ago
      I recall a psychologist or psychiatrist who challenged the notion of "defiant personality disorder" by observing two things: (1) Many of these "defiant" people merely didn't trust credentials -- they were perfectly fine with authority who earned deference by virtue of proving they really do know what they are doing, and (2) That the psychology/psychiatry profession in general, consisting of people who have their Masters and PhDs, have to "suck up" to a lot of credentialed authority, without question, to get their degrees -- and thus it's only natural for them to expect everyone to unconditionally respect credentials! (For the record, I have a PhD, but it's in pure math, which is possibly simultaniously both the least practical and most practical thing you could possibly learn -- but as such, I'm tangential to engineering and physics -- and I'm pretty sure that all three of these fields have a certain "fine, you have a credential, but can you really walk the walk?" element to them.)
- markus_zhang 2y ago
  Yeah exactly. I have been very interested in learning all kinds of details from the Archmages, so I gathered as much information as possible. From what I observe, great minds do great things.
- snowfarthing 2y ago
  Many years ago, when I was learning about pair programming, I remember someone (possibly even Kent Beck) saying that "Pair programming is kryptonite for incompetent introverts!" and I remember thinking, "Well, yeah, but I bet it's the haven of incompetent extroverts!" While I haven't really been in forums debating the merits and perils of paired programming, I cannot help but be amused by this essay, that pretty much confirms this initial thought I had about paired programming!
swatcoder 2y ago
> whenever he completed a piece of code, he always ran it in his head a few times to make sure that nothing could go wrong It's a bit disturbing to me that this is being voiced as a feat of some kind. Everybody should be doing this and most people are capable of it. I'm sure you are as well, despite your own pessimism. If you're not doing this, there's been some failing among your mentors. You can develop this skill with intent and practice and you really really really should. That's what the programming part of our job is: not pasting in snippets from Stack Overflow, not asking Copilot for something that you hope is okay, not vomiting code until it gets a big green OK from your tooling, not gluing together library functions whose implementation and constraints we don't understand. You should be developing a clear mental model of your code, what supporting utilities it references, how those utilities work and what constraints they impose, as well as actively considering edge cases that need specific attention and the constraints your code projects outward to its callers. You won't be able to do this consistently during your first couple years of working. And that's fine. But something's gone deeply wrong with your craft if you haven't gotten a handle on it once you're more professionally mature. But rather than feeling incapable of doing it yourself and in awe of those who do, you just need to commit yourself to practicing it as much as you can until it becomes second nature.
- 01HNNWZ0MV43FF 2y ago
  I can't run code in my head if I'm working at a high level where every function calls into thousands of lines of code. This comes up a lot at work. If I'm writing 100 lines of greenfield code then yeah, anything is easy then.
  - swatcoder 2y ago
    From my original comment: > what supporting utilities it references, how those utilities work and what constraints they impose The responsibility isn't to memorize and model every function called up and down your whole stack. Often, you don't even have full insight into that if you wanted it and of course you couldn't hold that all in your head even if you wanted to. But you don't need to. The responsibility is simply to thoroughly understand how each function you call works insofar as you're using it. You should be confident, not hopeful, that the state you've arranged for that function call is a valid state for it, you should have a informed, not incurious, sense of its general behavior characteristics (fast or slow, high or low resource demands, thread safety, etc), and you should be able to make informed predictions about what its output should like given the state you pass in. It's actual implementation will often be opaque, or at least opaque at some depth, but between the function's documentation, any access to its source, and your own insight of how something like that function would likely or necessarily implemented, you can and should be able to fully model it for the purposes of your own invocation.
ramon156 2y ago
Id argue that "running the code in your head" is something everyone should do to a degree. Just try and see which paths are interesting because they could potentially fail. Only then submit for review
uncertainrhymes 2y ago
I once had a (older) Russian colleague tell me about how he learned to program. He would write it out longhand, because access to compilers was limited to certain time slots in University. He know it had to work first time, otherwise he had to wait for the next chance to fix the bug. I'm sure that was true for everyone back in the punchcard days. It would enforce a kind of rigor that I can blissfully ignore. edit: I see the exact same story in the linked thread, so clearly a lot of Russians are very proud of that skill
- SoftTalker 2y ago
  Yes, this is common ground for "old" programmers. Quite simply, when you had to walk across campus or at least to a different room to submit your card deck, wait (perhaps hours) for the results (printed on fan-fold paper, that again you had to go to a different building or room to pick up) only to find your program didn't compile due to a syntax error or didn't run due to a careless bug, you learned to "desk check" your code, run the program in your head, and be as sure as you could be that there were no errors. Even when we got connected terminals, it could still take hours for your compile job to work its way through the queue of pending jobs, because it was in a development region that only got resources when the production queue was clear. You didn't use the compiler as a syntax checker in those days. That all started to change when we got PCs or workstations, or at least good interactive multiuser development environents, and a "code-compile" loop or repl became part of the standard toolkit.
  - michaelrpeskin 2y ago
    I have a old guy that I work with - PhD in Math (because CS didn't exist then) - who does lots of algorithm development with me. I often get Word docs of pseudo code from him. I'll do a search-and-replace on things like "LET" and "ELSE IF" and a very high percentage of the time if I run it in Python it works on the first try. Kind of amazing to me. The hard part for me is then translating his ideas into vectorized numpy for speed, but at least I get the right answer to check against.
  - markus_zhang 2y ago
    I sometimes wonder whether following some of these practices may promote more mediocre programmers, if they so wish, to become better ones. - Think through and write on paper in pseudo code first; - Run written code in head, or on paper if they don't have the capacity, a couple of times before pressing that BUILD menu item; - Restrain from using libraries if a custom, better solution is possible; But then I think, it probably doesn't make a lot of sense if you work as a frontend pushing out JS, or as a data eng writing Python code which calls some Scala code which runs in JVM which is highly complicated, because the whole industry is "AGILE" and the chain is way too long. You need to get into the right job, to nurture such a mindset. The old timers got lucky. They started with 6502 bare metal. That's why I'm pushing myself to get out of Data Engineering, to do something lower level, until I get deep into the basement. I probably won't succeed here but it's fun to try.

Matthyze 2y ago

There was a blog post the other day arguing that great developers aren't 10x but infinity-x. It sounds ridiculous, but their point was that great developers don't simply program faster but solve problems other developers are entirely unable to solve. And that makes sense to me. It's the difference between an AI boot camp graduate and someone with an ML PhD. They might apply a sklearn function at the same speed, but as soon as complex problems appear, the former hits an unsurpassable wall. edit: https://www.seangoedecke.com/weak-engineers/ https://www.seangoedecke.com/weak-engineers/

ukuina 2y ago
Do you happen to have a link?
- Matthyze 2y ago
  https://www.seangoedecke.com/weak-engineers/ https://www.seangoedecke.com/weak-engineers/
bilekas 2y ago
> It's the difference between an AI boot camp graduate and someone with an ML PhD. They might apply a sklearn function at the same speed, but as soon as complex problems appear, the former hits an unsurpassable wall. I'm sure you're generalizing to make a point but I can assure you this is often not the case, I know several PhD's who have a very hard time dealing with real-world problems that any practical engineer would catch. There is a lot to be said for theory, but there is also a very hard limit.
- markus_zhang 2y ago
  > I know several PhD's who have a very hard time dealing with real-world problems that any practical engineer would catch. I don't know the details, but this could exactly be the proof, not the counter-proof. They do different things, but they may not perform ordinary jobs very well. What if we ask John Carmack to play with CSS, move those pixels so the UI looks "perfect"?
  - bilekas 2y ago
    You might be right, point for giving me a good goggle thinking of John Carmack pulling his hair out over CSS :)
    - markus_zhang 2y ago
      Yeah would love to see that too...but Casey venting is good enough.
codr7 2y ago
I'd say my most valuable skill is identifying and making problems disappear completely, but it's more a result of having an extensive experience to pull from and pattern match against.
mindcrime 2y ago
OTOH, I've interviewed folks with CS PhD's that literally could not write fizzbuzz. And that's given a head-start with a template program in an IDE, where all they needed to do was flesh out the core algorithm. Not necessarily to disagree with your overall point. But having a PhD is maybe not always as significant as we think it is. Getting a PhD (usually) means extreme specialization in a (possibly highly niche) area, and may well leave someone without a lot of basic skills you might expect them to have.
- Matthyze 2y ago
  Right. My point isn't that doctors are particularly good at programming (they're probably not). I mean that some people have skills, or raw talent, that allow them to do what others simply cannot at all.
  - mindcrime 2y ago
    Fair enough!
- NoMoreNicksLeft 2y ago
  I don't have a PhD, so I'm hesitant to comment, but I've always had the impression that it was more like grinding in some video game than it was anything truly intellectual. Then at the final boss battle, can you or can you not have ready answers for ridiculous questions.
  - snowfarthing 2y ago
    I recall a psychologist or psychiatrist who challenged the notion of "defiant personality disorder" by observing two things: (1) Many of these "defiant" people merely didn't trust credentials -- they were perfectly fine with authority who earned deference by virtue of proving they really do know what they are doing, and (2) That the psychology/psychiatry profession in general, consisting of people who have their Masters and PhDs, have to "suck up" to a lot of credentialed authority, without question, to get their degrees -- and thus it's only natural for them to expect everyone to unconditionally respect credentials! (For the record, I have a PhD, but it's in pure math, which is possibly simultaniously both the least practical and most practical thing you could possibly learn -- but as such, I'm tangential to engineering and physics -- and I'm pretty sure that all three of these fields have a certain "fine, you have a credential, but can you really walk the walk?" element to them.)
markus_zhang 2y ago
Yeah exactly. I have been very interested in learning all kinds of details from the Archmages, so I gathered as much information as possible. From what I observe, great minds do great things.
snowfarthing 2y ago
Many years ago, when I was learning about pair programming, I remember someone (possibly even Kent Beck) saying that "Pair programming is kryptonite for incompetent introverts!" and I remember thinking, "Well, yeah, but I bet it's the haven of incompetent extroverts!" While I haven't really been in forums debating the merits and perils of paired programming, I cannot help but be amused by this essay, that pretty much confirms this initial thought I had about paired programming!

swatcoder 2y ago

> whenever he completed a piece of code, he always ran it in his head a few times to make sure that nothing could go wrong It's a bit disturbing to me that this is being voiced as a feat of some kind. Everybody should be doing this and most people are capable of it. I'm sure you are as well, despite your own pessimism. If you're not doing this, there's been some failing among your mentors. You can develop this skill with intent and practice and you really really really should. That's what the programming part of our job is: not pasting in snippets from Stack Overflow, not asking Copilot for something that you hope is okay, not vomiting code until it gets a big green OK from your tooling, not gluing together library functions whose implementation and constraints we don't understand. You should be developing a clear mental model of your code, what supporting utilities it references, how those utilities work and what constraints they impose, as well as actively considering edge cases that need specific attention and the constraints your code projects outward to its callers. You won't be able to do this consistently during your first couple years of working. And that's fine. But something's gone deeply wrong with your craft if you haven't gotten a handle on it once you're more professionally mature. But rather than feeling incapable of doing it yourself and in awe of those who do, you just need to commit yourself to practicing it as much as you can until it becomes second nature.

01HNNWZ0MV43FF 2y ago
I can't run code in my head if I'm working at a high level where every function calls into thousands of lines of code. This comes up a lot at work. If I'm writing 100 lines of greenfield code then yeah, anything is easy then.
- swatcoder 2y ago
  From my original comment: > what supporting utilities it references, how those utilities work and what constraints they impose The responsibility isn't to memorize and model every function called up and down your whole stack. Often, you don't even have full insight into that if you wanted it and of course you couldn't hold that all in your head even if you wanted to. But you don't need to. The responsibility is simply to thoroughly understand how each function you call works insofar as you're using it. You should be confident, not hopeful, that the state you've arranged for that function call is a valid state for it, you should have a informed, not incurious, sense of its general behavior characteristics (fast or slow, high or low resource demands, thread safety, etc), and you should be able to make informed predictions about what its output should like given the state you pass in. It's actual implementation will often be opaque, or at least opaque at some depth, but between the function's documentation, any access to its source, and your own insight of how something like that function would likely or necessarily implemented, you can and should be able to fully model it for the purposes of your own invocation.

ramon156 2y ago

Id argue that "running the code in your head" is something everyone should do to a degree. Just try and see which paths are interesting because they could potentially fail. Only then submit for review

uncertainrhymes 2y ago

I once had a (older) Russian colleague tell me about how he learned to program. He would write it out longhand, because access to compilers was limited to certain time slots in University. He know it had to work first time, otherwise he had to wait for the next chance to fix the bug. I'm sure that was true for everyone back in the punchcard days. It would enforce a kind of rigor that I can blissfully ignore. edit: I see the exact same story in the linked thread, so clearly a lot of Russians are very proud of that skill

SoftTalker 2y ago
Yes, this is common ground for "old" programmers. Quite simply, when you had to walk across campus or at least to a different room to submit your card deck, wait (perhaps hours) for the results (printed on fan-fold paper, that again you had to go to a different building or room to pick up) only to find your program didn't compile due to a syntax error or didn't run due to a careless bug, you learned to "desk check" your code, run the program in your head, and be as sure as you could be that there were no errors. Even when we got connected terminals, it could still take hours for your compile job to work its way through the queue of pending jobs, because it was in a development region that only got resources when the production queue was clear. You didn't use the compiler as a syntax checker in those days. That all started to change when we got PCs or workstations, or at least good interactive multiuser development environents, and a "code-compile" loop or repl became part of the standard toolkit.
- michaelrpeskin 2y ago
  I have a old guy that I work with - PhD in Math (because CS didn't exist then) - who does lots of algorithm development with me. I often get Word docs of pseudo code from him. I'll do a search-and-replace on things like "LET" and "ELSE IF" and a very high percentage of the time if I run it in Python it works on the first try. Kind of amazing to me. The hard part for me is then translating his ideas into vectorized numpy for speed, but at least I get the right answer to check against.
- markus_zhang 2y ago
  I sometimes wonder whether following some of these practices may promote more mediocre programmers, if they so wish, to become better ones. - Think through and write on paper in pseudo code first; - Run written code in head, or on paper if they don't have the capacity, a couple of times before pressing that BUILD menu item; - Restrain from using libraries if a custom, better solution is possible; But then I think, it probably doesn't make a lot of sense if you work as a frontend pushing out JS, or as a data eng writing Python code which calls some Scala code which runs in JVM which is highly complicated, because the whole industry is "AGILE" and the chain is way too long. You need to get into the right job, to nurture such a mindset. The old timers got lucky. They started with 6502 bare metal. That's why I'm pushing myself to get out of Data Engineering, to do something lower level, until I get deep into the basement. I probably won't succeed here but it's fun to try.