10 ms·

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 Sc

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)?

baal80spam 3y ago
Indeed, and of course for a full team of developers, not a single person. Carmack is a god.
noobface 3y ago
Move fast, gib stuff.
faizshah 3y ago
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 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.
- diatone 3y ago
  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.
  - faizshah 3y ago
    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 - 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 - a couple rounds of AppSec, UX and PM review - 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).
    - BlueTemplar 3y ago
      What about a "modern tech company" with only one (or maybe two) workers ?
gameoverhumans 3y ago
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.
- baz00 3y ago
  To be fair we don't have 99% of those problems and still manage to deliver fuck all.
  - tomcam 3y ago
    I like the cut of your jib
    - ant6n 3y ago
      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.
baz00 3y ago
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!
neilv 3y ago
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. :)
jsanders9 3y ago
Is the code a mess? From the notes it looks like the code is a mess, but don't want to assume.
- bluedino 3y ago
  https://fabiensanglard.net/quakeSource/ https://fabiensanglard.net/quakeSource/
livrem 3y ago
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.
hotnfresh 3y ago
- 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.
- moribvndvs 3y ago
  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.
- badsectoracula 3y ago
  > 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).
- another2another 3y ago
  >- 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.
hnthrowaway0315 3y ago
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.
lionkor 3y ago
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

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)?

baal80spam 3y ago

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

noobface 3y ago

Move fast, gib stuff.

faizshah 3y ago

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

diatone 3y ago
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.
- faizshah 3y ago
  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 - 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 - a couple rounds of AppSec, UX and PM review - 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).
  - BlueTemplar 3y ago
    What about a "modern tech company" with only one (or maybe two) workers ?

gameoverhumans 3y ago

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.

baz00 3y ago
To be fair we don't have 99% of those problems and still manage to deliver fuck all.
- tomcam 3y ago
  I like the cut of your jib
  - ant6n 3y ago
    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.

baz00 3y ago

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!

neilv 3y ago

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

jsanders9 3y ago

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

bluedino 3y ago
https://fabiensanglard.net/quakeSource/ https://fabiensanglard.net/quakeSource/

livrem 3y ago

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.

hotnfresh 3y ago

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

moribvndvs 3y ago
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.
badsectoracula 3y ago
> 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).
another2another 3y ago
>- 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.

hnthrowaway0315 3y ago

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.

lionkor 3y ago

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