Quake related work logs (1996)(gamers.org)
gamers.org
Quake related work logs (1996)
https://www.gamers.org/dEngine/quake/info/worklogs.html
105 comments
I understand this will not explain entirety of it, but when you concentrate responsibility, decision making and ability to do all things through entirety of the application, you can move much, much faster than what all of us are used to working for regular companies.
It almost feels, and sometimes is cheating.
I was confronted with this when I felt really fantastic being super productive at one of the projects and then a team member pointed out that I am also tech lead, architect and a manager all in one and I simply don't work by the same rules as everybody else. Where everybody else has to get permissions, approvals, concensus, inputs, has to wait for other people to do things, I can just do it all in my head and act immediately. This taught me an important lesson and I am now much more conscious of this fact and spending way more time trying to remove any barriers from other team members.
This also explains why solo developers can sometimes achieve so much -- they simply don't have to work with anybody else. They don't have to understand code somebody else designed and wrote. They don't have to spend time arguing defending their approach or solutions. They know how everything works and can make all decisions solely on whether it helps them to achieve the result. Synchronising with other people is a huge overhead in any organisation.
It almost feels, and sometimes is cheating.
I was confronted with this when I felt really fantastic being super productive at one of the projects and then a team member pointed out that I am also tech lead, architect and a manager all in one and I simply don't work by the same rules as everybody else. Where everybody else has to get permissions, approvals, concensus, inputs, has to wait for other people to do things, I can just do it all in my head and act immediately. This taught me an important lesson and I am now much more conscious of this fact and spending way more time trying to remove any barriers from other team members.
This also explains why solo developers can sometimes achieve so much -- they simply don't have to work with anybody else. They don't have to understand code somebody else designed and wrote. They don't have to spend time arguing defending their approach or solutions. They know how everything works and can make all decisions solely on whether it helps them to achieve the result. Synchronising with other people is a huge overhead in any organisation.
That's sort of the myth behind the guy, but from Romero's account in Doom Guy, Carmack was pushing himself to the limit. He didn't sleep, he didn't take breaks, and he frequently rewrote things that other engineers wrote from scratch. While his code was great, his faculties as an employee and manager greatly suffered. He started lashing out at other developers and became an utter tyrant of a boss when he began to perceive that the lack of similar effort on behalf of other developers was unfair. I think he really struggled with Quake 1, especially since he had to teach himself all the math required, having no background in math
I looked at one of the work logs. Thought "that's a fair amount to get done in a week". Then realised it was just one day. Man is a machine!
Sometimes I wish I could go back to the 90s (or even early/mid 2000s) just for a day to remember what that vacuum of "stuff to do" in every day life was like.
I lived it, I remember "being bored" or having "nothing to do", but I truly can't access it in a meaningful way. I would love to go back to those days of playing games or engaging in my hobbies where I didn't feel that constant pressure of "but you better get stuff done, we don't have all day here".
I lived it, I remember "being bored" or having "nothing to do", but I truly can't access it in a meaningful way. I would love to go back to those days of playing games or engaging in my hobbies where I didn't feel that constant pressure of "but you better get stuff done, we don't have all day here".
He said he works 13h days.
[deleted]
Final log excerpt:
> Vacation? I don't need a vacation!
> Vacation? I don't need a vacation!
Or maybe: I'm having vacations every day!
I used to have a somewhat similar system, basically just a stack/heap system where I'd push/pop one list into another list of dated completed items, and I think I fairly often ended up with a huge volume of points.
It gets momentum and is self-reinforcing, the practice of jotting down unrelated threads you come up with makes them easy to pick up later, so you always have stack of problems to attack without having any of them cluttering your head as you execute. Often when I'm not doing stuff, it's because I don't have a clear picture of what I should do next, or how to do the next thing. This is not a problem I had working like this. It was all execution.
It gets momentum and is self-reinforcing, the practice of jotting down unrelated threads you come up with makes them easy to pick up later, so you always have stack of problems to attack without having any of them cluttering your head as you execute. Often when I'm not doing stuff, it's because I don't have a clear picture of what I should do next, or how to do the next thing. This is not a problem I had working like this. It was all execution.
I can't help but notice that the days are continuous, with not many (two day) gaps in between.
It was a start-up where he was a founder and major shareholder, and Quake was his own pet project, so of course he worked nearly 7 days/week. Not only was the future of the company at stake but he also enjoyed doing it.
Then AAA game studios saw this and thought that game devs just love working 7 days/week for peanuts even if it's on other people's companies and other people's projects.
Then AAA game studios saw this and thought that game devs just love working 7 days/week for peanuts even if it's on other people's companies and other people's projects.
> Not only was the future of the company at stake but he also enjoyed doing it.
The business concerns were not a major factor for Carmack. He was against expanding the business and the company was making plenty of money with a lot of cash to spare. They had other projects other than Quake that were making them money. Had he really cared about the health of the business, he wouldn't have lashed out so much at other developers working on things other than Quake. He simply thought the company should basically work on one project at a time.
The business concerns were not a major factor for Carmack. He was against expanding the business and the company was making plenty of money with a lot of cash to spare. They had other projects other than Quake that were making them money. Had he really cared about the health of the business, he wouldn't have lashed out so much at other developers working on things other than Quake. He simply thought the company should basically work on one project at a time.
[deleted]
found more of his logs by googling and my favorite is that he worked on xmas and new years eve in 1997. impressive focus
Isn't that what programming is like? I guess the main challenge is to avoid lying to yourself by downplaying stuff that is problematic.
Some are like this, and others tend to have more of a "mess around and try things until it works" style. In fact I've noticed a lot more programmers in the latter category than the former.
Edsger Dijkstra calls it Mozart vs Beethoven style of programming in an interview.
https://youtu.be/-Uae9_pgZzE
https://youtu.be/-Uae9_pgZzE
Can the former even exist today?
The hard part is knowing what parts -and why- you need to load into your head, so work can even begin.
>> QuakeWorld.
>> The code I am developing right now is EXCLUSIVELY for internet play.
I hope he has at least a vague idea of how many lives he changed because of this feature/philosophy/idea and game.
>> The code I am developing right now is EXCLUSIVELY for internet play.
I hope he has at least a vague idea of how many lives he changed because of this feature/philosophy/idea and game.
Oh for sure. Of the OG id guys, John Carmack seems to usually be a bit more on the humble side about it, but they definitely know how influential their stuff has been.
If I remember correctly, making Quake 3 multiplayer _only_ (not counting the bot matches, which was a cool thing to have built in) was a push from John Carmack. Which I think also really accelerated e-sports as a thing.
If I remember correctly, making Quake 3 multiplayer _only_ (not counting the bot matches, which was a cool thing to have built in) was a push from John Carmack. Which I think also really accelerated e-sports as a thing.
Quake 3 being exclusively multiplayer could also be down to id software loosing their best creative designers, as Quake 2's story was also considered sub-medicore, so they most likely just said "fuck it, we're going without a single player story this time".
Yeah they basically had resigned themselves to making the same game in a new engine every few years.
> Quake 2's story was also considered sub-medicore
id was infamous for what the plot of their games could fit on a pack of cigs, on one side.
id was infamous for what the plot of their games could fit on a pack of cigs, on one side.
Sure, but by the mid to late '90s, the goalposts have moved.
Half-Life 2 and others showed gamers you can have a captivating single player story AND also have fun shooting your friends in multiplayer.
Half-Life 2 and others showed gamers you can have a captivating single player story AND also have fun shooting your friends in multiplayer.
Looking at his format, I can't help but think what could have been if he had only used org-mode instead!
iD software would never have become anything of note, of course. Obsessing over his emacs config, but missing C, and so becoming the master of the C core. We would probably never have heard of anything like "long lines mode".
Growing up with the iD games, I am not so sure what I would prefer anymore. Actually I think I would have preferred the latter. Which is almost sad. A wild testament to emacs, to be sure.
(yes I know these posts predate it)
iD software would never have become anything of note, of course. Obsessing over his emacs config, but missing C, and so becoming the master of the C core. We would probably never have heard of anything like "long lines mode".
Growing up with the iD games, I am not so sure what I would prefer anymore. Actually I think I would have preferred the latter. Which is almost sad. A wild testament to emacs, to be sure.
(yes I know these posts predate it)
Your life is not completely terrible when you work log contains this line:
- drop green slime percentageI guess he dropped it all the way, I don't remember any green slime in Quake. Or anything else green, for that matter. In fact, he could have phrased that task with only the first two words.
You don’t remember Quake at all then or are confusing it with something else. Slime was abundant, it’s showcased along with the bio suit in E1M1. It has a tremendously distinctive player injury scream. The ever famous: “Player can't exist on slime alone” death message.
The whole game is sort of greenish and brownish. Like 90% of the textures have a vomit green aesthetic.
The whole game is sort of greenish and brownish. Like 90% of the textures have a vomit green aesthetic.
You could stand to calibrate your monitor, I'm thinking. Your basic Quake slime was the color of oatmeal. There was a bluish-green acid as well, but it wasn't as common as the oatmeal-flavored slime.
Perhaps you are confusing the water for slime and the slime for acid, which quake 1 did not have. There was nothing called acid, what it was always called (as stated BY THE VERY subject document here) was slime. Quake 1 had 2 instantly damaging fluids/textures slime and lava. That is literally what they are in the source.
What a weird discussion, disputing a document that was written 25 years ago contemporaneous with the subject. There’s no misremembering here and this document trumps yours or anyone’s memory.
https://quake.fandom.com/wiki/Slime_(Q1) https://quake.fandom.com/wiki/Water_(Q1)
https://github.com/search?q=repo%3Aid-Software%2FQuake%20aci... https://github.com/search?q=repo%3Aid-Software%2FQuake%20sli...
https://quake.fandom.com/wiki/Slime_(Q1) https://quake.fandom.com/wiki/Water_(Q1)
https://github.com/search?q=repo%3Aid-Software%2FQuake%20aci... https://github.com/search?q=repo%3Aid-Software%2FQuake%20sli...
Maybe for the German version? When I was a game dev in the 90s we had to create a separate "green slime" SKU for Germany.
https://wiki.ncac.org/Video_Game_Censorship_in_Germany#:~:te....
https://wiki.ncac.org/Video_Game_Censorship_in_Germany#:~:te....
I wonder how much of this was premeditated vs deciding what to work on based on preference or mood for the day.
I've always enjoyed working on things without a dedicated predefined list of tasks that I'll accomplish in X time (1 day, week, etc.). Instead, I just pick things off the queue and however far I get is the result. The queue in this case could either be from memory or a list of ideas.
I've always enjoyed working on things without a dedicated predefined list of tasks that I'll accomplish in X time (1 day, week, etc.). Instead, I just pick things off the queue and however far I get is the result. The queue in this case could either be from memory or a list of ideas.
That's the only real way to work IMHO. Life is much too short to adhere to some restrictive design frameworks & plans. Software should be art, not rote mechanics.
Going to show this to anyone that thinks they need to build some optimized productivity tool stack before they can do their work.
Don't forget that John Carmack is arguably a programming genius, 3-4 standard deviations above average. Most of us can't maintain the same amount/depth of mental maps as he can, so we need tools to help us
On top of that, Carmack was essentially the singular engineer on his projects. Most others were concerned with making levels, assets, music, etc.
There were others (sorry Abrash and Cash) in the codebase but it was largely John. Which means his bus factor was insanely high. He was the definition of a silo of knowledge. He also used this to his advantage, knowing the company could not replace him.
Most projects of a certain size cannot and do not want that dynamic. It is not a healthy dynamic once there’s some number of people working in close proximity.
I'd say most of us do not have this kind of focus. He actually has two focuses: strategic focus and tactical focus. Strategic focus means that he devotes a good part of his life into building a virtual world and concentrates on rendering algorithms. Tactical focus means that he can work 10+ hours daily for every day for a large part of his life.
Most of us would be lucky to get a quarter of those two focuses.
Most of us would be lucky to get a quarter of those two focuses.
It's easy for him since he wrote most of the code himself so he knows how it all works and fits together so short notes are all it takes to get the clue, but good luck finding your way around projects where you didn't write 90% of the code and it's constantly changing under your nose from other people's commits.
I currently work every day on a codebase that is >95% not mine and changing, and its very fun. Some days I'm just as productive as on my own projects, sometimes 1% of that.
I think there is great value in letting yourself enter this hacker flow state on other people's code - its new and exciting.
I think there is great value in letting yourself enter this hacker flow state on other people's code - its new and exciting.
Glad to see this, I'm a mega John fanboy as they come but the reality is this is close to the ideal working env for a hacker of his talents. The single biggest hurdle to good code is somebody else touching it and the other major hurdle is not owning the company/product direction.
Again, I am happy to recognize him as a genius no doubt, but I couldn't imagine he would've lasted in a CRUD Java gulag. Those places... break people.
Again, I am happy to recognize him as a genius no doubt, but I couldn't imagine he would've lasted in a CRUD Java gulag. Those places... break people.
Thanks for sharing. Really exciting to see how John Carmack would take notes for his work logs. I don’t really have an elaborate system for my own process so I love this because it gives me ideas for improving my own system. I did not expect that John Carmack’s logs would be readable. They’re a lot of fun. Here’s two of my favorite snippets:
> There will be a single master server running here at id. Whenever anyone starts up a server, it will register itself with the master server, and whenever a client wants to start a game, it will inquire with the master to find out which servers are available.
> After hearing many arguments against the single master server, ranging from coherent and well reasoned to paranoid whining, I now agree that the single global master server isn't sufficient.
> During the R&D phase, there will still be only the single server, but after all the kinks get worked out, I will allow a small number of sites to run private master servers. This will not be a general release, but only to properly licensed third parties. That will still allow me to collect my 100% coverage data, and it will prevent a single network/computer/software failure from preventing all QuakeWorld play.
Must have been so exhilarating to be pushing the bleeding edge with early solutions in this space. The conversations they were having must have been awesome!
> There will be a single master server running here at id. Whenever anyone starts up a server, it will register itself with the master server, and whenever a client wants to start a game, it will inquire with the master to find out which servers are available.
> After hearing many arguments against the single master server, ranging from coherent and well reasoned to paranoid whining, I now agree that the single global master server isn't sufficient.
> During the R&D phase, there will still be only the single server, but after all the kinks get worked out, I will allow a small number of sites to run private master servers. This will not be a general release, but only to properly licensed third parties. That will still allow me to collect my 100% coverage data, and it will prevent a single network/computer/software failure from preventing all QuakeWorld play.
Must have been so exhilarating to be pushing the bleeding edge with early solutions in this space. The conversations they were having must have been awesome!
I don't get the feeling from Carmack's logs that he was exactly agreeable to work with. (Esp. if you were Romero, Tom Hall, American McGee...)
One notable thing in David Kushhner's Masters of Doom is that he seems to try to set up Carmack as a bit of a villain or at least an antagonist, though Carmack is and was already so beloved that most people don't seem to notice. You could say that that's Kushner trying to shoehorn in a dramatic structure that he thinks makes for a more entertaining story, but maybe it also reflects parts of the reality that most people don't know about or don't want to know about.
Having recently read Romero’s “Doom Guy” autobiography, I certainly got a sense of that. Seems that Carmack became kind of almost a bully knowing all the other stakeholders depended solely upon him, and he could not be replaced. Used the threat of his departure as a bargaining chip to get exactly what he wanted.
Romero however seems almost apologetic for Carmacks actions. My guess is to spare Carmacks feelings, if he has those.
Romero however seems almost apologetic for Carmacks actions. My guess is to spare Carmacks feelings, if he has those.
Yeah romero seems to take the high road, attributing some of Carmack behavior to stress, but he really seemed like a tyrant of a boss who was uninterested in accommodating anyone
Romero was fired during Quake development for playing lan Doom instead of working.
Do you have any examples?
Actually not finding any references in his planfiles to Hall, but check this out on "the august quakeworld logs"
I also found the tone in his plan update about American McGee's dismissal rather... casual:
aug 8:
Romero is now gone from id.
There will be no more grandiose statements about our future projects.
I can tell you what I am thinking, and what I am trying to acomplish, but all I promise is my best effort.
I also found the tone in his plan update about American McGee's dismissal rather... casual:
American McGee has been let go from Id.
His past contributions include work in three of the all time great games (DOOM 2, Quake, Quake 2), but we were not seeing what we wanted.
Thank you, interesting stuff!
Huh. Coincidental similarities with my own work log that I've been keeping since 2007 are striking. Even down to using asterisks to mark done items (though I've since switched to the org-style '- [X]') and equal sign followed by a space and a date to start an entry, though my inspiration was actually POD (Perl's Plain Old Documentation format).
My file(s) (it eventually felt too big and I split it up by year, which is also an opportunity to forget about the never-going-to-do items that tend to collect at the bottom) used to be specific to the job I started in 2007, but I ended up using it more and more for personal things, too. Individual projects might have their own TODO files, but my main 'what am I going to do today' keeps going in good old 2023-timelog.txt. Mine might look denser than John Carmack's but then I have a lot of things like
My file(s) (it eventually felt too big and I split it up by year, which is also an opportunity to forget about the never-going-to-do items that tend to collect at the bottom) used to be specific to the job I started in 2007, but I ended up using it more and more for personal things, too. Individual projects might have their own TODO files, but my main 'what am I going to do today' keeps going in good old 2023-timelog.txt. Mine might look denser than John Carmack's but then I have a lot of things like
- [X] Start the laundry
- [X] Feed cats AGAIN omg
- [X] Baby-proof the basement door
- [X] $job: Figure out why `mvn spring-boot:run` doesn't f!&#ng work
> When I accomplish something, I write a * line that day.
Nice. When I accomplish something, a few weeks later it comes back and tells me the solution I've used is wrong, and I should've done something else instead, so I'm always hesistant to set the "fixed" flag immediately after fixing something...
Nice. When I accomplish something, a few weeks later it comes back and tells me the solution I've used is wrong, and I should've done something else instead, so I'm always hesistant to set the "fixed" flag immediately after fixing something...
The thing I picked up from this is that it’s fine to have very short notes. The false starts with my engineering journal are, I think, partly because I write it like documentation. I should just write terse bullets. If I badly need to know more detail, that bullet and date is likely enough to excavate some commits.
You might enjoy something that takes advantage of this type of note-taking, like logseq (https://logseq.com/). The way I understand it (I haven't tried it out yet) is that it builds up hierarchies from bullet lists and can organize your knowledge base with them in mind, which means your daily notes can have a hierarchical bullet list and potentially you could query for every day you worked on a particular feature in a particular project very easily.
I think this misses the point of daily note taking, at least for me. I don’t care about anything more than a week old and really only a couple of days because all I’m using it to do is organise myself in the near future and give myself a little reward every time I finish something. I keep it public so people can also see what I’ve been up to. Insights into work are better left to other tools that also track work not someone’s personal notes.
Is it just me, or the work logged by Carmack for a single day seems like a plan for a two week sprint in Scrum, or even a full (3-month) Program Increment in Scaled Agile Framework (SAFe)?
- No hour a day (conservatively…) lost to meetings and other activities that exist to generate data for managers to make pretty graphs out of.
- No hour a day lost on PR reviews (reviewing and being reviewed).
- No hour a day pairing on someone else’s task.
- No two hours lost because some part of your hellishly-complex stack and set of alpha-quality vendor tools decided to shit itself today for no reason.
- No hour babysitting yesterday’s code through CI and testing et c.
- No hour a day lost to context-switching from the above and a dozen other distractions.
- Oh look there’s only an hour left in which to actually produce code in one eight-hour day.
- No hour a day lost on PR reviews (reviewing and being reviewed).
- No hour a day pairing on someone else’s task.
- No two hours lost because some part of your hellishly-complex stack and set of alpha-quality vendor tools decided to shit itself today for no reason.
- No hour babysitting yesterday’s code through CI and testing et c.
- No hour a day lost to context-switching from the above and a dozen other distractions.
- Oh look there’s only an hour left in which to actually produce code in one eight-hour day.
I’m an architect at my company but we’re in a bind with a particular project that I had started a couple years ago, so they temporarily assigned me to basically one-man it over the finish line.
Aside from the stress of the deadline and knowing that I’m going to get stuck being the expert on this project forever, it’s been pretty nice (and productive) just working in peace and quiet with no bullshit scrum ceremonies and navel gazing as distractions. Actually reminded me of why I like programming, and that the things I hate about my career is the fact the organizations spend a lot of time keeping you from actually performing it for some reason.
Aside from the stress of the deadline and knowing that I’m going to get stuck being the expert on this project forever, it’s been pretty nice (and productive) just working in peace and quiet with no bullshit scrum ceremonies and navel gazing as distractions. Actually reminded me of why I like programming, and that the things I hate about my career is the fact the organizations spend a lot of time keeping you from actually performing it for some reason.
> No hour a day (conservatively…) lost to meetings and other activities that exist to generate data for managers to make pretty graphs out of.
IIRC even in the Doom 3 and probably also Rage days Carmack had mentioned that they didn't really do any meetings, if they needed they just discussed things in the kitchen (or something like that).
It did help that the team was small though (IIRC Doom 3 was made by ~25 people total).
IIRC even in the Doom 3 and probably also Rage days Carmack had mentioned that they didn't really do any meetings, if they needed they just discussed things in the kitchen (or something like that).
It did help that the team was small though (IIRC Doom 3 was made by ~25 people total).
>- Oh look there’s only an hour left in which to actually produce code in one eight-hour day.
Usually around 7pm, once everybody's left for the day.
Usually around 7pm, once everybody's left for the day.
Well, it is Carmack we're talking about here. He's well known as a prolific programmer prodigy ;)
But also, some other things to note:
* A lot of "agile" development in corporate environments is anything but agile because of overhead in horizontally scaling human gray meat (until we get neural interfacing between one another or something)
* It was a simpler time back then. Carmack was coding against a much simpler architecture, with significantly fewer variants.
* It was a simpler time back then. Carmack could focus on blitting pixels to the screen as fast as possible, rather than spending 6 months trying to wrap his head around Vulkan.
* It was a simpler time back then. Carmack didn't have to worry about building for Windows, macOS and Linux, and iOS. And Android. And ...
* It was a simpler time back then. Carmack didn't need to worry about accessibility requirements. Web service integrations. Digital distribution complexitities. etc...
Even in the modern day there's still people who get prodigious amounts of work done when they can focus on doing something they like doing, and the stars align. A good recent example off the top of my head in game development is The Witness. Jonathan Blow + 2-3 other programmers IIRC.
But also, some other things to note:
* A lot of "agile" development in corporate environments is anything but agile because of overhead in horizontally scaling human gray meat (until we get neural interfacing between one another or something)
* It was a simpler time back then. Carmack was coding against a much simpler architecture, with significantly fewer variants.
* It was a simpler time back then. Carmack could focus on blitting pixels to the screen as fast as possible, rather than spending 6 months trying to wrap his head around Vulkan.
* It was a simpler time back then. Carmack didn't have to worry about building for Windows, macOS and Linux, and iOS. And Android. And ...
* It was a simpler time back then. Carmack didn't need to worry about accessibility requirements. Web service integrations. Digital distribution complexitities. etc...
Even in the modern day there's still people who get prodigious amounts of work done when they can focus on doing something they like doing, and the stars align. A good recent example off the top of my head in game development is The Witness. Jonathan Blow + 2-3 other programmers IIRC.
He was building for at least Windows and Linux, and didn't have OpenGL so he was doing all the 3D manually. Plus assembly code, hardware specific versions like Verite, had to handle all the raw networking code, wrote tools to work with assets and process levels, also wrote Quake C, encryption to unlock the full game on the shareware Cd...
Sure, Cash, Abrash and Romero were helping out
Sure, Cash, Abrash and Romero were helping out
Everyone serious about gamedev at his age would be well versed in assembly language and such. It's unthinkable nowadays but normal for graphics programmers in 80s and early-mid 90s.
You can do it too if you follow his steps. I mean by programming Apple ][ and then IBM PC in assembly.
You can do it too if you follow his steps. I mean by programming Apple ][ and then IBM PC in assembly.
Quake 3, I do believe, had it's own shader language so the designers could have more control over visual effects.
https://icculus.org/gtkradiant/documentation/Q3AShader_Manua...
The dude was definitely doing stuff no one else had ever done. Then again I have a 90's game dev book that covers ASM as well as manufacturing then programming your own sound card using the parallel port so... you're not wrong.
https://icculus.org/gtkradiant/documentation/Q3AShader_Manua...
The dude was definitely doing stuff no one else had ever done. Then again I have a 90's game dev book that covers ASM as well as manufacturing then programming your own sound card using the parallel port so... you're not wrong.
Yeah I agree. He is definitely doing new stuffs no one is doing. I don't really think it's realistic for any programmer to set a such high objective.
Abrash did most of the graphics related assembly IIRC
> He was building for at least Windows and Linux
Are you sure about that? I remember in Doom 3 era Carmack was rocking a fancy NeXTStep computer and doing cross platform development. But before that I'm pretty sure everything was a strictly Windows affair...
Wikipedia seems to suggest in the first line that it was originally released for Linux. But the "Ports" section it mentions that:
> The first port to be completed was the Linux port Quake 0.91 by id Software employee Dave D. Taylor using X11 on July 5, 1996
And on that topic:
> In late 1996, id Software released VQuake, a source port of the Quake engine to support hardware accelerated rendering on graphics cards using the Rendition Vérité chipset.
> and didn't have OpenGL so he was doing all the 3D manually
So in other words he could focus on the fundamentals of doing vector math and rasterizing pixels, rather than worrying about 600 different incompatible OpenGL extensions, pipeline stalls, and memory management bugs?
> Plus assembly code...
Assembly isn't that hard. Pokemon Red/Blue was written entirely in assembly.
> had to handle all the raw networking code
Again, not that hard when all you're doing is blasting out UDP packets on a very simple network. You didn't have to worry about double NAT, people didn't expect your game to work for diverse peers connected from Germany to Belgium.
> wrote tools to work with assets and process levels
I think Romero wrote a lot of the tooling. Side note - have you read Masters of Doom? It goes into a lot of this stuff and is a great read.
> encryption to unlock the full game on the shareware
I couldn't find anything online but I doubt this was anymore more than some xor + rot13, it's not like Carmack was also Daniel J. Bernstein in disguise :) Back then the state of computer security was, well, rather nascent.
I hope this comment doesn't come across as contrarian. I also hope it doesn't sound like I'm trying to diminish the achievements of Carmack. He's a role model for me personally as a programmer. And he and his mates spawned an entire game genre that I have enjoyed for ... an amount of time I'd rather not disclose or think too much about!
The original point I was trying to make is thus: computers, and computing, have steadily become more and more powerful, which results in more and more complexity, and progressively more unwieldy abstractions to deal with all that complexity. Back when Carmack was cutting his teeth, computers were still fairly early on that complexity curve.
Are you sure about that? I remember in Doom 3 era Carmack was rocking a fancy NeXTStep computer and doing cross platform development. But before that I'm pretty sure everything was a strictly Windows affair...
Wikipedia seems to suggest in the first line that it was originally released for Linux. But the "Ports" section it mentions that:
> The first port to be completed was the Linux port Quake 0.91 by id Software employee Dave D. Taylor using X11 on July 5, 1996
And on that topic:
> In late 1996, id Software released VQuake, a source port of the Quake engine to support hardware accelerated rendering on graphics cards using the Rendition Vérité chipset.
> and didn't have OpenGL so he was doing all the 3D manually
So in other words he could focus on the fundamentals of doing vector math and rasterizing pixels, rather than worrying about 600 different incompatible OpenGL extensions, pipeline stalls, and memory management bugs?
> Plus assembly code...
Assembly isn't that hard. Pokemon Red/Blue was written entirely in assembly.
> had to handle all the raw networking code
Again, not that hard when all you're doing is blasting out UDP packets on a very simple network. You didn't have to worry about double NAT, people didn't expect your game to work for diverse peers connected from Germany to Belgium.
> wrote tools to work with assets and process levels
I think Romero wrote a lot of the tooling. Side note - have you read Masters of Doom? It goes into a lot of this stuff and is a great read.
> encryption to unlock the full game on the shareware
I couldn't find anything online but I doubt this was anymore more than some xor + rot13, it's not like Carmack was also Daniel J. Bernstein in disguise :) Back then the state of computer security was, well, rather nascent.
I hope this comment doesn't come across as contrarian. I also hope it doesn't sound like I'm trying to diminish the achievements of Carmack. He's a role model for me personally as a programmer. And he and his mates spawned an entire game genre that I have enjoyed for ... an amount of time I'd rather not disclose or think too much about!
The original point I was trying to make is thus: computers, and computing, have steadily become more and more powerful, which results in more and more complexity, and progressively more unwieldy abstractions to deal with all that complexity. Back when Carmack was cutting his teeth, computers were still fairly early on that complexity curve.
> Are you sure about that? I remember in Doom 3 era Carmack was rocking a fancy NeXTStep computer and doing cross platform development. But before that I'm pretty sure everything was a strictly Windows affair...
By Doom 3 NeXTSteps were way obsolete and the company had already been bought by Apple long before. He did show the Doom 3 tech first on a Mac at a WWDC though (and later did the same for Rage).
NeXTStep was used for Doom 1 and Quake 1 but by Quake 2 they had switched to Windows NT based computers (with a second Win95 computer for testing - and some artists still used DOS-based software like Deluxe Paint).
> I think Romero wrote a lot of the tooling.
AFAIK Romero wrote the editor for Doom and previous games but Carmack wrote most of the editor for Quake (the whole "brush" idea was Carmack's). Romero has mentioned a few times that he wasn't happy with the editor's usability. AFAIK by that time Romero spent more time on working on the levels (which were more time consuming to make than the Doom ones) and the QuakeC scripts.
> have you read Masters of Doom? It goes into a lot of this stuff and is a great read.
Indeed, i have read MoD, it is a neat book. One of these days i want to also read Romero's "Life in First Person" too.
> I couldn't find anything online but I doubt this was anymore more than some xor + rot13
It was a little more involved than that, there is a blogpost series[0] about it from someone who tried to reverse engineer and reimplement the original qcrack (which calculated a decryption key). The original qcrack was made almost instantly though.
IIRC from Masters of Doom, Carmack didn't really like the idea (most likely he expected people to crack it quickly).
[0] https://faehnri.ch/finished-with-qcrack/
By Doom 3 NeXTSteps were way obsolete and the company had already been bought by Apple long before. He did show the Doom 3 tech first on a Mac at a WWDC though (and later did the same for Rage).
NeXTStep was used for Doom 1 and Quake 1 but by Quake 2 they had switched to Windows NT based computers (with a second Win95 computer for testing - and some artists still used DOS-based software like Deluxe Paint).
> I think Romero wrote a lot of the tooling.
AFAIK Romero wrote the editor for Doom and previous games but Carmack wrote most of the editor for Quake (the whole "brush" idea was Carmack's). Romero has mentioned a few times that he wasn't happy with the editor's usability. AFAIK by that time Romero spent more time on working on the levels (which were more time consuming to make than the Doom ones) and the QuakeC scripts.
> have you read Masters of Doom? It goes into a lot of this stuff and is a great read.
Indeed, i have read MoD, it is a neat book. One of these days i want to also read Romero's "Life in First Person" too.
> I couldn't find anything online but I doubt this was anymore more than some xor + rot13
It was a little more involved than that, there is a blogpost series[0] about it from someone who tried to reverse engineer and reimplement the original qcrack (which calculated a decryption key). The original qcrack was made almost instantly though.
IIRC from Masters of Doom, Carmack didn't really like the idea (most likely he expected people to crack it quickly).
[0] https://faehnri.ch/finished-with-qcrack/
To be fair we don't have 99% of those problems and still manage to deliver fuck all.
I like the cut of your jib
Peter : Well, I generally come in at least fifteen minutes late, ah, I use the side door - that way Lumbergh can't see me, heh heh - and, uh, after that I just sorta space out for about an hour. (...) I just stare at my desk; but it looks like I'm working. I do that for probably another hour after lunch, too. I'd say in a given week I probably only do about fifteen minutes of real, actual, work.
(...)
Bob : What if - and believe me this is a hypothetical - but what if you were offered some kind of a stock option equity sharing program. Would that do anything for you?
Peter : I don't know, I guess. Listen, I'm gonna go. It's been really nice talking to both of you guys.
Bob : Absolutely, the pleasure's all on this side of the table, trust me.
Peter : Good luck with your layoffs, all right? I hope your firings go really well.
(...)
Bob : What if - and believe me this is a hypothetical - but what if you were offered some kind of a stock option equity sharing program. Would that do anything for you?
Peter : I don't know, I guess. Listen, I'm gonna go. It's been really nice talking to both of you guys.
Bob : Absolutely, the pleasure's all on this side of the table, trust me.
Peter : Good luck with your layoffs, all right? I hope your firings go really well.
I am not sure I would consider much of what he did very simple (or easy) compared to what most of us are doing today. The last few chapters of Michael Abrash's Black Book is about his work with Quake (he was involved doing some of the graphics code together with Carmack) and it is pretty hardcore low-level advanced things they were doing. Remember they were software rendering everything in the first version.
https://github.com/neonkingfr/AbrashBlackBook
And also they did pretty soon support MSDOS, Windows 95, and Linux (and possibly some more platforms?). In addition to supporting software rendering, 3Dfx, OpenGL, and possibly some more 3D API.
https://github.com/neonkingfr/AbrashBlackBook
And also they did pretty soon support MSDOS, Windows 95, and Linux (and possibly some more platforms?). In addition to supporting software rendering, 3Dfx, OpenGL, and possibly some more 3D API.
Didn't he code on Solaris or something weird in the workstation family and port quake over to dos? I only remember him having a giant CRT monitor where he'd sit and code for photos back in the 90s
I think it’s more so that when you are an expert in a particular system and you have very little bureaucracy/overhead in any particular task you’re able to get a lot more done.
I was watching a video from one of the creators of Fallout and he was talking about how things that used to take a day now take 2 weeks for similar sort of reasons: https://youtu.be/LMVQ30c7TcA?si=eJm_u-i1xwttfcRL
Our industry in general has added a lot of overhead and bureaucracy and does everything overly cautiously in comparison to back then. Things take exponentially longer to do in software development today. You can also observe this in how long it takes a startup to build a feature vs a FANG company.
I was watching a video from one of the creators of Fallout and he was talking about how things that used to take a day now take 2 weeks for similar sort of reasons: https://youtu.be/LMVQ30c7TcA?si=eJm_u-i1xwttfcRL
Our industry in general has added a lot of overhead and bureaucracy and does everything overly cautiously in comparison to back then. Things take exponentially longer to do in software development today. You can also observe this in how long it takes a startup to build a feature vs a FANG company.
I'm not sure it's fair to say that the industry has added overhead versus the 90s. Unless you're talking about gamedev, which I can't comment about. But it's hard to say that tech in general is slower moving as an industry than thirty years ago; I think there's more nuance to it than that. What exactly that nuance is I'm not completely sure, but here are some counterexamples:
Intel shifted the entire direction of its company away from memory and into microprocessors as early as the 1980s, in response to smaller, allegedly faster moving Japanese competitors.
IBM has been a slow-moving behemoth for decades; the story of how DOS began is an idiomatic David vs Goliath tale of the industry.
Apple debatably rose to prominence on the back of tech lifted from Xerox, which for one reason or another (maybe they were too confident in their fax machines) didn't ship their own tech.
Google was at one point a fast-moving startup, up against slow-moving competitors like AltaVista, arguably Yahoo, MSN.
Amazon's original web stack was written in C, iirc. I personally would have a hard time arguing that things done today in web development could be done faster in C.
Intel shifted the entire direction of its company away from memory and into microprocessors as early as the 1980s, in response to smaller, allegedly faster moving Japanese competitors.
IBM has been a slow-moving behemoth for decades; the story of how DOS began is an idiomatic David vs Goliath tale of the industry.
Apple debatably rose to prominence on the back of tech lifted from Xerox, which for one reason or another (maybe they were too confident in their fax machines) didn't ship their own tech.
Google was at one point a fast-moving startup, up against slow-moving competitors like AltaVista, arguably Yahoo, MSN.
Amazon's original web stack was written in C, iirc. I personally would have a hard time arguing that things done today in web development could be done faster in C.
It’s not tech in general that’s slower moving, but rather that software development is slower moving today (in my opinion).
To launch a minor feature at a modern tech company you need to:
- pitch your idea to your manager and get alignment
- get approval from your skip manager and buy-in from your product managers
- align your idea with your partner team’s roadmap
- go through a design review with your team
- go through a design review with your principal engineers
- write a task breakdown
- actually write the code
- time to coordinate the launch of your feature toggle with 6 partner teams
- oops there was a minor bug you need to roll back your feature and resolve it overnight
How much of this overhead existed in the 90s?
If a single lone genius like Ken Thompson or John Carmack wants to write a new feature or product and get it out to customers they have 10x+ the work today (at a modern tech company).
To launch a minor feature at a modern tech company you need to:
- pitch your idea to your manager and get alignment
- get approval from your skip manager and buy-in from your product managers
- align your idea with your partner team’s roadmap
- go through a design review with your team
- go through a design review with your principal engineers
- write a task breakdown
- actually write the code
- write tests for the code
- write integration tests for the code
- fix build issues
- push multiple code reviews and respond to comments
- whoops you need to rebase and that shared component you used just changed it’s interface yesterday breaking your tests
- your integration tests failed in preprod blocking your coworker’s launch, better fix that
- time to coordinate the launch of your feature toggle with 6 partner teams
- oops there was a minor bug you need to roll back your feature and resolve it overnight
How much of this overhead existed in the 90s?
If a single lone genius like Ken Thompson or John Carmack wants to write a new feature or product and get it out to customers they have 10x+ the work today (at a modern tech company).
What about a "modern tech company" with only one (or maybe two) workers ?
There are some sweet spots to be found in software development productivity.
Finding them is an art/craft, and very sensitive to the project/company context, the people you have available, how the work will be distributed, etc. It includes making process lightweight by default, and having a good sense of when to use something non-lightweight.
In the right circumstances, a few top "programmers" with great team software engineering sense, and someone representing product sense, unencumbered by BS, can usually wipe the floor with most contemporary much-larger teams.
But starting off a startup by saying "We'll do Leetcode rituals so we know we'll hire aspiring techbros who spent their spare time at Stanford memorizing those, and we'll (pretend to) use this fashionable branded lifecycle process designed for companies that have no idea what they're doing but have a lot of warm bodies to fumble blindly through it, and ignore unfashionable process tools that we were confidently told don't work by students with zero experience based on what a professor with zero experience told them, and this huge list of popular tech we heard of and will never understand will be our stack, and then we can show promise to get to the next funding round and hire even more warm bodies..." is one way to make the road to finding effective expertise much longer. :)
Finding them is an art/craft, and very sensitive to the project/company context, the people you have available, how the work will be distributed, etc. It includes making process lightweight by default, and having a good sense of when to use something non-lightweight.
In the right circumstances, a few top "programmers" with great team software engineering sense, and someone representing product sense, unencumbered by BS, can usually wipe the floor with most contemporary much-larger teams.
But starting off a startup by saying "We'll do Leetcode rituals so we know we'll hire aspiring techbros who spent their spare time at Stanford memorizing those, and we'll (pretend to) use this fashionable branded lifecycle process designed for companies that have no idea what they're doing but have a lot of warm bodies to fumble blindly through it, and ignore unfashionable process tools that we were confidently told don't work by students with zero experience based on what a professor with zero experience told them, and this huge list of popular tech we heard of and will never understand will be our stack, and then we can show promise to get to the next funding round and hire even more warm bodies..." is one way to make the road to finding effective expertise much longer. :)
The point of SAFe is so that remote workers can be as productive as Carmack on their own side gigs during the ceremonial duties and meetings. I rather like it!
It depends on yohr programmers.
At $JOB, we had one programmer who was absolutely slaying. We would plan a sprint, and two days later more than 1/2 of the board was done and in review, mostly done by him. When I joined, I did a similar thing, until I realized that its no fun to just chew through all tasks for the team and then only do reviews for the rest of the sprint. So instead now I mix reviews and writing code, which managers like to see anyways, and progress is a magnitude slower. Setting up a test env, context switching to a problem, code review, manual testing, writing comments, etc. definitely takes a lot more time usually than solving that same issue.
I think it definitely depends on the programmers, though. I've seen people take a week for what, for maybe another dev, would probably take a day.
One of the ideas of scrum and sprints is that everyone does a bit of everything, right? And that is long-term good, short term a bit of a hindrance.
The guy who could do that task in one day has a lot of knowledge about that part of the code, and if he always does that, and then leaves, there's a knowledge gap. If instead we let someone else spend a week on the task, because they have to figure out how everything works and is structured, then we have two people who have this knowledge at the end.
In my experience, there are also big skill gaps between people, and some are just much, much faster than others. Carmack is likely on the higher end
I think it definitely depends on the programmers, though. I've seen people take a week for what, for maybe another dev, would probably take a day.
One of the ideas of scrum and sprints is that everyone does a bit of everything, right? And that is long-term good, short term a bit of a hindrance.
The guy who could do that task in one day has a lot of knowledge about that part of the code, and if he always does that, and then leaves, there's a knowledge gap. If instead we let someone else spend a week on the task, because they have to figure out how everything works and is structured, then we have two people who have this knowledge at the end.
In my experience, there are also big skill gaps between people, and some are just much, much faster than others. Carmack is likely on the higher end
I reacted to how his way of working sounded actually agile (vs some method sold as agile but mostly consisting of a lot of processes and automatic tools to keep everyone from having any hope of being agile), like:
> When I accomplish something, I write a * line that day.
> Whenever a bug / missing feature is mentioned during the day and I don't fix it, I make a note of it. Some things get noted many times before they get fixed.
> Occasionally I go back through the old notes and mark with a + the things I have since fixed.
> When I accomplish something, I write a * line that day.
> Whenever a bug / missing feature is mentioned during the day and I don't fix it, I make a note of it. Some things get noted many times before they get fixed.
> Occasionally I go back through the old notes and mark with a + the things I have since fixed.
Move fast, gib stuff.
I can complete, maybe half the tickets of a sprint, in one day, if I get everything I need and have a full day without disturbance.
Of course it's not going to be as difficult as some of his tasks.
Of course it's not going to be as difficult as some of his tasks.
Is the code a mess? From the notes it looks like the code is a mess, but don't want to assume.
Indeed, and of course for a full team of developers, not a single person.
Carmack is a god.
Carmack is a god.
Now, if only I knew what was in John Carmack's scratch paper as well...
Interesting that my notes are almost identical for my web development job.
Mine are more like this with headings for each date.
===
2023-10-04
Client Name - monthly maintenance. 30m
Client Name - Attempt debug of mysql 8 upgrade issue. 1h 30m
...
Mine are more like this with headings for each date.
===
2023-10-04
Client Name - monthly maintenance. 30m
Client Name - Attempt debug of mysql 8 upgrade issue. 1h 30m
...
I use 3 +'s or 3 *'s in my notes.
Clearly Carmack is 3x as efficient as me.
Clearly Carmack is 3x as efficient as me.
Meta-comment: it’s profoundly amusing to read the surprised reactions to Carmack’s productivity.
This is what a great programmer who is a domain expert looks like when operating in an org structure that lets them focus on what they’re good at. You’re lucky if you get one of those three things, honestly.
I worry that most orgs are not set up to even allow this level of productivity nowadays, because they’re too insistent on ironing out the peaks of productivity to try to fix the valleys. Also, tech culture is still so bizarrely focused on the idol of tooling fixing the programming problem that we see people like Carmack and remember, if only vaguely, that programmer skill is still a very real thing.
This is what a great programmer who is a domain expert looks like when operating in an org structure that lets them focus on what they’re good at. You’re lucky if you get one of those three things, honestly.
I worry that most orgs are not set up to even allow this level of productivity nowadays, because they’re too insistent on ironing out the peaks of productivity to try to fix the valleys. Also, tech culture is still so bizarrely focused on the idol of tooling fixing the programming problem that we see people like Carmack and remember, if only vaguely, that programmer skill is still a very real thing.
You don't have to be a great programmer to be that productive.
I am not, but I've also been fortunate to have periods in my life where I just got to pour 70-90 hours a week into a programming project, sometimes doing multiple 16-20 hour sessions over night in cafés, then taking a few days off to recover, with no distractions. Including commercial work, at a place with 20 or so other good engineers that allowed for a one-meeting-a-week culture because we just got each other and the tech stack was narrow enough to keep us compatible.
The sheer amount of stuff you can get done and the level of satisfaction are amazing. I will always love those times.
Everything you say about environment and org structure I fully agree with. But you don't have to be exceptional or gifted to benefit from an environment that trusts a creative worker to solve problems.
I am not, but I've also been fortunate to have periods in my life where I just got to pour 70-90 hours a week into a programming project, sometimes doing multiple 16-20 hour sessions over night in cafés, then taking a few days off to recover, with no distractions. Including commercial work, at a place with 20 or so other good engineers that allowed for a one-meeting-a-week culture because we just got each other and the tech stack was narrow enough to keep us compatible.
The sheer amount of stuff you can get done and the level of satisfaction are amazing. I will always love those times.
Everything you say about environment and org structure I fully agree with. But you don't have to be exceptional or gifted to benefit from an environment that trusts a creative worker to solve problems.
A game is art.
The most efficient tool I know to kill art and the artist's soul is probably Jira.
The most efficient tool I know to kill art and the artist's soul is probably Jira.
Non technical product managers
coming up with ideas to make more productive. Happy to work in a pure dev environment now. No sprints, no deadlines. Just goals.
You would need to find some small gig which allow you the freedom to do whatever you are good at. It's difficult indeed. I'd also say that most smaller gigs are struggling with financials so cannot hire really good people.
[deleted]
Reading this log, I can't stop thinking how clear things needed to be in his head to advance at that pace. Like he already had everything programmed in his mind, he was just transcribing it for the computer.