EDIT: Looks like the parent post entered the second chance pool (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.
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.
> 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.
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.
> 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.
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.
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.
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.
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.
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
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.
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
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.
IIRC, Dijkstra's THE operating system for the Electrologica X8 was completed before the hardware was available. It was the first multitasking operating system (albeit with a fixed set of tasks) and the first use of semaphores. Supposedly the initial version only had trivial coding errors.
Turing and Champernowne coded Turochamp by hand in 1948, but never executed it on a computer. The instructions were however executed with Turing as the computer:
I remember Mohammed Said (of Laravel fame) telling this story to Matt Stauffer in the Laravel Podcast. He wrote is programs at home on pen and paper and went to the public library to try them out.
I think there’s a story in the Bill Gates biography “Hard Drive” about when he flies to MITS in New Mexico to show off BASIC (I think), then realizes he forgot to write a bootloader, so does it on the plane on a yellow legal pad. Toggles it into the Altair during the demo and it works on the first try.
I couldn't find the exact post, but it might be related to the story of Terry Davis, the creator of TempleOS. He was known for his unique approach to coding and his dedication to his project. Unfortunately, Terry Davis passed away in 2018.
Unfortunetaly is not any of them. Title was not very descriptive, a keen of "My friend Andre", but didnt find anything with those so maybe I misremember the name.
This isn't really that uncommon of a thing. Just talk to your ex-Soviet friends. I worked with a Network Engineer whose computer time in uni was limited, so he did exactly this.
No luck as I dont have a keyword in mind of the title. I remember in the blogpost that in the very end he had to fix 1-2 typos and everything worked correctly.
The blog (in old school design) had a lot of posts and pictures of that era and the people involved building that OS.
We used to have to do this in high school in AP CS in the early 90s. All the tests were to write such and such with pencil and paper. We would get marked off for syntactical mistakes.
I had totally forgotten about this. I still have the PASCAL book.
I have the same problem finding an article about meta problem solving. The writer compared it to skiing or judo or some sport. No combination of keywords conjures up the right article in search.
Ah yes, the web burns shortly after we shoot it and we left no bread crumbs to navigate the forest. It is true! We used pens, pencils and graph paper to write down and draw all kinds of things while using the computer. Paper has very robust IO. A single note book can hold as many glyphs as ship full of clay tablets but after 40 years you have no idea where you've put it.
This looks pretty close to your description: 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). 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.
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.
> 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.
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.
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/
> 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.
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.
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.
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.
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.
Do you happen to have a link?
https://www.seangoedecke.com/weak-engineers/
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
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.
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
That was it, thank you very much! :)
Note, one of the links in that article goes to the source code in question:
https://multicians.org/vtoc_man.html
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.
Yep it was it :)
IIRC, Dijkstra's THE operating system for the Electrologica X8 was completed before the hardware was available. It was the first multitasking operating system (albeit with a fixed set of tasks) and the first use of semaphores. Supposedly the initial version only had trivial coding errors.
Was it the Story of Mel?
https://news.ycombinator.com/item?id=32395589
He also passed away relatively recently.
https://melsloop.com/docs/the-story-of-mel/pages/mel-kaye-cv
Does anyone know if the original source as diagrams and pencil code is preserved somewhere?
It looks as if some of them might have been re-drawn for:
https://www.multicians.org/nss.html
and this is the source code in question?
https://www.multicians.org/vtoc_man.html
This was pretty common back then. I don't recall the post you are talking about but I wrote a little about my own experience here: https://blog.jgc.org/2013/04/how-i-coded-in-1985.html
Turing and Champernowne coded Turochamp by hand in 1948, but never executed it on a computer. The instructions were however executed with Turing as the computer:
https://www.history.com/news/in-1950-alan-turing-created-a-c...
I remember Mohammed Said (of Laravel fame) telling this story to Matt Stauffer in the Laravel Podcast. He wrote is programs at home on pen and paper and went to the public library to try them out.
They used to have print templates for this sort of thing. Here's an example from the 1960s: https://try-mts.com/system-360-assembly-language-introductio...
I think there’s a story in the Bill Gates biography “Hard Drive” about when he flies to MITS in New Mexico to show off BASIC (I think), then realizes he forgot to write a bootloader, so does it on the plane on a yellow legal pad. Toggles it into the Altair during the demo and it works on the first try.
(Might have a lot of details wrong)
I couldn't find the exact post, but it might be related to the story of Terry Davis, the creator of TempleOS. He was known for his unique approach to coding and his dedication to his project. Unfortunately, Terry Davis passed away in 2018.
https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
It can also be Mel
https://hn.algolia.com/?q=mel
Unfortunetaly is not any of them. Title was not very descriptive, a keen of "My friend Andre", but didnt find anything with those so maybe I misremember the name.
This isn't really that uncommon of a thing. Just talk to your ex-Soviet friends. I worked with a Network Engineer whose computer time in uni was limited, so he did exactly this.
In Romania when I was a kid I had access to computers at some sort of kids' club only once or twice per week for a couple hours.
So I wrote BASIC programs in the back of my school notebooks and typed in some of them when I got to the computer.
Have you tried using Hacker News Search?
https://hn.algolia.com
No luck as I dont have a keyword in mind of the title. I remember in the blogpost that in the very end he had to fix 1-2 typos and everything worked correctly.
The blog (in old school design) had a lot of posts and pictures of that era and the people involved building that OS.
We used to have to do this in high school in AP CS in the early 90s. All the tests were to write such and such with pencil and paper. We would get marked off for syntactical mistakes.
I had totally forgotten about this. I still have the PASCAL book.
I have the same problem finding an article about meta problem solving. The writer compared it to skiing or judo or some sport. No combination of keywords conjures up the right article in search.
I hope @dang remembers? :)
Ah yes, the web burns shortly after we shoot it and we left no bread crumbs to navigate the forest. It is true! We used pens, pencils and graph paper to write down and draw all kinds of things while using the computer. Paper has very robust IO. A single note book can hold as many glyphs as ship full of clay tablets but after 40 years you have no idea where you've put it.
why does this make me immediately think of templeOS