« Posts under Hiring Developers

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

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

CONCLUSION

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.

How To Hire Great Developers, Part I

“When there is a will, there is a way.”
— Unknown

Hiring great software developers is certainly not an easy task. To find out if a candidate is a good fit, companies usually focus on assessing an applicant’s knowledge, social skills, and intelligence.

THE STATE OF THE ART

Knowledge means that a person has a profound command of the domain, technology, and tools required for his/her job. If, for instance, you need a C++ developer for the development of an ECU (electronic control unit) for a car, you probably want somebody who is not only proficient in C++, but also has expert knowledge of embedded systems development, Autosar (an automotive middleware), CAN/FlexRay/MOST (some automotive communication buses), and probably a lot more technologies and tools. Determining a candidate’s level of knowledge is straightforward: you just need to ask enough technical questions.

Since today’s projects are usually done by teams, not individuals, social skills are very much sought after by every company. In general — and contrary to what is portrayed in Hollywood movies — software developers aren’t those pizza-eating and Red-Bull-drinking loners that reverently stare at their screens all day (and night). While such stereotypical coders do exist, they are the rare exception. These days, most professional software developers spend a significant share of their time communicating with peers, managers, and sometimes even customers. Developers need to successfully explain, present, and negotiate. Being able to do this in an open and respectful manner is not just highly desirable — it’s an essential survival skill. How to find out if a person has social skills? You ask questions and pay attention to how things are said and presented. Have candidates talk a little bit about themselves, their past projects, let them explain a difficult topic.

Many traditional companies would stop here. However, most successful, especially software-centric companies have recognized that while knowledge is important, it’s not sufficient. They want smart developers; that is, developers that come up with creative, efficient solutions and require little time to implement them. Thus, they also check a candidate’s intelligence by torturing them with riddles and logic puzzles, including those who look like they’re impossible to solve (“How Would You Move Mount Fuji?“). Others ask candidates to do online programming tests that challenge the candidate to find clever solutions to tough programming problems. The reasoning is this: intelligence ensures that knowledge is put to good use.

By now you know whether your candidate is a great developer, don’t you? If a candidate passes all the aforementioned tests, (s)he certainly has a lot of ability. But does this also imply that such a person will get the job done? Sadly, it’s a common fallacy to confuse ability with willingness.

MY HERO

More than fifteen years ago, I worked on project where the development team received insanely formatted error log files from the testing department. Information that would have helped us debug the problem was buried deeply in ASCII noise. Every time we received a bug ticket, we had to spend quite some time on figuring out what exactly went wrong. One day, a coworker gleefully came into my office and told me that he’d written a filter program that extracted and reformatted all the relevant data from the error log files. What a neat idea and what a time-saver! Full of pride, he showed me his code. What I was faced with was many pages of C code, written over the course of three days, full of low-level ‘getc’-based text parsing — definitely not easy on the eyes! Finally, I gave him a smile and thanked him for this great little tool. Half an hour later I went to his office and showed him a 30-line Perl listing that was functionally equivalent to his C code.

He didn’t know about regular expressions and neither Perl nor any other scripting language. All he knew was C. He clearly lacked knowledge. He was a lousy software developer, right?

As a matter of fact, I think he was a very fine developer. None of the other team members (including myself) — despite knowing about regular expressions and Perl — could be bothered implementing such a productivity boosting tool. Instead of lamenting, he just did it, even though it must have been painful for him. He didn’t waste three days because of his incompetence. His persistence saved hundredths of developer-days down the road. He did it because it was the right thing to do.

Of course, he was somewhat embarrassed at first. I told him that I reimplemented his program to demonstrate the power of regular expressions and dynamic languages, not to insult or humiliate him. Guess what? A couple of days later, he told me that he did a Perl tutorial in his spare time, because he was sure it would save him lots of time and effort in the future. He never defended himself and he didn’t make lame excuses — he acted like a pro.

This is a guy you certainly want to hire! He possesses two traits that are much more valuable than knowledge: persistence and professionalism.

PROSPECTING FOR GOLD

To me, persistence and professionalism are not fundamental personality traits; I strongly believe that they’re the by-products of a root trait that I call “professional software passion” (PSP). Developers who possess a high degree of PSP are self-motivated and in general enthusiastic about their craft, they commit to life-long learning, are able to take a lot of hardship and always work towards fulfilling the business goals of their employers and clients — not just the short-term goals — especially the long-term goals.

Unfortunately, typical hiring processes completely ignore this critical trait. A certain level of intelligence and social skills is crucial, no doubt about it. Knowledge, however, can and will be obtained as long as PSP exists in a developer. PSP ensures that the job gets done. I would pick PSP over knowledge any day.

I will explore the topic of “professional software passion” as well as strategies on how to detect it in candidates in future posts. Stay tuned.