PPSD: The Codenator

“Listen, and understand. That terminator is out there, it can’t be bargained with, it can’t be reasoned with, it doesn’t feel pity or remorse or fear, and it absolutely will not stop…EVER, until you are dead!”
— Kyle Reese, The Terminator

In this day and age, especially in medium-to-large sized, established companies, it’s common for software developers to spend most of their time in meetings. It’s sad but true: There are even developers who brag about how loaded their meeting calendars are.

The worst kind of all meetings is the dreaded regular status meeting where many valuable person-hours go down the drain every week. Tom DeMarco and Timothy Lister really nailed it in their bestselling book Peopleware: “Though the goal may seem to be status reporting, the real intent is status confirmation. And it’s not the status of the work, it’s the status of the boss.”

But while the rest of the team is worshiping the project leader and discussing what could/should/might be done next or at some point in the future, one is already busy implementing and creating facts: the Codenator.

The Codenator is an extremely prolific individual who just can’t sit on his hands. Whereas the Terminator’s mission is to kill, the Codenator’s mission is to code. To him, the keyboard is a weapon of mass construction; he hammers away at it in an endless battle against impossible deadlines, missing specs, and buggy compilers.


Just because he’s such a badass, no-nonsense coding machine, don’t get fooled into assuming that the Codenator comes with a strong physique and a loud voice—not at all: the majority of Codenators appear to be timid or nerdy, at least at first sight. The Codenator doesn’t put much emphasis on clothing, either. All he’s interested in is generating as much software as possible.


One might think that the Codenator holds strong opinions and loves to fight for them. While the former is certainly true, the latter often is not. Being an omega male much more than an alpha male, he avoids direct confrontations and prefers to wage war behind the scenes. If in a design meeting he’s convinced that his approach or idea is superior (and he always is), he agrees with his opponents or at least gives in—just to end the discussion. Then, later, he goes on to implement it his way, anyway.

If he’s not contented with the code of his peers, he doesn’t waste time giving constructive criticism, either; he patiently waits till they are on holiday and then performs a massive overhaul of their components. I’m not exaggerating: I witnessed this happening many years ago when—during the absence of a coworker—a Codenator rewrote a 20 KLOC device driver in two weeks. Needless to say, the Codenator’s design was clearly better plus it fixed all the issues we previously had with the driver. But can you imagine the traumatizing impact this assault had on the component owner, whom it took months to write the original code?

Probably suffering from Asperger’s syndrome, the Codenator is a maverick, hates teamwork, discussions, and compromises. Yet, he’s smart and productive. It’s just his utter lack of people skills in general and empathy in particular, which make him a difficult, if not impossible, team member. You shouldn’t be surprised to hear that he’s unable to take criticism. To him, it’s either his way or the highway.


Remember the scene from Terminator 2 where the Terminator discovers the minigun at the arsenal? Likewise, tools are important to the Codenator as they help him complete his missions. He shows a great level of mastery of the tools he uses daily. Nevertheless, he’s conservative, quite the opposite of an early adopter, and therefore hesitant towards employing new tools. A Codenator is unlikely to try out new programming languages either and will do most of his coding in matured, proven versions of C, C++, and Java. Why? Because the Codenator’s credo is that no new tool or programming language can ever solve the fundamental problem of software development: that people talk instead of code.


If Sarah Connor were a programmer, she’d probably put it this way: “In a world full of code fear, a Codenator might be the sanest choice.” If he just wasn’t such a heartless robot! But don’t attempt to socialize a Codenator. Even if he honestly tried to change, he would soon relapse. And if you push him too hard, it’s very likely that he’ll just pack his bags and leave. Another big mistake would be to put a Codenator in an environment with strict rules, like a scrum team, for instance. Scrum is a very systematic approach to software development and requires lots of coordination through various forms of planning and meetings. That wouldn’t work for him. He’s a Codenator, mind you, not a coordinator.

Instead, assign him to tasks where his harsh personality can be put to good use. Have him work on prototypes, code ports, and performance optimizations, for instance. Especially when requirements are foggy or non-existent, he will close the gaps, come up with pragmatic solutions that help him carry on doing what he loves most: constantly write code. While some highbrow developers might complain that a Codenator’s code is far from aesthetically pleasing, his code is solid and—more importantly—works. A Codenator is the incarnation of the “finished is better than perfect” adage.

To sum it up, despite his weaknesses with people, he’s a must-keep because he’s never afraid to start. Even better, he’s a finisher. A Codenator doesn’t stop when he’s tired—he stops when he’s done.

const_map, anyone?

Today, I want to share a little C++ container class with you that has proved useful over the years: const_map. I finally got around to turning it into something reusable, or so I hope. Special thanks go to John Hinke, who provided awesome feedback.

In simple words, const_map is an associated array, just like good ol’ std::map: a mapping from keys to values which allows you to lookup values by keys:

Contrary to std::map, however, const_map is a read-only container. To set it up, you provide a key/value mapping table to the constructor:

Once a const_map is instantiated, it’s not possible to add or remove key/value pairs anymore:

Just like std::map, const_map’s runtime is O(log(n)). Contrary to std::map, the implementation isn’t based on binary trees but on binary search. Hence, the mapping table must be sorted by key in ascending order.

const_map doesn’t do any heap allocations. All it does is maintain two pointers: one to the beginning and another one to the end of the mapping table. Apart form these two pointers, const_map doesn’t need any other state or housekeeping data. Thus, on a 32-bit platform, const_map instances will cost you eight measly bytes of RAM.

Now, I know there are some embedded cheapskates out there to whom even eight bytes is sometimes too big a sacrifice. If you’re so tight on RAM and are willing to forgo the fancy STL-like interface and rather expend a little bit more typing, you can use the static class member function ‘lookup’ which is completely stateless and doesn’t require an instance:

I’ve mostly used const_map as a replacement for long, unwieldy switch-case abominations. Either to translate values from one data type to another or to determine which action to take based on a given value. In the latter case, my value type was a function pointer or functor.

Share and enjoy!

PPSD: The Statler/Waldorf

“Sarcasm is the last refuge of the imaginatively bankrupt.”
― Cassandra Clare, City of Bones

The legendary “The Muppet Show” featured two older characters, Statler and Waldorf, who sat next to each other in a balcony, always nagging and cracking sarcastic jokes at the expense of others. On various projects, I’ve come across developers who behaved just like them.

Statlers and Waldorfs are typically found in medium-to-large corporations that have been around for quite some time—just like the Statlers and Waldorfs themselves, they usually have a long history with their company.


The Statlers and Waldorfs that I’ve met were always male and clearly above age 40, some of them way into their 50s. They didn’t care much for looks and grooming and were often overweight.

But looks can be deceiving. What really defines Statlers and Waldorfs is not their looks, but rather their mental attitude. There are Statlers and Waldorfs that don’t fit the description above but who are still who they are, even at age 28. In my experience, there are “classic” Waldorf and Statler types and “concealed” Waldorf and Statler types. Mental attitude and looks only coincide in the former type.


Regardless of their age or physical appearance, their mental age is above 70 and even if they show up in the office every day, they retired mentally a long time ago.

At their core, Statlers and Waldorfs are extremely dissatisfied. About what and why this is the case, we don’t know and are unlikely to ever find out. It’s possible that they were once positively enthusiastic about their craft but got severely hurt or disappointed along their way.

All Statlers and Waldorfs have in common that they avoid change like the plague. At first, this comes as a bit of surprise, as one might think that dissatisfied people would happily welcome new approaches, ideas, and tools. Not so for the Statlers and Waldorfs of the world. They’d rather stay miserable for the rest of their lives than give something new a chance.

Unable to accept change in an ever-changing world, the Statlers and Waldorfs become bitter and resentful and express it through endless streams of sarcasm. High-quality production code, however, only trickles out of them—at best. If you give them a task, chances are that they will complain forever about missing requirements, missing documentation, inferior tools, and lack of support from others.


Tools are not highly valued by Statlers and Waldorfs. They use the tools everyone else uses and when asked to pick a programming language, they reach for the top of the TIOBE index; that is, Java or C. If they pick Java, they don’t use any of the features that came out after JDK1.1; should they pick C, K&R C is more than sufficient for them.


I vividly remember the day when I presented a wonderful idea to a Statler/Waldorf type of colleague early in my career. I was so thrilled, so sure that it was a big hit and naively assumed that everyone else was likewise excited. But boy, was I mistaken! Before I had even finished telling my story, the Uber-Statler/Waldorf—with a big smirk on his face—started firing dozens of poisoned darts at me, why it would never work, why it was a ridiculous idea in the first place, and so on. As you can imagine, my motivation dropped to the floor. Days later, I implemented my idea nevertheless. With great success, as it turned out. However, it took days until the Statler/Waldorf finally stopped mocking me.


I’m personally convinced that it’s impossible to reprogram the firmware (or rather wetware) of a Statler/Waldorf; yet, I’m hoping that the following tips help reduce the likelihood of you turning into a Statler/Waldorf zombie yourself:

1. Don’t look old. No, you don’t have to become a Programming Hipster, rather try to blend in with the rest of the team. If you are the only one wearing Birkenstocks, get rid of them. Get rid of those highwater cords and suspenders, too.

2. Don’t talk old. Naturally, as an experienced developer you have seen a lot—good things and bad things. But trust me: nobody wants to hear that story where you implemented toaster control software in 256 bytes of ROM at GE in the late 1970s—over and over again. Would you trust a doctor that pops up at your door and tells you that he has the perfect medical treatment for you? No? That’s why you should never give unsolicited advice, either. Wait until they come to you. Bite your tongue. Most importantly, stop being sarcastic; sarcasm only hurts and is a sign of weakness, not strength.

3. Don’t think old. Over the years, you have probably learned that most problems that projects face these days are not technological but rather sociological in nature. The kind of people and the way they work together has much more influence on the overall success than the choice of programming language. Nevertheless, don’t fight it if the majority of the team wants to give a hip programming language a try on the next project. Trying out new things boosts motivation and extends the knowledge portfolio. Just like life itself, software development is a continuous learning process. Remember the quote from Steve Siebold: “You’re either growing or dying. Stagnation does not exist in the universe.”


Some people build, and some destroy—a fact that can be easily observed by watching children playing with Lego bricks. Waldorf and Statlers are destructive rather than constructive. Maybe they excel as software risk managers; I can imagine that they come up with risks that nobody else has ever thought of. Or perhaps they should work in the testing department where they will use their negativity to find even the most unthinkable bugs. But whatever you do—keep them as far away from your developers as possible.

PPSD: The Programming Hipster

“That proves you are unusual,” returned the Scarecrow; “and I am convinced that the only people worthy of consideration in this world are the unusual ones. For the common folks are like the leaves of a tree, and live and die unnoticed.”
— L. Frank Baum, The Marvelous Land of Oz

After a series of rather technical posts, I feel a strong urge to release some lighter reading. Let me introduce a new series called “people-patterns in software development” (PPSD).

As a freelance software developer, I’ve met literally hundreds of people over the years. People are individuals, of course, and no two people are the same, but I have observed that certain personalities traits — personality patterns — appear over and over again. What an amazing zoo we live in!

The goal of PPSD is to collect and classify these personalities, to provide a taxonomy in an exaggerated, tongue-in-cheek way.

If you, dear reader, have also come across “outstanding” personalities and want to contribute to this compilation, don’t hesitate and drop me a line! Without further ado, let’s get started with our first personality pattern, the Programming Hipster.


If I had to pick one characterizing adjective that describes a Programming Hipster best it would be “different”. Programming Hipsters have one distinct goal: to be different from the pack and they demonstrate this not only by behavior but also by appearance. A Programming Hipster is the opposite of the average, boring mainstream developer, aka. John C. Coder.

A Programming Hipster is male and usually only found in small, software-centric companies, mostly startups where the average age is below 30. You rarely find him in medium-to-large environments, because his style is way out of line with what typical corporate identity standards demand.

Classical examples of Programming Hipsters are the founding fathers of Unix, like Dennis Ritchie and Ken Thompson. Here is an illuminating quote from “The Art of Unix Programming” by Eric Steven Raymond:

“The pioneering Unix programmers were shaggy hippies and hippie-wannabes. They delighted in playing with an operating system that not only offered them fascinating challenges at the leading edge of computer science, but also subverted all the technical assumptions and business practices that went with Big Computing. Card punches, COBOL, business suits, and batch IBM mainframes were the despised old wave; Unix hackers reveled in the sense that they were simultaneously building the future and flipping a finger at the system.”


What does a programmer look like that wants to be different? Usually, programmers already look different, at least compared to average business people: instead of suit and tie they prefer casual clothing like t-shirts, jeans, and sneakers; by and large they don’t care much about looks. The Programming Hipster, however, wants to be clearly discernible from his peer programmers and appearance matters a lot him. The clearest signs of a Programming Hipster are:

1. Either long hair, especially pony-tailed long hair or shaved head.
2. A monumental full beard.
3. Shorts worn in wintertime.
4. Woolen hats worn in summertime.
5. A big headphone, worn all day, even when visiting the bathroom.

Even a single match from this list is a strong indication that a person is a Programming Hipster; more than one is 100% proof.


Programming Hipsters care a lot about their craft and their technical and programming skills are clearly above average. The same can be said about their intelligence. They are characterized by high-self esteem and usually hold strong opinions. They are not the easiest people to get along with. Most of them can be considered lone wolves that shouldn’t be mixed with the herd. Some of them are team-players, but most of them are not. Thus, Programming Hipsters mostly work on projects where all members have the exact same values and opinions; that is, single-person projects. The biggest shortcoming of a programming hipster is — you guessed it — his ego.


In almost all cases, Programming Hipsters are keyboard virtuosi and disgusted by mice.

To them, only Vi and Emacs deserve to be called “editor”, provided that the color scheme is set to dark. Every other so-called “editor” is just “Notepad” or a derivative of “Notepad”, which, like any other product originating from Redmond, is miles beneath them.

Consequently, they prefer CLIs (Command-Line Interfaces) and use GUIs (Graphical User Interfaces) only when forced to. Since Bash is so prevalent (“mainstream”), they favor a highly-customized version of zsh.

Programming Hipsters pick programming languages from the lower end of the Tiobe index (e. g. Rust) but their ideal programming language doesn’t even appear on the index (e. g. Haskell). Mainstream languages like Java, C, C++, even Python are generally frowned-upon, even though I remember that one Hipster Programmer lowered himself to participate in a C++11 project (subject to the condition that he may use some advanced features from boost and the not-yet-released C++20 standard).


A Hipster Programmer is a colorful addition to every software company, they are the parrots among the sparrows. It would be a mistake to assign such extravagant persons to mundane product development projects; they will, however, excel if they work on prototypes or bleeding-edge research projects.

Code Kata 5: Reversing The Bits

“Boredom is just the reverse side of fascination: both depend on being outside rather than inside a situation, and one leads to the other.”
— Arthur Schopenhauer

Winter is definitely approaching. The days are getting shorter and temperatures are dropping. Isn’t this a wonderful time for doing code katas? Sitting in your easy chair, in front of a fireplace, serenely coding away in your favorite editor.

Today, we dip once more into the realm of low-level embedded programming. Your primary job is to write code that reverses the bits of an integer. For instance, reversing the 8-bit integer value 139 (10001011) yields a new value of 209 (11010001).

Sounds simple, doesn’t it? But it’s not just about coding a bit-reversing routine, that wouldn’t teach you enough lessons. You’ll also practice unit testing, code tuning and — if you like — assembly language programming, cross-compilation, and remote debugging along the way.

The goal is not to find the best/fastest algorithm possible. Instead, the emphasis is on exercising your programming muscle and learning new things. Don’t rush this kata, rather consider it a mini project. Do the research, be persistent. Try and fail and become better. Take your time, I did it over a period of three weeks. Now, without further ado, let’s get (gently) started.

1. Implement a bit reversing function in a dynamic programming language (eg. Perl, Ruby, Python).

a) Decide on a suitable interface, eg. in Python, it could look like this:

b) Implement a dummy version of ‘reversebits’ that simply returns 0.

c) Implement a couple of test cases, run them against the dummy version and watch them fail, eg.

d) Implement a straightforward solution (‘reversebits1’) that passes the unit tests.

e) Add more unit tests to gain better confidence in your solution.

f) Measure the execution time of ‘reversebits1’.

g) Be creative, find other solutions. Optimize for speed, optimize for shortest code (in terms of characters typed). Measure and compare the execution times.

h) What if ‘max_bits’ is smaller than the total number of bits already taken-up by ‘value’? For instance

In this case, only the first ‘max_bits’ of ‘value’ shall be reversed and the remaining upper bits shall be discarded:

Adapt your code accordingly. Probably, some of your solutions already behave correctly and need no modifications.

2. Port your code and unit tests to C/C++

a) Decide on a suitable interface. It’s OK if you use a fixed-bit unsigned integer data type for the value to be reversed, as long as it supports at least 32 bits, eg.

b) Measure execution times and compare them against the execution times from 1.

c) Play with various compiler optimization settings. How do they impact the timings?

d) Bonus: Implement a bit reversal function in x86 assembly language.

3. Port your code and tests from 1. and 2. to a Raspberry Pi

a) Don’t have a Pi? Find out how to emulate one on your PC.

b) Measure and compare execution times using various optimization settings.

c) Bonus: Implement a bit reversal function in ARM assembly language.

d) Bonus: Want to learn even more? Build your own cross toolchain (hint: ‘crosstool-ng’) and build the Pi code on a regular PC. Debug the code remotely over a TCP connection (hint: ‘gdbserver’, ‘gdb-multiarch’).

I certainly learned a lot by doing this kata. Far more, than I can possible tell here without risking to bore you and/or spoil all the fun. Nevertheless, I uploaded my work to GitHub. Have a peek in case you get stuck, need some inspiration or are just curious.

‘static’ With Array Parameters? Oh My!

There’s a rather obscure feature in C99 which allows you to put the ‘static’ keyword between the brackets when declaring array-like parameters to functions, as in

What this means, in a nutshell, is that the caller of this function is expected to pass an array of at least 42 uint8_t’s. Calling ‘transform’ like this would be perfectly OK:

whereas this would constitute a breach of contract:

Likewise, passing a NULL pointer is not allowed, as it — by definition — doesn’t point to anything, not even a single element:


While the semantics of this feature are pretty clear, the purpose isn’t. The C99 language standard doesn’t give a hint, either.

Even when ‘static’ is used, the called function ‘transform’ doesn’t know the exact size of the array. It only knows that it comprises at least 42 elements, so it can only reliably utilize 42 elements. There’s nothing ‘transform’ can do with any (potential) extra elements, because there might be none. So what’s different to this?

This question haunted me for days (if not weeks) and I just couldn’t find a satisfying answer. But let’s put it aside for a moment, as I still have a lot to critisize regarding the technicalities.


First off, why on earth ‘static’? In C, the keyword ‘static’ has already overloaded meanings: a) module scope (an object or function declared ‘static’ is private to a translation unit) and b) lifetime (a static object defined within a function retains its value across invocations). Thanks to C99, ‘static’ now can also mean “at least”. Yuck!

Had I been forced to specify this feature, I would have used the ‘>=’ operator instead of ‘static’:


One of the biggest and most infamous blunders in engineering is when you don’t have a single point of truth; that is, the same information is stored in more than one place. Over time, inconsistencies arise in the copies which can lead to all kinds of havoc. All software engineers are reminded again and again to honor the DRY principle.

According to the grammar, ‘static’ can appear in function declarations as well as function definitions. Nobody prevents you from declaring ‘transform’ like this in your header file:

and like so in a C file:

The C99 standard says nothing about such inconsistencies, whether it constitutes an error, which one takes precedence, whether the compiler has to emit a warning message.

Another problem is that C99 also introduced variable-length arrays (VLAs) and hence an array’s size is not required to be a compile-time constant, like it used to be in C89 and like it still is in C++. Therefore, the C99 grammar blesses such abominations:

What’s the contract now? At least 42 elements (the value of ‘my_global’ at program start-up) or the value of ‘my_global’ when ‘transform’ is actually called:

Again, if you’d forced me to specify this feature, I’d required the size specifier to be a compile-time constant:


While ranting about this feature, I suddenly had an epiphany. Let’s revisit the question I asked above: What’s really the difference between


since my doubts regarding the usefulness of this feature are 100% founded in this question. Previously, I believed that in the second case, there are at least 42 elements, while in the first case there are exactly 42 elements. Not a big difference, because what benefit would a compiler be able to derive from this subtle difference?

But I obviously fell into a trap that I warned my readers a long time ago: believing that array parameters are really arrays, which is mistaken, of course, because arrays cannot be passed directly to functions. From the C language’s point of view, the former interface of ‘transform’ is equivalent to

which means that ‘buffer’ is a pointer to a single ‘uint8_t’, nothing more, nothing less. The compiler can’t make any assumptions beyond that, it’s obliged to ignore the fact that you indicated that there are 42 elements. Specifically, all these declarations are equivalent and effectively declare a function taking a pointer to a ‘uint8_t’:

By contrast, the version of ‘transform’ that uses ‘static’ tells the compiler that a pointer to the first of at least 42 elements is passed. Armed with this knowledge, the compiler can now perform certain optimizations, the most likely one being accessing memory in units much larger than a ‘uint8_t’, to save memory access times. Ah!


Even though we now understand the motivation behind this feature, I still wouldn’t recommend using it. Just like it’s the case with many other so-called “optimization” features (e. g. ‘inline‘ and ‘restrict‘) you, as a developer, have to keep a promise but get nothing dependable back from the compiler. As usual, my advice is this: if you think something needs to be optimized, prove it first; if evidence shows that optimization is necessary, optimize in a dependable way — don’t rely on something that might change from one compiler version to another, especially if it comes with an hideous interface that invites inconsistencies.


Thinking about this odd feature once again, what it all boils down to is that ‘static’ with function parameters actually tries to deliver what regular array-like parameters can’t, namely inform the compiler that the pointer that is passed is really an array, not just a pointer to a single element. But there’s already a feature in the C language (available since C89) that achieves that, namely pointers to arrays:

Contrary to ‘static’ with array parameters, pointers to arrays is a clean, proven, and type-safe concept. Since the compiler knows how many elements the array comprises, it can apply the same optimizations that the ‘static’ with array parameters feature promises, that is, accessing multiple elements at once when traversing the array. There’s really no reason to put ‘static’ between your array brackets, trust me.