6 ms·

This looks pretty close to your description: https://news.ycombinator.com/item?id=39342143 https://news.ycombinator.com/item?id=39342143 EDIT: Looks like the p

This looks pretty close to your description: https://news.ycombinator.com/item?id=39342143 https://news.ycombinator.com/item?id=39342143 EDIT: Looks like the parent post entered the second chance pool (https://news.ycombinator.com/item?id=26998308 https://news.ycombinator.com/item?id=26998308). Not only did all the timestamps get rewritten, but apparently I can now edit this day-old comment :) Interestingly, it does show the correct timestamp when editing. Off-topic, but thought it's interesting behavior worth mentioning.

dcminter 2y ago
Oh that surely must be it! Even if it isn't though, that is a neat little anecdote and I'm glad I've had the chance to read it - I hadn't seen it before.
- lexoj 2y ago
  Yep it was it :)
markus_zhang 2y ago
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"?
- 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.
lexoj 2y ago
That was it, thank you very much! :)
thih9 2y ago
Note, one of the links in that article goes to the source code in question: https://multicians.org/vtoc_man.html https://multicians.org/vtoc_man.html
- snowfarthing 2y ago
  I was puzzled by the source at first -- it seemed like Assembler, but was too high-level to be that -- and it looked too complex to be BASIC (or possibly JOSS, I suppose) -- I was a little taken aback to see the extension of the filename as "pl1", because I sort-of thought PL/1 was higher-level than that!
dang 2y ago
Great! Macroexpanded: It Can Be Done (2003) - https://news.ycombinator.com/item?id=39342143 https://news.ycombinator.com/item?id=39342143 - Feb 2024 (137 comments) It Can Be Done (2003) - https://news.ycombinator.com/item?id=18415231 https://news.ycombinator.com/item?id=18415231 - Nov 2018 (18 comments) (re the timestamps see https://hn.algolia.com/?dateRange=all&page=0&prefix=true&query=by%3Adang%20timestamps%20re-up&sort=byDate&type=comment https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que... - only the front page and /item pages show the re-upped time. Good point about the edit window, I missed that twist!)

dcminter 2y ago

Oh that surely must be it! Even if it isn't though, that is a neat little anecdote and I'm glad I've had the chance to read it - I hadn't seen it before.

lexoj 2y ago
Yep it was it :)

markus_zhang 2y ago

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

lexoj 2y ago

That was it, thank you very much! :)

thih9 2y ago

Note, one of the links in that article goes to the source code in question: https://multicians.org/vtoc_man.html https://multicians.org/vtoc_man.html

snowfarthing 2y ago
I was puzzled by the source at first -- it seemed like Assembler, but was too high-level to be that -- and it looked too complex to be BASIC (or possibly JOSS, I suppose) -- I was a little taken aback to see the extension of the filename as "pl1", because I sort-of thought PL/1 was higher-level than that!

dang 2y ago

Great! Macroexpanded: It Can Be Done (2003) - https://news.ycombinator.com/item?id=39342143 https://news.ycombinator.com/item?id=39342143 - Feb 2024 (137 comments) It Can Be Done (2003) - https://news.ycombinator.com/item?id=18415231 https://news.ycombinator.com/item?id=18415231 - Nov 2018 (18 comments) (re the timestamps see https://hn.algolia.com/?dateRange=all&page=0&prefix=true&query=by%3Adang%20timestamps%20re-up&sort=byDate&type=comment https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que... - only the front page and /item pages show the re-upped time. Good point about the edit window, I missed that twist!)