Quake related work logs (1996)

Isn't that what programming is like? I guess the main challenge is to avoid lying to yourself by downplaying stuff that is problematic.

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!

I can't help but notice that the days are continuous, with not many (two day) gaps in between.

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.

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.

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

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.

Is this satire

pcj moment

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

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.

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

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.

Do you have any examples?

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.

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.

Indeed, and of course for a full team of developers, not a single person.

Carmack is a god.

Move fast, gib stuff.

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.

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.

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!

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

Is the code a mess? From the notes it looks like the code is a mess, but don't want to assume.

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.

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

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.

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 use 3 +'s or 3 *'s in my notes.

Clearly Carmack is 3x as efficient as me.

A game is art.

The most efficient tool I know to kill art and the artist's soul is probably Jira.

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.

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.