The vexing nature of brilliance

This story, entitled “Brilliance,” appears without explanation in Michael Jackson’s 1995 book, “Software Requirements & Specifications.” For those of us who’ve been around software a while it needs no explanation. But for the benefit of a wider audience I’ll explain why this story is so significant for every software engineer. I’ll also share my opinion on what to do about it.

(This essay was originally published on medium)

“Some years ago I spent a week giving an in-house program design course at a manufacturing company in the mid-west of the United States. On the Friday afternoon it was all over. The DP Manager, who had arranged the course and was paying for it out of his budget, asked me into his office.

“‘What do you think?’ he asked. He was asking me to tell him my impressions of his operation and his staff. ‘Pretty good,’ I said. ‘You’ve got some good people there.’ Program design courses are hard work; I was very tired; and staff evaluation consultancy is charged extra. Anyway, I knew he really wanted to tell me his own thoughts.

“‘What did you think of Fred?’ he asked. ‘We all think Fred is brilliant.’ ‘He’s very clever,’ I said. ‘He’s not very enthusiastic about methods, but he knows a lot about programming.’ ‘Yes,’ said the DP Manager. He swivelled round in his chair to face a huge flowchart stuck to the wall: about five large sheets of line printer paper, maybe two hundred symbols, hundreds of connecting lines. ‘Fred did that. It’s the build-up of gross pay for our weekly payroll. No one else except Fred understands it.’ His voice dropped to a reverent hush. ‘Fred tells me that he’s not sure he understands it himself.’

“‘Terrific,’ I mumbled respectfully. I got the picture clearly. Fred as Frankenstein, Fred the brilliant creator of the uncontrollable monster flowchart. ‘But what about Jane?’ I said. ‘I thought Jane was very good. She picked up the program design ideas very fast.’

“‘Yes,’ said the DP Manager. ‘Jane came to us with a great reputation. We thought she was going to be as brilliant as Fred. But she hasn’t really proved herself yet. We’ve given her a few problems that we thought were going to be really tough, but when she finished it turned out they weren’t really difficult at all. Most of them turned out pretty simple. She hasn’t really proved herself yet — if you see what I mean?’

“I saw what he meant.”

Jane’s brilliance is the enemy of her career. Like a professional athlete, she makes what she’s doing look easy. This makes her less appreciated. Compounding this problem is her ability to convey her understanding of tough problems to other people. Every time she increases her coworkers’ insight, she decreases their appreciation of her brilliance.

The vexing thing about this story is that Jane is delivering more value to her company than Fred. She’s solving problems quickly and effectively, creating solutions that will be cheaper to maintain, and making people around her smarter. Yet Fred comes across brilliant because it’s perceived he’s tackling more complexity. The reality is that complexity is tackling him.

Of course, these characters are fictional extremes. There’s some Fred and some Jane in every software engineer. Our hope is that over time we handle more challenges as Jane does and imitate Fred less often. Our fear is that as we do this and the value of our work increases, that our perceived value will decrease.

A professional athlete who makes things look easy has standardized metrics (points scored, etc.) and these metrics effectively correct misperceptions about ability. Some points are more difficult to score than others, but in aggregate those points say a lot. Software engineering is different. The variation in difficulty is so great and so subjective that, at best, metrics tell you only a little. At worst, they are prone to measuring the opposite of what you want, e.g. lines of code.

So what do we do? Give up on software engineering because as you get better your career will get worse? No. I’m writing this essay to tell you you don’t need to do that. I’ve been a full-time software engineer continuously for 25 years, and I’m 19 months into the best job I’ve ever had.

Focus on being effective. I’ve done worst in my career when I’ve lacked this focus, and best when I’ve had it. By effective, I mean having a positive effect on the company you work for. “Wait,” you say, “Isn’t that what Jane was doing?” Yes it is. Don’t forget: Jane came to her current position with a great reputation. The perception problem she’s facing in this story is temporary. It’s unfortunate that her current boss is so wowed by what appears to be cleverness. But there are a lot more people in her company who care about effectiveness.

Some readers (you?) are mad at me right now because my simplistic advice to focus on being effective ignores the reality of office politics. I disagree. It’s a smart political move. It builds relationships. There’s a sure-fire formula for building relationships, whether it’s with a coworker, a potential spouse, an audience member — anybody.

1. Find out what makes them happy.
2. Tell them what you’re going to do for them.
3. Do it.
4. Tell them you’ve done it.

If you focus on being effective, you’ll naturally follow this formula. If you’re a software engineer, unless you’re in a software consulting company, there’s somebody in your company who understands its needs better than you. Whenever you see this person, you’ll naturally ask questions to find out what would benefit the company most. That’s step 1. Next, create tickets in your company’s system and alert that person to their existence. If you’re not in a position to do that, stop reading now because my advice is not useful to you. Come back and re-read this when you have a better job. In today’s market that likely won’t be long.

Skipping ahead to step 4, you’ve likely learned already without any help from me that software is not effective if people don’t know it exists. If you’re trying to make your work effective, naturally you’ll make sure stakeholders know that what they wanted has been implemented. Voila. Without even trying, you’ve just engaged in politically astute relationship building. Repeat this pattern, and you’ll develop a reputation as an exceptionally valuable employee.

While you’re doing this, Fred will be engaged in highly-visible firefighting to solve problems he himself created. This has a certain political value, and there may be lots of people who are convinced that Fred is full of cleverness and hard work. But long-term, people instinctively value getting what they want. Deliver what people want. In the unlikely event that fake technical wizardry still wins, go work somewhere else.