« Posts under People

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.

Why I don’t Use Apple Products

Every now and then, people ask me why I steer clear of iThings. Explaining my view over and over again is tedious, so I’ve decided to present my reasons in writing. When this topic comes up next time I just need to point people to this post, which will save a lot of time on both sides.

Open-source veteran Richard Stallman, founder of GNU and the Free Software Foundation (FSF) has already contributed his share to the topic. I do agree with most of his arguments but I still want to tell the story from my point of view.

First of all, let me emphasize that it has not always been like that. As a matter of fact, I used to be an Apple fan myself, even though this was in the early 1980s. My first home computer was an Apple II clone and I badly wanted to own a real Apple II, I can tell you. Alas, it was too expensive for an eighth grader’s measly monthly allowance.
»Read More

The Need for an Hippocratic Oath for Software Engineers

Two months ago, I wrote about an incident where a fault in an airbag system was responsible for the death of a child. (Actually, as a court ruled later, it was not the airbag system that was responsible, but rather an engineer who kept quiet about a bug that he had discovered earlier.)

Now, it seems like we have another case of a software-based disaster: Volkswagen recently admitted that they used software in their cars that detects official test situations and then reconfigures the engine to reduce pollution — just to get the figures right. When not in this “cheat mode”, that is, under real driving conditions, Volkswagen’s NOx emission rates are up to 40 times higher.

I think this cunning piece of German engineering has the potential to smash Volkswagen. Not extinguish entirely, of course, but Volkswagen’s stock value might decrease so much that it can be taken over easily by the competition. In any case, it will cost this company, whose bosses probably thought it was too big to fail, big: billions of dollars, thousands of jobs, an immeasurable amount of reputation and credibility.

What makes this story so exceptionally shocking is that we are not talking about a bug (like in the failing airbag case) but a feature. This software was put in deliberately, so it is rather a sin of commission than a sin of omission.

While it would be interesting to know what made people act in such a criminal way, what really matters is this: the whole mess could have probably been avoided if someone along the chain of command would have stood up and said “No!”.

I will use this sad story as an opportunity to introduce the “Software Engineering Code of Ethics and Professional Practice” to you, a joint effort by IEEE and ACM. As for the Volkswagen scandal, it looks as if at least the following principles have been grossly violated:

Software Engineers shall:

1.03. Approve software only if they have a well-founded belief that it is safe, meets specifications, passes appropriate tests, and does not diminish quality of life, diminish privacy or harm the environment. The ultimate effect of the work should be to the public good.

1.04. Disclose to appropriate persons or authorities any actual or potential danger to the user, the public, or the environment, that they reasonably believe to be associated with software or related documents.

1.06. Be fair and avoid deception in all statements, particularly public ones, concerning software or related documents, methods and tools.

2.06. Identify, document, collect evidence and report to the client or the employer promptly if, in their opinion, a project is likely to fail, to prove too expensive, to violate intellectual property law, or otherwise to be problematic.

3.03. Identify, define and address ethical, economic, cultural, legal and environmental issues related to work projects.

5.11. Not ask a software engineer to do anything inconsistent with this Code.

6.13. Report significant violations of this Code to appropriate authorities when it is clear that consultation with people involved in these significant violations is impossible, counter-productive or dangerous.

In a world in which an ever-increasing part is driven by software, “The Code” should be considered the “Hippocratic Oath” of software engineers, something we are obliged to swear before we can call ourselves software professionals, before we are unleashed to an unsuspecting world. I wonder how many more software catastrophes it will take until we finally get there.

Two German Maxims That Will Save Your Neck (and Others’ Necks as Well)

I quite remember the uneasy sensation that I had when a former coworker told me a story — a story about a senior engineer who went to jail because of a bug, a fatal one, as it turned out.

The bug lurked in an electronic control unit (ECU) which was, among other things, controlling the manual deactivation of the front passenger seat’s airbag. Under normal circumstances, you wouldn’t want to disable an airbag, a feature that saves lives every day around the world. However, if you intend to put a rearward-facing baby seat in the front, you have to do it, or you risk severe injury of your child in case the airbag deploys during an accident.

Now, this unfortunate engineer discovered that under extremely rare conditions there was a tiny window of opportunity for the airbag deactivation mechanism to fail silently; that is, it would appear to be deactivated when in fact it wasn’t. I don’t remember the necessary prerequisites, but what I do remember is that the combination of inputs and actions sounded so silly, so unusual, so improbable that he — like probably most of us would have — expected that the fault would never ever show up in practice. But what a terrible mistake this was, as this is exactly what happened and a child lost its life.

How unlikely or likely is the higly improbable? The chances of winning a 6-number lottery game are typically 1 against many tens of millions; yet, the likelihood that some player (not a particular player, of course) wins is quite high. Why? Because there are millions of players who take part in such lotteries. The same is true for ECUs which frequently find their way into millions of cars.

The developer was punished not for creating the bug but for not telling his managers about his discovery, for keeping it secret. But why didn’t he report the problem to his superiors? I can only guess. Maybe there was a lot of schedule pressure, perhaps he didn’t want to upset his boss. Or, the product was already released and a recall would have cost a lot of money, let alone reputation. If you ask me, it was a deadly cocktail of fear and pride.

When I did my military training at the German Armed Forces, one of the first rules I learned was “Melden macht frei”, which more or less translates to “reporting is liberating”. It is your duty to report an incident and it has a liberating effect on you, both emotionally and legally. After reporting, it is your superior’s problem. He has to decide what to do next. That’s not dodging responsibility — it’s passing on an issue that is outside your area of responsibility to the right person.

In the same spirit, as professionals we also have to report any issue that is harmful to customers or the company, regardless of how unlikely it appears to us. Even if management makes a (hopefully prudent) decision to ignore the problem (like it was the case in the Space Shuttle Challenger disaster, where engineers clearly raised their concerns that the O-rings on the rocket boosters would not seal at low temperatures), at least you have behaved professionally and are saved from prosecution and guilt feeling.

There is, however, a strange phenomenon: People sometimes forget that you informed them, especially when they have to testify in court. That’s why I want to share another important German wisdom with you: “Wer schreibt, der bleibt”, which can be translated as “you write, you stay”. It means that (only) if you write something down, you will be remembered. In other words: always keep a paper trail; email usually suffices.

The Game of Life

game_of_life

“Imagine there’s no heaven
It’s easy if you try
No hell below us
Above us only sky”

— John Lennon “Imagine”

Once again, like every year, time has come to celebrate Towel Day, a great occasion to ponder Life, the Universe and Everything.

Speaking of Life — a surprising number of people, including software developers, don’t know about LIFE, also called Conway’s Game of Life; an even smaller number is aware of the corollaries, let alone accept them as a fact of life (pun intended!). So what is LIFE?

In LIFE, which isn’t really a game, but rather a simulation, there is an infinite field of cells; cells can be in either of two states: dead or alive. Conway defined four simple rules:

  1. A live cell with fewer than two live neighbors dies (think: dies of loneliness).
  2. A live cell with two or three live neighbors continues to live.
  3. A live cell with more than three live neighbors dies (think: dies of overpopulation).
  4. A dead cell with exactly three live neighbors becomes a live cell (think: birth of a cell).

You start with an initial (e.g. random) set of live and dead cells, let time increase in discrete steps and after every step you apply these four rules. That’s all. After every step the board contains a new set of live and dead cells.

It is quite fascinating to see how structures, patterns (or objects) emerge, move, disappear and reappear. Some of these objects have been given names that aptly describe their nature, like “pulsars”, “gliders”, “glider guns”, just to name a few.

What is even more fascinating is that these objects are governed by higher-order “laws” that are not obvious from the four simple rules. For instance, you can observe that “blocks” never move, “gliders” always move diagonally and “lightweight spaceships” always move from right to left. (Here is a great site for trying out various patterns yourself.)

Isn’t this very much like our own universe? In our universe, we have some fundamental laws, which give rise to higher-level structures and laws, up to highest-level laws of physics or principles of human behavior.

What Conway proved was that complex structures can emerge from simple rules; he proved that you don’t need a Creator to obtain a complex universe, just simple rules, time and favorable circumstances.

Religious people often have a hard time accepting that. One the one hand, they argue, Conway didn’t prove the absence of a Creator, and second, Conway himself acted as a Creator himself since he — after all — created the rules of the game. Isn’t there, in our world, at least room for such a “Creator of Rules”?

Nobody knows, but I personally don’t think so. What Conway did was not create the rules — he rather zoomed in on a particular universe with a particular rule set, chosen from an infinite set of rules: He just shed light on one particular universe that is favorable of life in an infinite multiverse.

Let me close this post with the words of Stephen Hawking. Like all human beings, he doesn’t know everything, but he is probably one of the persons who has the best grasp of our universe:

“We are each free to believe what we want and it is my view that the simplest explanation is there is no God. No one created the universe and no one directs our fate. This leads me to a profound realization. There is probably no heaven, and no afterlife either. We have this one life to appreciate the grand design of the universe, and for that, I am extremely grateful.”

The Reason We Have a Job

“There’s truths you have to grow into.”
― H.G. Wells, Love and Mr. Lewisham

Let me ask you a simple question. Why do you have a job?

Maybe you are convinced that you have a job because you have a lot of obligations, like hungry mouth to feed and bills to pay. Or because someone told you that every decent citizen simply must have a job these days.

But no, that’s not the answer I am looking for. These are all valid reasons why you want or need or should have a job.

Or maybe you believe the reason is that you are such an irresistibly smart person that every company just wants to posses.

No, again, such factors only make you attractive to your employer, they give you a competitive edge over other people.

So what is the real reason you have a job? Here is my answer: unless you work for a non-profit organization (or the government) the only reason why you have a job is that someone — the business owner — believes that, overall, you generate much more money than you cost.

The verb believes is essential here. It could be that you, objectively, turn out not to be such a great investment for your company, maybe even a massive waste of money, but that doesn’t matter much: you can still keep your job as long as your boss’ belief in your money-generating abilities remains strong.

However, once this belief (or hope) is gone, your days are numbered. You may stay on the payroll for quite some time, but you will be walking around neither dead nor alive, just like a zombie. The question is not if you will lose your job — the question is when.

But how cruel are these greedy company owners? What about social responsibility? Is it always just about the money?

This attitude arises from a common misconception, and yes, it is always just about the money. It is not the responsibility of a business owner to make employees rich (not even happy) — it is just the other way around. Sure, there are hip companies which treat their employees extremely well, pay high salaries and grant extraordinary benefits; but let’s not forget: it is only because there is (still) an enormous belief in a high return on investment. If everything turns out well in this gamble there is a win-win situation: happy business owner, happy employees — all the ingredients for a long-lasting virtuous circle.

In the not-so-fortunate case — and every company will face stormy weather, even the hippest — a business owner has to eliminate cost to ensure that his business stays profitable; not performing these life-saving amputations would put his and his employees’ future at risk. Unprofitable companies cannot exist for an extended period of time in a free market; they will sooner or later be eaten by the competition. And that’s not a statement — that’s a fact.

So wise developers should avoid becoming dependent on an employer’s dreams and beliefs. Instead, developers should constantly and aggressively invest in their knowledge portfolio and keep their resume up-to-date. They should neither mentally nor financially become too attached to a company or technology. Instead, they should always be ready to move on.

Give an outstanding performance for your money, but treat every day as if it would be your last. Get rid of those personal items on your desk. Accept that employments are transient. This not only gives you independence and self-confidence, it also makes you indispensable for your current employer — and your next.