The Duct Tape Programmer (2009)

Really smart people invest time into making their code very readable and at the same time manage to give it the required layers of abstraction and flexibility in a way that does not confuse the reader. They make their code in a way, that enables them or others to write tests for it. They think about the concepts needed in the project. Find a good trade-off between simplicity and flexibility and if you are a true master of finding good abstractions, manage to choose a simple abstraction to get simplicity and flexibility at the same time. At least that is being smart to me.

I spent hours this week debugging a test that kept failing in

  EXPECT_EQ(result.status(), SUCCESS)

I have a similar gripe with Python's unittest: because some of the assertions allow `expected` and `actual` to be interchangeable, there's always some extra mental overhead to remembering which is which. For example, compare this:

  >>> unittest.TestCase().assertEqual(1, 2)
  Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
    File "/usr/lib/python3.9/unittest/case.py", line 831, in assertEqual
      assertion_func(first, second, msg=msg)
    File "/usr/lib/python3.9/unittest/case.py", line 824, in _baseAssertEqual
      raise self.failureException(msg)
  AssertionError: 1 != 2

  assertThat(actual).isEqualTo(expected)

  java.lang.AssertionError: expected:<[guava, dagger, truth, auto, caliper]> but was:<[dagger, auto, caliper, guava]>
    at org.junit.Assert.failNotEquals(Assert.java:835) <2 internal calls>
    at com.google.common.truth.example.DemoTest.testBuiltin(DemoTest.java:64) <19 internal calls>

As they say, "anyone can design a complicated system", but if you're really smart, you can make a simple system. It's no different in programming.

No, that's what business is about. Coding isn't just for business.

I know we are not hired "to write code" but "to ship products", and that everything is done in "sprints" and we must be very agile in doing them because they're always non-stop, and quality comes second (unless, of course, you are really skilled and can ship high quality code in half the time it usually takes), and customers first and "we'll polish it in version 2" and...

I guess I feel "guilty" of writing good code just for the sake of writing good code (and taking time for doing so). At work code comes second, product comes first. I accept it and I try my best, but at the end of the day the code I write at my own pace at home for side projects, now that's the code I like to write.

There is non-linearity here where you beat the "6 month" competitor the following year, because their product is buggy as hell and unmaintainable, but you keep cranking out solid features on your maintainable codebase/infra.

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

Wait what? If you've done any windows coding in C it's practically lingua franca. I think the int{size}_t stuff is way better, but a "word" is common slang, and a double word is like a dword because nobody wants to write that much

> Also, the "next and previous points xor'ed into a DWORD" hack mentioned at the end? This isn't duct tape programming. It's absurdly context-dependent premature optimization

Man I'm writing code for an arduino right now and that kinda optimization isn't rare for a machine with 2k of ram. It's not absurd it's useful to be able to do that. Sure don't do it on your 4ghz intel or whatever but techniques like that are useful.

A well designed solution doesn't feel like duct tape, nor should it be "too clever" with a crazy multiple-inheritance architecture that no one but the author can understand.

In fact, it sounds like the extremes described in this article are both crap developers, with different flavors of crap on the menu.

I insist on solid engineering. Nothing that feels like duct tape, but nothing that approaches over-engineering either. Easy to understand and easy to extend to the point of "OF COURSE this makes sense!"

It's not so much "in the middle" as "robust design vs one or another flavor of garbage." A strong designer is needed to get to that point, and maybe duct tape is better for shipping product than over-engineering, so if you HAVE to choose, the duct tape end of the spectrum is better. But even better to have a solid software architect who can come up with a good solution that people can use and extend and understand.

You're assuming that ductape == bad. What your describing is someone writing bad code, not someone gaffertaping a bunch of modules together to make the _more important_ code work. (instead of re-writing a whole bunch of things to make stuff more "idiomatic" )

This is where innovation tokens come in. You have one innovation token per project, you can spend it on the thing you actually need, or some pointless part of the system that you're bored with maintaining.

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.

Another crazy thing in Z88 is that the maximum amount you could allocate in one 'malloc' call was 256 bytes!