Category Archives: People

How To Attract Great Software Developers, Part II: The Natural Habitat


“We have nothing that is really our own;
we hold everything as a loan.”
― Nicolas Poussin

In the previous installment of this series, I explained why many software companies attract charlatans instead of great developers. I summarized the problem by postulating the first rule of hiring great software developers:

To be able to attract truly great developers, a company has to be truly great itself

Thus, if companies can’t attract (or retain) great software developers they are most likely not great themselves. Great, from a great developer’s point of view, mind you. There are many companies out there who are probably considered “great” by ordinary people (and even investors), but this doesn’t mean they are a great place to be for great software developers.

Today, I want to explain what great developers look for when selecting a company. However, keep in mind that no two great software developers are the same. Still, in my experience, most of them share a common set of expectations.

1. Challenging projects that matter

The main goal of great software developers is working on challenging projects where they can demonstrate and hone their skills. Implementing a mission critical embedded system from scratch (like the mars rover) most likely is. Adapting an accounting system such that it’s in line with the latest tax regulations most likely isn’t. It’s the hallmark of great software developers that they always look for new ways of doing things and learning new techniques and technologies — that’s why they’ve become great, after all. When you look at a great developer, you see a snapshot of a life-long journey towards excellence.

The most attractive projects are projects that have top management or even better media attention. Don’t be fooled by the fact that most great software developers are introverts — as every human being, they still want to feel needed and also like to show off every now and then. This is a manifestation of positive pride: pride in workmanship.

On the perfect project, they would work together with other like-minded great developers, ideally recognized experts in the field from which they can learn and to whom they can look up to.

2. Freedom and the absence of friction

Great software developers are individuals who turned their hobby into profession. They want to be ever productive and spend as much time as possible doing what they love most: writing awesome code. Anything that distracts them from coding is thus abhorred. To them, having to fill in time sheets, write meeting minutes, apply for admin rights, attend regular status meetings is creativity-killing utter waste of time.

Great developers love to freely choose their development tools and when and from where they work. Forcing them to use a particular IDE or to commute daily in order to work on-site in a noisy open-plan office is diametrically opposed to what they look for.

3. Decent pay

Money does matter, even to introverts. But it matters less to great software developers than to average people. More important are challenging projects and a frictionless environment. By paying way-above-average salaries, even mediocre companies may be able to lure in great software developers every now and then. They will, however, always lose them, regardless of whether they stay or leave.

So there you have it: feed them great projects, give them freedom and keep bureaucracy out. Pay them enough that they feel comfortable. The latter is the easiest to achieve. Offering a steady stream of challenging projects that matter and providing a hassle-free environment is hard in the long run, especially for a successful company that grows due to its success. The bigger companies get the more they become driven by fear — fear to lose what they have accumulated in terms of wealth and reputation. They fight this fear by adding more and more creativity-stifling policies to maintain the status quo.

Thus, it’s the sad fate of every successful company to become bureaucratic and boring in the long run. Regardless of whether great software developers stay just for the money (at the expense of losing their greatness), or leave — the second law of hiring great software developers can’t be escaped:

In the long run, great software developers cannot be retained

People Patterns In Software Development: The Major Tom

“Perfection is achieved not when there is nothing more to add, but when there is nothing left to take away.”
– Antoine de Saint-Exupery

In this day and age, especially in large corporations, you can find a special breed of software developers who just can’t KISS. For every problem, even the simplest, they dream up a solution that is so complex, so over-engineered that when you look at it, it’s next to impossible to tell what problem it’s trying to solve. When you delve down the layers of abstractions and technologies you soon get lost and forget where you started from.

In 2001, Joel Spolsky coined the term “Architecture Astronaut” to describe folks that love to complexify. However, according to his definition, “It’s very hard to get them to write code or design programs, because they won’t stop thinking about architecture”. To me, however, his definition of an Architecture Astronaut sounds more like a particular variant of a Non-Painter.

The individual I want to talk about today bears a strong resemblance to an Architecture Astronaut, at least on the surface. Contrary to the Architecture Astronaut, he does design programs and does write code — actually, he’s a quite prolific coder. However, what such a developer really does is building overly complex, not-from-this world systems and hence I call him “Major Tom”, in reference to the astronaut character “Major Tom” in David Bowie’s song “Space Oddity“. This song, “depicts an astronaut who casually slips the bonds of the world to journey beyond the stars”. Later in the song, it’s revealed that Major Tom is forever stuck in space and will never return back to earth.

Here’s an example that gives you insight into the thought process of a Major Tom, which can be helpful for diagnosing one.

Let’s assume you have two processes running. One of them (process A) depends on the other (process B). For reliability, process A wants to regularly check whether B is still alive. The initial and obvious choice would be to have process B emit a “live tick” message at regular intervals, potentially including a running counter. A Major Tom’s journey to the stars (and beyond) could look like this:

1. Let’s use a Unix pipe between the processes to exchange the live tick message.

2. But what if the processes are distributed across different machines? Pipes don’t work across machines, so let’s use UDP (datagram) sockets.

3. But with UDP, datagram delivery is not guaranteed, so let’s better use a TCP (stream) socket instead.

4. But what if the machines are based on different architectures that use a different byte order (i. g. big-endian vs. little-endian)? Wouldn’t the counter value be interpreted wrongly? Let’s better use a platform-independent data exchange technology like Protocol Buffers on top of it. This has the additional benefit of supporting backwards compatibility should the message format change and one never knows what additional messages need to be exchanged between process A and process B in the future.

This reasoning goes on and on, let me spare us the rest. In this hypothetical example, a possible final design could look like this:

N. All involved processes register the services that they offer (a “live tick” service, for instance) with a central service registry. Service consumers discover available services offered by service providers. A dedicated, load-balanced broker connects service providers and service consumers which exchange JSON objects via rest API calls over a triply redundant TLS connection.

Now, every software developer is — to some extend — familiar with such lines of thinking and sometimes also leaves solid ground. But while healthy developers stop early and descend back due to the pull exerted by the YAGNI principle as well as time and budget considerations, Major Toms only know one direction: up, up, up in the sky, which translates to more, more, more complexity.

APPEARANCE

Major Toms don’t have any special appearance. They come in all shapes and sizes.

PERSONALITY

Why do Major Toms have such a strong desire to inflate everything? Let’s explore the main drivers, which depend on the particular personality of the Major Tom.

One huge source for not-of-this-earth complexity is the boredom felt by a super-smart developer. I’ve observed many times that developers with a very high IQ have a hard time doing menial work, and sooner or later every task becomes menial to them. The only way to calm down their insatiable mind is to constantly feed it with complexity.

Another cause for cosmic designs can be software engineers with a strong scientific background, especially computer scientists holding PhDs. Some of these individuals are all about research and insist on always creating something novel. Keeping things simple, going for the absolute necessary, and using “mundane” technology is often beneath them.

Last, but not least, there’s a possibility that people create uber-complex designs for job security reasons. Especially Fake Surgeons are known for using strategies like this in order to maintain a massive head start over the rest of the team, thinking “if you can’t comprehend my complex code, you’re not going to replace me.”

RATING

According to the Q²S² framework, a Major Tom’s rating is 4/1/3/3.

(The second Q-rating is so low because of the incidental, unnecessary complexity that causes poor maintainability and poor performance. Hence, the value of what a Major Tom creates is of low, sometimes even negative value to the company.)

POLAR OPPOSITE

The Wolf

CONCLUSION

Major Toms have a passion for making mountains out of molehills but not for shipping production-grade software within budget, in time. Instead of adhering to the trusted XP principle of “doing the simplest thing that could possibly work”, they program in the future tense and constantly ask “but what if?”. The result is often something that resembles a Rube Goldberg machine that nobody (apart from the Major Tom who created it) is able to maintain.

Sometimes it’s possible to cure a Major Tom, and since they are smart and prolific, it’s always worthwhile trying to redirect their energy into more valuable channels. Here are some tactics that might work:

1. Explain that software development is a learning process, that great systems must evolve from simple to complex, just like an oyster grows a pearl from grain of sand, like a vase is made in traditional pottery.
2. Explain that a simple first implementation doesn’t preclude a more elaborate implementation later, once the need for additional complexity has been proven.
3. Explain that a simple design is not a sign of weakness but a sign of strength, that simple design is often the result of hard thinking and discarding of non-essential parts.
4. Explain that doing simple things extremely well can be as satisfying as working with hip technologies.
5. Explain that a company’s main job is to generate money to feed the hungry mouths of its owners and employees, so all successful commercial software development must be done within time and financial constraints.

If your attempts to ground a Major Tom are fruitless, it’s time to go separate ways. Fortunately, when confronted with your down-to-earth ideas, pathological Major Toms usually launch their jet packs and head off for another planet.

How To Attract Great Software Developers, Part I: The Man In The Mirror

“Everything is energy and that’s all there is to it. Match the frequency of the energy you want and you cannot help but get that reality. It can be no other way”
— Albert Einstein

These days, almost every software company is looking for software developers. Not just any software developers, mind you, it’s great software developers that everybody’s craving.

Such companies know that — as has been confirmed again and again in many studies over the last decades — great software developers are easily 10 times as productive as average software developers. Productive as in “able to craft quality products”. It’s not about intelligence, nor the talent to give great talks, write awesome research papers, file patents, implement one prototype after another. It’s not about ranks, titles, grades, number of diplomas or PhDs. It’s all about the great developer’s ability to ship money-generating products on time. Those people are few and far between.

The sad truth is that the main problem of such companies is often not that they have a shortage of great developers — they suffer from far too many below average developers (again, in terms of money-generating productivity). These companies don’t ship awesome products, not to mention on time.

As a countermeasure, they recruit for great developers. What they often forget to do is take a critical look in the mirror. If they did, they would understand that what they try to do is akin to a hobo courting a beautiful princess. It’s nothing more than an exercise in futility! To attract someone attractive, you have to be attractive yourself. It’s that easy!

Realistically, the great developers that such companies are after are already with a highly attractive employer. Why should they change down?

Desperate as these companies are, they employ tricks that are as old as mankind: making themselves appear more beautiful than they really are. They dye their hair, they apply tons of makeup, but it’s just a cover up for something that’s ugly or not there at all.

They try to lure great developers in by telling them that they will be working in a modern workspace, be part of a global, agile team of the brightest minds, that they will shape the future of a whole industry, and so on.

Obviously, everybody, not just great developers, knows that this is pure BS and that a company which resorts to such measures must be a) far from great and b) really desperate.

The latter naturally attracts a special breed of developers. Con artists, who also apply tons of makeup to hide their shortcomings, which I usually refer to as Non-Painters; and so the vicious circle continues for the poor company. Birds of a feather flock together. Pretenders attract pretenders. But the converse is equally true.

Let’s conclude this installment by postulating the first rule of hiring great developers:

To be able to attract truly great developers, a company has to be truly great itself.

In the next installment, we’ll take a look at the hallmarks of great software companies and what great developers are attracted to.

Do They Treat You Like A Superuser?

“A good workman is known by his tools”
— proverb

The process of getting admin rights as a corporate software developer is definitely on a spectrum. Over the last 20+ years, I’ve written code for more than ten companies and boy, do their policies differ!

In one case, I had full admin rights from day one. In more typical cases, I had to start a workflow to request admin rights which would arrive within hours to days. In one extreme case, I had to do an online training about the dangers of working with admin rights before I could start the workflow. After I passed the exam and once my request was approved (7 days later), I would be granted admin rights only for a limited number of time (180 days at most). Even worse — the online training course would need to be taken again as well!

Let’s meditate a little bit on this latter case. Too me, it’s an utter catastrophe. As software developers, we constantly need to maintain and tweak our PC, our beloved toolbox. We need to install or upgrade development tools, device drivers and the like, sometimes just for the purpose of experimentation and learning. What if I wanted to switch to a newer version of g++ one day only to find out that my ‘sudo’ rights had expired? Sure, I could start the workflow again, wait a couple of days for approval, but why? Such processes are nothing but a nuisance that break developers’ flow and inspiration while not adding any real security.

A software developer is not a regular user — a software developer is a superuser, literally. If a company has to have their software developers take training courses to ensure that they don’t work in a root shell all day they should not have been hired in the first place. Doesn’t it border on insulting if you learn in such a training that you should not open email attachments from unknown senders, especially while being logged-in as root? You don’t say!

If a company doesn’t give you unlimited superuser rights within a couple of hours, you’re definitely not treated like a superuser. You’re rather treated like a regular office worker who has no clue about how computers work, let alone computer security.

It’s not just about wasted time. It’s about lack of empowerment and trust. But it’s mainly about a missing software culture: are you viewed as precious human capital that develops top-notch software products which will make the company thrive, or are you rather viewed as a schmuck that poses an severe risk to the company?

A company with good software culture understands the chief need of creative makers, which is: working on interesting projects in a frictionless, libertarian environment where they can spend most of their time doing what they love most: craft exciting software.

Restricting software developers in terms of admin rights is just one problem of companies lacking good software culture, but it’s symptomatic. While such shops might manage to lure in great creators, they will certainly not be able to retain them in the long run.

People Patterns In Software Development: The Non-Painting Painter And The Non-Painter

“If you put off everything till you’re sure of it, you’ll never get anything done.”
— Norman Vincent Peale

I once read about an individual who wanted to become a painter. But instead of painting, he spend a lot of time and money on finding the right canvases, brushes, and paints. He read dozens of books on painting, went to museums, studied the great masters but never got around to paint a picture.

Inspired by this story I coined the phrase “Non-Painting Painter” to label individuals who behave in such manner.

It’s highly likely that you will encounter non-painting painters in your career, so it’s worthwhile to shed more light on their attributes and behaviors, because it’s easy to misdiagnose them. It’s especially common to confuse them with a more extreme form, which I call the “Non-Painter”. Non-painting painters and non-painters have a lot in common (after all, they don’t paint), but while there is hope for cure for the former, all is lost for the latter.

APPEARANCE

Both, non-painting painters and non-painters are indistinguishable by looks, sight, or sound. You recognize them by their personality traits.

PERSONALITY TRAITS

Both, non-painting painters and non-painters procrastinate, they are on the constant lookout for reasons to evade their primary task. This doesn’t imply that they are lazy — far from it! They spend a lot of effort on side issues. What they don’t do is get the task done that they are supposed to do.

To them, there is always more research to be done, more code samples to study, more design documents to write, more meetings to call for. They cannot start to code unless the coding standards have been approved by QA and to avoid this from ever happening, they permanently submit change requests. Then, some day, they hear about a new build system, programming language, software tool that need to be evaluated because this would “save us from so many problems in the future”.

Other characterizing attributes of both, the non-painting painter and the non-painter are that they are usually smart people with above-average social skills. They have a lot to say, seem to be well-versed with many contemporary technologies (at least superficially) as well as everyday topics. They are a naive hiring manager’s dream come true.

To qualify as a non-painting painter, it’s imperative that such an individual still possess a willingness and ability to actually perform the task they so eagerly avoid to do. The chief reason why they don’t perform is rooted in fear. Fear to make mistakes, fear to look stupid in front of coworkers. But contrary to the non-painting painter’s believe, it’s no shame to have little experience, as long as there’s a strong desire to learn and improve. In his book “The Passionate Programmer”, Chad Fowler goes as far as giving this advice: “Always be the worst guy in every band you’re in. – so you can learn. The people around you affect your performance. Choose your crowd wisely.”

But let’s now turn to the pathological, incurable sibling of the non-painting painter — the non-painter. Non-painters also don’t produce what they’re supposed to, they also waste time on unimportant, minute details and side issues. But contrary to the non-painting painter, they have neither the intention, nor the ability to get the job done. If that wasn’t bad enough, in almost all cases they go to great length to prevent also teammates from getting their jobs done, thus multiplying their own unproductivity. Why? Non-painters are in constant fear that well-performing teammates steal the limelight from them and expose them for what they are: freeloading charlatans.

RATING

According to the Q²S² framework, the rating of a non-painting painter and a non-painter is the same: 2/1/4/2; the Q²S² framework is unfortunately not able to discern them.

POLAR OPPOSITE

The Codenator

CONCLUSION

A non-painting painter is still a painter, alas an inhibited one. My recommendation is to give non-painting people the benefit of the doubt and not by default label them as non-painters. If they don’t have the courage to speak about their fears, a senior developer should approach them and provide support and guidance. Just like Attaboys, non-painting painters often are diamonds in the rough. If they are open about their inexperience and strive hard to improve, they can turn into a valuable asset. However, if their productivity doesn’t improve, relabeling them as non-painters is more than deserved and non-painters have no place in the team.

People Patterns In Software Development: 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.

POLAR OPPOSITE

The Non-Painting Painter/Non-Painter

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.