Bug Hunting Adventures #13: Prime Sums

― Edgar Allan Poe, The Purloined Letter








PPSD: The Q²S² Framework

— Yolanda Hadid




















1: Far below average
2: Below average
3: Average
4: Above average
5: Far above average



Codenator: 5/3/1/1
Statler/Waldorf: 2/2/2/1
Programming Hipster: 4/4/2/2

Simplified: Idiot Tax

— Albert Einstein

The opening quote is attributed to Albert Einstein, even though it’s unlikely that he used these exact words. Nevertheless, the idea behind it has always resonated with me: If you explain something in easy words the person at the receiving end can immediately grasp it and is enlightened forever. But reducing a topic to its essence and explaining it from the vantage point of somebody else is even well worth the time for the one at the giving end: As always, the teacher learns the most.

I recently held an embedded programming workshop for kids and what I took home is this: if you pick the right examples and metaphors, even 12-year-olds can understand topics like pulse-width modulation. With this post, however, I want to address adults; specifically, I want to talk about something that has puzzled me for quite some time: why do people, even highly educated people, take part in lotteries?

A common knee-jerk reply is that everyone wants to get rich quick, without earning it. But that’s not the answer I am looking for. Let me refine my question: why do people play lotteries even though they know that the odds of winning are infinitesimally small?

Let’s take the German lottery system as an example. In order to become a millionaire, you have to get six numbers right, out of a total of 49. According to their official website, the odds to get these six numbers right are 1 to 15.537.573, or roughly 1 to 15 million.

Even though our gut feeling tells us that this is quite unlikely, we completely underestimate how unlikely it really is. Why? My guess is that it’s because we hear about figures that are in the millions every day. This guy is a millionaire, and that one even a billionaire. Government spends millions here and billions there. Still, we are nothing more than remotely acquainted with large numbers; we constantly fail to truly and fully comprehend them.

Let’s use an approach that has helped me quite a lot and treat big numbers like distances. What the human species has done for thousands of years is walk, so we naturally have a good grasp on distances. Let’s pretend we have a distance of 15 million centimeters.

15 million centimeters divided by 100 gives us 150 thousand meters, which equals 150 kilometers. People are especially good at understanding kilometers. 150 kilometers means roughly a two-hour car ride on a regular country road. That’s quite a distance, isn’t it?

Further, imagine a single M&M chocolate piece. It’s diameter is roughly one centimeter, give or take. Put one M&M after another, on a single straight line that is 150 kilometers long and you get what the number 15 million looks like. Somewhere along that line, there is that one special M&M where they printed a “$” sign on the back, instead of the usual “m”. So you drive along this 150 kilometer line with your car, stop at some random point and flip a single M&M of your choice, hoping to see a “$” sign on it’s back.

Now, how much money would you invest in such a bet? I don’t know about you, but I wouldn’t even invest a single cent. While it’s not impossible to win, it’s very, very improbable. Any money would surely be gone.

This is why the enlightened call lotteries “idiot tax”. It’s the tax that people—out of greed and ignorance—pay voluntarily.

PPSD: The Codenator

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


According to the Q²S² framework, a Codenator’s rating is 5/3/1/1.


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?









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


A Statler/Waldorf’s Q²S² rating is 2/2/2/1.


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.