« Posts under People Patterns

PPSD: The Attaboy

“The better you feel about yourself, the less you feel the need to show off.”
― Robert Hand

In his famous book, Code Complete, Steve McConnell tells the story of a maintenance programmer who was called out of bed one night to fix a critical bug. The original author had long left the company and the poor maintenance programmer had never worked on the program before. There were no comments in the code, except six letters on a line of assembly code:

After working with the program through the night and puzzling over the comments, the programmer made a successful patch and went home to get some sleep. Months later, he met the program’s original author at a conference. “What does the comment R. I. P. L. V. B. stand for?” he asked, to which the original author replied: “‘Rest in peace, Ludwig van Beethoven.’ Beethoven died in 1827 (decimal), which is 723 (hexadecimal).”

Ladies and Gentlemen, such conduct is the mark of an Attaboy!

An Attaboy is a developer who craves admiration for being smart. To satisfy his needs, he regularly pulls coding stunts that get him the attention of his coworkers. Attaboys usually follow this pattern:

1. Bury an outlandish “nugget” in the code base.
2. Patiently wait until it’s discovered by an unsuspecting victim.
3. When the horrified victim demands answers, smugly explain.
4. Watch the victim’s jaw drop.
5. Savor the attention.

Many years back, I was a victim of an Attaboy myself, even though I hadn’t coined the term yet. I was reviewing a coworker’s code when a gut feeling told me that something wasn’t quite right. At first, I couldn’t really explain it, but then, all of a sudden, I knew: there was something weird about his zeros: Whenever he needed a decimal 0, he put the letter ‘O’ instead, as in

instead of

Since code like this wouldn’t normally compile, I suspected that he had defined a preprocessor macro somewhere like this:

but a regex grep across the code base didn’t yield any matches.

Finally, it dawned on me: he must have done it in the Makefile and so it was: he predefined O through a command-line argument to the compiler, like the following:

Arrgh! Even though this explains why his code compiled, it didn’t explain why he did something insane like this in the first place. It was time to confront this schmuck! But little did I know that this was all part of a carefully premeditated game.

“Well,” he said, with a smirk on his face, “our coding standard says, we’re not allowed to use octal constants. According to the C programming language, any number starting with a zero is an octal constant, so 0 is by definition also an octal constant, which according to our coding standard we shouldn’t use.”

Touché!

The proper way to handle this, of course, would have been to ask our software architect to make a tiny adjustment to our coding standard. Not so for the Attaboy who saw this as a unique opportunity to show off.

APPEARANCE

Attaboys are usually fresh out of college and lack professional experience. The ones that I’ve met looked like stereotypical nerds, but I don’t think that you can generally discern them by their looks or the way they dress. Attaboys are all about their wits.

PERSONALITY TRAITS

Attaboys are not just ordinary pranksters—they desire praise and validation and pranks are just a means to attain it. However, contrary to pathological cases of attention-seeking personality disorders, their behavior is transitory and not rooted in either getting too much or too little attention from their parents during childhood.

Instead of getting praise from their colleagues for their outstanding “achievements,” Attaboys are often confronted with despise and in rare cases even hostility. While such negative attention is far from ideal for Attaboys, it’s nevertheless proof of their intellectual prowess. And like every aging actress knows: any attention is better than being ignored.

These antics notwithstanding, most of the time, Attaboys are usually productive, write decent code, and get along well with others.

RATING

According to the Q²S² framework, an Attaboy’s rating is 4/4/3/3.

TOOLING

Since tools can also be a means of getting attention, tools play a significant role in Attaboys’ lives. They prefer tools, techniques, and programming languages that are considered unusual by their teammates. This is of course dependent on the context: in an environment, where everyone uses Visual Studio to write their code, an Attaboy might use Vi or Emacs as an editor. In C++ projects, Attaboys make lots of use of C++ template meta-programming, yielding code that is illegible to almost everyone, often including themselves. Or, they use programming languages that are illegible by design, like Brainfuck. Highly readable mainstream languages like Python are only used if absolutely necessary but even then, Attaboys find rarely used or recently added features that baffle peers.

Regarding the selection of tools, an Attaboy is almost indistinguishable from a Programming Hipster. But while a Programming Hipster’s main motivation is being different, an Attaboy’s main motivation is being admired.

CONCLUSION

Attaboys are tech-savvy rookies that are still wet behind the ears. Despite being occasionally a nuisance, Attaboys are not much of a problem. On the contrary, their productivity is above average, and they definitely care about their craft. Sometimes, you can even learn something from an Attaboy’s highbrow pranks—even if it’s just the day of death of a German composer, or that zero is an octal constant. While most would refer to an Attaboy as a smartass, I would like to add that an Attaboy is a benign smartass. Actually, I tend to think of an Attaboy as a diamond in the rough. Over time, the attention-seeking behavior will disappear and what’s left over will be a rock-solid developer.

PPSD: The Fake Surgeon

“I just trust my intuition taking into account the psychology of things. Therefore, I am not persuaded by facts, but by behaviors.”
― Maria Karvouni

In his classic book on software engineering, The Mythical Man-Month, Fred Brooks presents a radically different approach to organizing development teams, which he coined the “Surgical Team.” His idea is based upon three key insights:

1. Great software developers are easily 10 times more productive than average developers.
2. Conceptual integrity is the key to the success of every software product, especially large software products.
3. The bigger the team, the more communication paths are required, which is detrimental to conceptual integrity.

Consequently, according to Brooks, a software team should consist of a single super-programmer (the “surgeon”) accompanied by nine “assistants,” give or take. The surgeon is not only the boss of the team, but he also does the main work; that is, thinking and programming, all for the sake of minimal communication and conceptual integrity. The assistants have clearly defined roles, all aimed at making the surgeon’s life easier and boosting his productivity: for example, they support him as backup programmer, editor, tester, and secretary.

To grade A developers, this approach looks quite appealing, as they finally get the resources, recognition, and status that they crave so much, while at the same time still being allowed to do what they love to do most: programming.

Alas, for various reasons the whole idea was stillborn (boo-hoo!), but that’s not what I want to focus on today. For the rest of our discussion, you just have to bear in mind these facts about Brooks’ analogy:

1. The surgeon is a talented and experienced developer.
2. The surgeon is the boss and has the company’s official mandate.
3. The assistants respect the surgeon and fully accept their roles as subordinates.

A Fake Surgeon, by contrast, is a wannabe surgeon—a surgeon that has no official mandate and his imagined assistants neither accept him nor their ascribed roles.

Early in my career, I was part of a fake surgical team. The Fake Surgeon was very prolific, worked ridiculous hours, and never went for lunch. Why? Because he wanted to make himself indispensable by keeping a massive head start on the rest of the team.

Sometimes, he would leave the office late at night for only a couple of hours, to take a quick nap and a shower. When the other team members arrived in the morning, they couldn’t believe their eyes: so much had changed overnight! They really didn’t know how or where to contribute. Instead of filling them in, the Fake Surgeon’s solution was to assign his “assistants” only non-critical, menial work because, according to him, he was way too busy to explain what he did during last night’s blaze of glory. This tactic ensured that he remained the keeper of the crown jewels. Managers, sales, customers—they only talked to him, because he was the authoritative source of everything, thus isolating the rest of the team even more.

He put up such an act, always looking so busy and stressed, that you didn’t dare disturb him. If you finally got up the courage, he’d only give you short, superficial, sometimes even misleading replies.

Reading his code was far from easy—it left you puzzled and gave rise to many questions; questions, that you were too afraid to ask. Obviously, mysterious, unreadable code was yet another element of his cunning plan: job security by code obscurity.

APPEARANCE

Regarding the choice of clothing, a Fake Surgeon is pretty average, at least clothes do not define him. By and large, he doesn’t spend much time on looks; instead, he invests his time speeding ahead of everyone else. It’s highly likely that he appears rushed, always hustling about the office, never socializing over coffee, just swiftly refilling his mug before running back to his keyboard.

PERSONALITY TRAITS

Most likely, the reasons for a Fake Surgeon’s behavior are deeply rooted in his low self-esteem and fragile ego. Deep down inside, he’s aware of his limited skills and is in constant fear of losing his job. To compensate for his insecurity, he tries to establish a regime of control, keep as much of his knowledge to himself, and make sure that his enigmatic code can only be understood by him and nobody else. A self-confident programmer, by contrast, knows that he’s indispensable because he shares information and writes clean code that can be extended by others.

Of course, such a pathological type of developer can’t thrive all by himself. Every Fake Surgeon forms an unhealthy symbiosis with an extremely weak manager who condones such egoistic behavior. In most instances, the Fake Surgeon’s boss doesn’t see through the Fake Surgeon’s ulterior motives and might even praise the Fake Surgeon for his unusual commitment. After all, the Fake Surgeon takes care of everything and thus gives the boss plenty of time to work on his own career.

What ends up happening, in almost all cases, is that the Fake Surgeon sooner or later takes advantage of his distinguished position and extorts the company by asking for a sizable pay raise. Usually, the company gives in, must give in, because they can’t afford to lose such an important person. What these companies fail to recognize is that they already lost him, anyway. Fake Surgeons are sly and anticipate that once they’ve made such a move, their days might be numbered. Hence, they use this promotion just for negotiation purposes and try to land an even better paid job with a competing company. A company, where the Fake Surgeon can rightly claim, “In my previous job, I did everything by myself” and where nobody knows his selfish, dirty little secret. Depending on whether his need for security and power are ultimately met at the new job, he might settle down and mellow out; if not, he might establish yet another cycle of abuse.

RATING

According to the Q²S² framework, a Fake Surgeon’s rating is 5/2/1/1.

TOOLING

A Fake Surgeon likes tools, especially tools that give him a strategic advantage over others. Most likely, some of the tools that he (or the team) employs were created by himself, such that he’s the only person who can operate and extend them. He also fancies rarely used libraries and programming languages and exerts quite a significant amount of effort in mastering them. To a Fake Surgeon, that’s time wisely invested, as it allows him to race ahead on steroids while the rest of the team is limping along.

CONCLUSION

Information hiding is a sound and proven software design principle but it doesn’t carry over to developers working on a team. A Fake Surgeon is the opposite of a team player—he’s a ball hog. He’s a charlatan that dupes everyone into believing that he’s a real surgeon. All he has in mind, however, is advancing his career at the expense of others, often putting the fate of whole companies at risk. He’s such a nuisance to work with that often valuable team members (who never got a chance to prove themselves) leave the toxic environment he created.

A strong manager is required to prevent a company from being taken hostage by such an individual. A strong manager wouldn’t fall prey to a Fake Surgeon’s ensnarement. Instead, he will make knowledge sharing a priority and ensure that everyone leaves the office on time. Managers, beware red flags: If somebody works excessive overtime, tell this person immediately that they should rather use their time to enable others to contribute. This way, the person’s time will yield a high return on investment and reduce the overall risk for the project. If he doesn’t understand, ask him to seek his luck elsewhere. Don’t shed any tears over this person: the only thing that you lost is a problem.

PPSD: The Q²S² Framework

“Some people come into our life as a blessing, while others come into our life as a lesson, so love them for who they are instead of judging them for who they are not.”
— Yolanda Hadid

As you know, “People-Patterns in Software Development” (PPSD) is a tongue-in-cheek series in which I present personality traits of software developers and arrange them in patterns. In order to make these patterns easier to compare, I came up with an evaluation framework that I’ve dubbed “Q²S² framework.”

Each letter of the Q²S² (or QQSS) acronym represents one of the four dimensions, along which developers are assessed: Quantity, Quality, Social, and Sharing.

QUANTITY

Quantity captures how prolific a person is. Is an individual a doer who creates or rather somebody who consumes things created by others? Low-producing software developers, even highly educated ones, have difficulties writing code. They overthink, get stuck in analysis-paralysis and have a hard time entering insert mode. But even if they do start, they often don’t sustain and end up failing to make it to the finish line. But getting things done is essential: a bridge over a river is worthless if it ends three meters short of the other bank.

High-volume producers, on the other hand, are totally sold on action, they want to get their hands dirty. If they encounter a Gordian knot, they simply cut it. Without knowing the details, they start with a “shitty first draft” and shape it into the final product. To them, software development is like pottery making: they begin with a lump of clay and turn it slowly but steadily into a vase—and then proceed to make another one, and another one. Whether these vases are of decent quality is a completely different story.

QUALITY

According to a popular definition, quality is the degree to which something meets or exceeds the expectations of its customers. While a certain amount of quantity is essential, it’s by no means sufficient. Quality-oriented developers create software that performs well, is easy to use, and has a low defect rate.

There is a type of quality that is not visible to the customer called internal quality. High internal quality means that the software is easy to comprehend and extend by maintenance developers, and thus supports the incorporation of future requirements. Low internal quality means that the code is hard to maintain, that it is full of technical debt. So much technical debt, in fact, that over time—due to compound interest—the maintenance costs becomes so high that a software company is forced to declare bankruptcy, literally, sometimes. High internal quality, by contrast, denotes investment protection and is the foundation of long-term business success.

Since internal quality is so frequently neglected, I stress its importance a lot. Still, for the sake of simplicity, I decided to merge external and internal quality into a single “quality” dimension. Therefore, a developer with a high-quality rating in the Q²S² framework pays utmost attention to both external and internal quality.

SOCIAL

Even a super-productive, high-quality programmer is still only able to achieve so much in a day. The best carpenter in the world may build you the finest log cabin, yet he’s unable to build a skyscraper, let alone a city. By the same token, some of today’s software products are so large and demanding, it’s imperative that their construction is distributed over many shoulders. To achieve great products, people from different disciplines and backgrounds have to work together smoothly.

The biggest challenges a large software project faces these days are sociological in nature, not technological. Hence, the ability to effectively interact with other individuals is a crucial skill for every software developer. This includes being able to communicate clearly, present ideas in a comprehensible way, give and take criticism, and the willingness to compromise.

SHARING

It goes without saying that productive, high-quality developers are a blessing for every company. But developers who are willing and able to share their knowledge with coworkers can lift them to new heights and thus boost the productivity of the whole team. Like Robert Noyce, co-founder of Intel said: “Knowledge is power. Knowledge shared is power multiplied.” Imagine the benefits if all software developers followed the “each one teach one” maxim.

Developers with a great sharing attitude introduce new tools and techniques, host coderetreats, write blogs, and give one-on-one advice. What is important, however, is that this is done on top of their daily work as above-average-quantity, above-average-quality developers. All knowledge sharing must be founded on and validated by practical, real-world experience. Beware wannabe experts who only teach because they can’t do or don’t want to do what they were once hired for.

CONCLUSION

All four dimensions of this framework are all about the product. Quantity and quality are about the individual programmer’s direct influence on the product, while social and sharing are indirect: it’s the individual programmer’s influence on the influence of other programmers on the product.

You may wonder why there are no dimensions for intelligence, experience, and knowledge. Even though most job interviews put a lot of emphasis on these attributes, to me, by themselves, they are pretty meaningless. At best, such attributes can be viewed as necessary but insufficient. All that matters in the end is the product. Or, to put it another way: “It’s the product”, stupid!”

From now on, I will include Q²S² ratings in all people-patterns. Every dimension has a rating, ranging from one to five, just like is the case for most star-based classification systems that are in use today:

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

Thus, a 4/3/5/2 rating describes a developer that produces at an above average rate with average quality, has extremely good social skills but is poor at teaching.

For the sake of completeness, I’ve also added ratings to the patterns presented so far:

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

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.

APPEARANCE

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.

PERSONALITY TRAITS

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.

TOOLING

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.

RATING

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

CONCLUSION

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.

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.

APPEARANCE

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.

PERSONALITY TRAITS

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.

TOOLING

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.

CASE IN POINT

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.

ADVICE

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

RATING

According to the Q²S² framework, a Statler/Waldorf’s rating is 2/2/2/1.

CONCLUSION

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.

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

APPEARANCE

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.

PERSONALITY TRAITS

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.

TOOLING

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

RATING

According to the Q²S² framework, a Programming Hipster’s rating is 4/4/2/2.

CONCLUSION

A Programming Hipster 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.