Summary: Software People and Management

Guess what – software people aren’t like regular people! There are differences in the ways they think and act, judging results can be difficult, and hiring and managing is challenging. This is a summary of my writing on the subject.

Skills, Training and Status

When you get a degree in CS or learn a programming language, you’re all set, right? Actually, those things are pretty much the same as knowing how to hammer a nail when building a house. It’s a nice start, but there are levels and levels of skill beyond the basics.

There is perennial conflict between young and old in software, perhaps more than other fields.

You might think that getting a degree in Computer Science prepares you to be an effective programmer, much like getting an MD prepares you to be an effective doctor. A comparison of the two makes it clear that CS education is sadly deficient.

Does status in software correlate with your skills, kind of like how hitting more home runs gives you status in baseball? Sadly, no. One aspect of software status is that the more layers there are between you and real customers, the more status you have.

There are other dimensions, for example the more management layers between you and fingers-on-keyboard programming, the greater the pay and status. And there are others!

There is a similar skills and status hierarchy in data science

One of the sad things about software is that writing great code and getting credit for it are largely unrelated to each other.

Programming skill and power in the programmer is far more important than the differences between programming environments.

At least in some environments, high-performing nerds are highly valued.

Understanding Programmers

When you think about hard-core programmers, the word "nerd" comes to mind. In the poplar imagination, "nerd" often seems to mean guys who play lots of games. And have attitude. Of course there are such people. But the very best programmers, in my experience, don't match that description.

Some programmer-nerds go beyond introversion.

Temple Grandin's views are always valuable.

In the end, the best nerds like to get stuff done -- and have fun.

And of course, normal people can react to a passionate desire to get things done in the best way possible as arrogance.


Hiring software people is a challenge. There is widespread bad advice that interviewing for a software job should involve lots of chatting and relationship building.

There are definitely better ways to select software people than the normal interview process.

The CTO of an organization is a special case. The requirements for the job are frequently impossible to meet.

While CTO’s should be tops in technology, the best of them understand finances.


Managing software people isn’t easy. Most managers tend to focus on process instead of substance.

Many companies have what's called a software architect. What should that person do?

If instead of just paying attention to abstract process managers paid attention to what the programmers are actually doing, things would improve.

One of the reasons software managers tend to focus on process instead of substance is that they have zero experience building software. Worse, it's literally invisible to them.

As you can see from Dilbert and coal mining, you do a whole lot better managing something you've done or at least can see.

All too often, nontechnical managers make important decisions instead of software people.

When non-technical people do all the managing, the programmers who know stuff either leave or learn to keep their mouths shut in the face of stupidity and lie.

In other fields, it’s mostly people who DO the highly skilled thing who become managers of it. It should be the same in software.

Non-technical managers think that MBA skills are the main thing that's required to be a good manager. Wrong.

Here's how I learned from a course at Harvard Business School that the MBA teaches confident ignorance in terms of software.

So with all this, should a skilled software aspire to be a manager? Dilbert makes an excellent argument.

It’s easy to focus on relationships instead of technical substance when managing.

There is also the classic case of ego. It's been a big problem in other technology-based fields, and it's a big problem in software.

The way group management changes as the group grows can be destructive.

It’s clear from the pay scales that most companies value management much more highly than the people who write code. Unlike baseball, for example, where the people who play on the field get the highest pay.

Does having a CS degree lead to the best pay? Not as much as you’d think.

There are many ways otherwise good programmers can go wrong. One big one is the result of perverse incentives.

Programmers who are considered to be “stars” often have issues unique to software that hurt group efforts and are rarely recognized.

On the other hand, the whole process of training and promoting the most talented programmers is broken. It can learn a lot from ballet.


The above are highlights of what there is to learn about software people. For more, see my book.