There is obviously loads of open source code out there, for example, gcc, nasm, qemu and quite a few game engine, like quake, doom.

I have spent many hours trolling through code trying to understand it, right now back to horde3d, how about you?

Some of the biggies are,

gcc

nasm

idtech engines

qemu

unreal 4

NOFL engine

enemy territory engine

I keep telling myself I need to start looking through open source projects, but just never get around to it.

I never by intent look into any projects, including open-source. There has to be a reason. I have to use these open-source projects in my own projects for me to be interested in them. Even then, only if it's easy to use and actually provide immediate benefit out of the box. If the projects are at all difficult to use, I would look for another one, or perhaps spin my own. Once the projects have provided some benefits, and only when there are defects or lack of features that I would take a peek into the code to see if I can fix it.

I have been through the Quake and Half life code, both of which were interesting as a young developer but don't give me a lot of info relevant to the modern day. I've looked through Ogre 3d, which I always felt was trash.

Unfortunately, code tells you what somebody did, but rarely why or when they did it. It also doesn't tell you if they made the right decision when they did it. Without lots of experience, it's hard to decode the context or history behind many of these things.

Many people here will tell you that looking at other people's code is not productive. I do not agree with them. However it is important to understand that code without context is a tricky thing that can easily mislead. Don't think something is a good idea just because it appears in the code for something that is big or impressive on the surface.

Unfortunately, code tells you what somebody did, but rarely why or when they did it. It also doesn't tell you if they made the right decision when they did it. Without lots of experience, it's hard to decode the context or history behind many of these things.

To that end, I wish Git were just a touch better about diff-ing, because all too often it does something like this:

  function A(){
      // some code
- }
- 
- function B(){
-     // some other code
  }

Where something like deleting all of function B ends up looking like partially editing function A.

It's an idle wish, as I know there is no way for Git to understand all of the corner cases of issues like this, but it would make playing the commit history back much more readable. But if it worked like I wanted, it plus a viewer that animated the changes between commits would be just about a perfect tool for writing tutorials about software development as a continuous pursuit, rather than just program code as an end result.

Unfortunately, code tells you what somebody did, but rarely why or when they did it. It also doesn't tell you if they made the right decision when they did it. Without lots of experience, it's hard to decode the context or history behind many of these things.

I'd love for someone like Carmack to write a book detailing the decisions that went into a given chunk of source.
It would be fascinating to read about what problems were encountered, why they went with a given solution and even what they would have liked to get done.

Unfortunately, I suspect such a project would be almost as much work as writing the code in the first place.

Unfortunately, code tells you what somebody did, but rarely why or when they did it. It also doesn't tell you if they made the right decision when they did it. Without lots of experience, it's hard to decode the context or history behind many of these things.

I'd love for someone like Carmack to write a book detailing the decisions that went into a given chunk of source.
It would be fascinating to read about what problems were encountered, why they went with a given solution and even what they would have liked to get done.

Unfortunately, I suspect such a project would be almost as much work as writing the code in the first place.

I would say there is a lot of Carmack material out there, plenty of youtube videos on various talks, plenty of articles and also the book Master of doom may have a titbit or two, was there another book I read, can't remember.

I would say there is a lot of Carmack material out there, plenty of youtube videos on various talks, plenty of articles and also the book Master of doom may have a titbit or two, was there another book I read, can't remember.

Not really. Masters of Doom is about the history of id, but it doesn't really go into any significant detail about the code.

There are a couple of articles on the web about various open source engines (including the various idtech engines), but AFAIK, all of them are written by a 3rd party, who can only analyse the source code "after the fact". I'm interested to see the evolution of the source.

To be fair, I frequently have no idea why past-me made certain code decisions a year ago, let alone 20+.

To be fair, I frequently have no idea why past-me made certain code decisions a year ago, let alone 20+.

lol, me either! You'd need to be writing the book as you go, but as I said it would take an inordinate amount of effort.