Shlemiel The Painter

Shlemiel gets a job as a street painter, painting the dotted lines down the middle of the road. On the first day he takes a can of paint out to the road and finishes 300 yards of the road. "That's pretty good!" says his boss, "you're a fast worker!" and pays him a kopeck.

The next day Shlemiel only gets 150 yards done. "Well, that's not nearly as good as yesterday, but you're still a fast worker. 150 yards is respectable," and pays him a kopeck.

The next day Shlemiel paints 30 yards of the road. "Only 30!" shouts his boss. "That's unacceptable! On the first day you did ten times that much work! What's going on?" "I can't help it," says Shlemiel. "Every day I get farther and farther away from the paint can!"

see http://www.joelonsoftware.com/articles/fog0000000319.html

 char bigString[1000];/* I never know how much to allocate... */
 bigString[0] = '\0';
 strcat(bigString,"John, ");
 strcat(bigString,"Paul, ");
 strcat(bigString,"George, ");
 strcat(bigString,"Joel ");

This works, right? Yes. And it looks nice and clean.

What is its performance characteristic?
Is it as fast as it could be?
Does it scale well?
If we had a million strings to append, would this be a good way to do it?

Every time I read Joel, I question whether he should be thrown into solitary confinement before he writes yet another article. For instance, he writes regarding building Pascal strings in C

Lazy programmers would do this, and have slow programs:

char* str = "*Hello!";
str[0] = strlen(str) - 1;

No, Joel does that. Good coders would a) know why it's immoral to not write char const *, and b) do this

char str[] = "*Hello!";
str[0] = sizeof(str)/sizeof(*str) - 2;

and smarter programmers might make that a macro as

/* Joel calls them fucked strings, so we shall "fuck" them. */
#define FUCK_STRING(s) s[0] = sizeof(s) / sizeof(*(s)) - 2
char str[] = "*Hello!"; 
FUCK_STRING(str);

There's also that completely babblicious section about buffer overflows and malloc that falls flat on its face.

I guess have to agree with him that "some of the biggest mistakes people [like Joel] make even at the highest architectural levels come from having a weak or broken understanding of a few simple things at the very lowest levels." -- SunirShah

Um... what if I want a string longer than 127 characters? And moving to a potential size of 256 doesn't ring my bell either. --BruceIde

Every time I read Joel, I question whether he should be thrown into solitary confinement

I got a good laugh out of that, as I usually think the same thing. As he states, these are "highly questionable rants" on software. All-in-all, though, I think Joel does a good service. I disagree with a lot of what he has to say, but he does write good software and he's clearly better than the average monkey. I think a lot of coders who would never venture into the wiki read his stuff and learn a little something about how to do their jobs better. For the moment, at least, I vote we don't lock him up.

For reference, a shlemiel drops a bucket of paint, a shlemozzel is the guy it falls on.

It is NOT off by one.

: True, I made the mistake of assuming he wanted to include the NUL byte in the length. (No UnitTests, eh.) I fixed my rant. Fortunately, the letter-points were off-by-one as well. ;) --ss

The illustration given by the story introduces two aspects of working with purpose. The Painters view of things, and the Boss's view of things. The painter was concentrating on the work to be done, and ignoring the way the work was done. The Boss was concerned with the quantity of work and the cost of the work. The final product, the lines down the middle of the road, was the work. The question he asked was not "WhatAreYouWorkingOn?", or "HowAreYouDoingYourJob?", but "HowMuchDidYouGetDoneToday?" The boss was viewing the WorkInProcess? with one eye shut. Managers can learn from this simple story that ManagingIsNotaMatterOfMetrics? and that if one is to achieve, it is well to consider ProcessImprovementTools as well as ProcessImprovementSkills. The way a painter does his work, whether painting wall from a bucket in place, or painting lines down the middle of a road, when the bucket must be carried along, should be realized by observation, and not just via "ReportsOfAccomplishment".

A good C coder would know that modifying the backing store for a string literal has undefined behaviour, and would avoid doing so. Poking the length into a string literal can result in compiler warnings or errors, or may result in unexpected runtime behaviour - such as your computer exploding.