The Duct Tape Programmer (2009)

I really feel as if the author should put the most important information right at the beginning of his post, namely that his coding philosophy is "you’re not here to write code; you’re here to ship products."

Of course the way to properly tackle these two objectives is going to be vastly different, and Joel just has the second objective, rather than the first. The problem is that almost everyone who complains about what you might call 'bad code' thinks that "writing good code" is the end goal, whereas almost everyone who writes said 'bad code' has "shipping products" as their end goal.

From the outside that might look like a difference in design philosophy, but really it's more a difference between someone who codes well because they care about their product and someone who codes badly because they have to put food on the table.

> Also, real programmers don't say DWORD.

That's just silly. DWORD is a macro for an unsigned 32-bit integer. It has been around since the first version of Windows.h, along with BYTE and WORD for unsigned 8-bit and 16-bit integers.

Any old-time Win16 or Win32 programmer like Joel or me would know the term and be likely to use it in the context of Windows programming.

Keep in mind that Windows.h predated the modern definitions like uint32_t by many years. The original Windows developers had to come up with some names for these data types. It doesn't mean they weren't "real" programmers.

Although I suppose, given that floating point processors were far from being standard equipment at the time, you could argue that they were integer programmers...

So one thing I think that gets lost is, to me, the most important quality in code is: how easy is it to debug. Like, I remember once having to maintain this guy's code where he just went crazy on C++ templates. And like, he proved that he's very smart and clever, but it made his code practically unusable since nobody could figure it out, and trying to debug a template masterpiece is like the hardest thing in c++ coding because the errors are impenetrable.

Coding isn't about proving your smartness it's about making something people can use and work with.

I would say the extremes are between no design and some "perfect" design.

It can be done even better. I read an article about that recently.

Nowadays pointers are 64-bit. So the simple xoring already saves 64 bits.

But, in most cases allocated memory blocks are close together, so that xoring of those 64-bit values gives a 32-bit value. So if you ignore the upper half and store the result in 32-bit, you basically save 96 bits. For the cases where the upper half matters, you can store it in an additional hashmap.

But it goes even better, if you allocate blocks and store indices. Like if you allocate blocks of 512 objects each. Then it is likely that the next/prev index is also in that block. Then you can store those indices in 2*8 bits (or just 8 bits if xored again?). In case it is in another block, you use the hashmap again. Then you save up to 120 bits.

The question remains, how do you find that hashmap? The article had a really clever solution. You allocate the blocks as 4K-aligned pages, e.g. by using mmap rather than malloc. Then you put a pointer to the hashmap at the beginning of the page, and when you have a pointer inside the block, you can find the hashmap by rounding the pointer down to the previous aligned position.