You Have A Superpower

We software engineers have a superpower. It’s true! We do. And you came here to find out what your superpower is. How long do I keep you in suspense? One sentence? Two? Or do we just cut the chase. Let the cat out of the bag.

Well okay, I’ll tell you. In a moment. First, I want to show you a number:

16%

I was astounded when I saw this number. I was working for a software engineering department that very generously granted all engineers a sizeable personal training budget. You could spend it on anything related to personal education that wasn’t a paper book (for tax reasons…). It was more then enough for a ticket to a decent conference, a workshop, or a virtually limitless supply of online courses. And it wasn’t being spent. 16% was the amount of the overall training budget that had been spent towards the end of the financial year. Our company was giving us money to make us more awesome, and we weren’t spending it.

This, I thought, was really quite unfortunate — because our superpower is learning. Yes, learning.

I wanted to know why my colleagues were not spending their training budget. The people I was working with were all highly intelligent and incredibly talented. Absolutely some of the best engineers I have ever worked with. Why weren’t they spending their training budget? I conducted an informal survey and a few common themes emerged:

• I have no time
• I don’t know what to spend it on
• I already know what I need to know for my job. I know I should learn more stuff, but it’s hard to be motivated when I feel like I won’t get a chance to apply them in my job.

As a father of two — time is definitely a legitimate excuse. There’s not much we can do about that — although in a future article I’ll share my personal tips for learning efficiently when you have no time. You may or may not be lucky enough to have access to a training budget or a reimbursement program. That’s okay. There’s plenty you can learn just by spending an hour a day reading Hacker Noon. But setting aside the ‘how’, in this essay I’d like to convince you of two things:

1. That acquiring broad technical knowledge is worthwhile even if you think you can’t directly apply it in your current role
2. That learning really is a superpower

I’m going to do this by addressing four key themes, which I’ll attempt to stitch together at the end. Hopefully with a dazzling display of logic and reason. If not, then with a lot of exclamation points and another ‘kapow!’.

1. True radical and disruptive innovation are rare

To many of us the word ‘innovation’ is synonymous with ‘disruption’. But that is not solely the case. In the late 1980’s and early 90’s researchers Henderson and Clark proposed the ‘architectural model’ of innovation. They were looking to explain why, in some cases, relatively minor improvements in technology had disastrous effects on industry incumbents.

The example from their research paper was Xerox, who had been dominating the plain paper copier market in the 1970s and in fact had invented the core technologies. However when competitors started offering smaller, more reliable copiers it took Xerox eight years to launch a competitive offering. In that time it lost about half it’s market share. In the case of Xerox the actual underlying technological improvements were relatively minor. The core concepts were unchanged.

We won’t talk about the model of innovation itself in this essay, but rather the consequences. It’s informative to consider how market leaders can crumble. How previously cutting-edge, innovative companies can be left behind. Did they have bad management? Did they rest on their laurels and stop innovating? Did they ignore their customers? Well, no. In many cases market leaders were doing everything right. They had good management, they were listening to their customers.

An example of this is Kodak. When digital cameras first arrived on the scene they were slow, fragile, took terrible photos and held less images than a film roll. I recall my uncle had an early model digital camera which he used to take photos for his product catalogue. It saved photos onto a 1.44" floppy. Why would Kodak invest in a worse product when customers want better film?

Kodak did invest in digital cameras, but made the mistake of trying to match the quality of their film. Early technology was not up to the task and they failed to gain a firm foothold. They also anticipated that online photo sharing would rise dramatically. Fatally, they hedged a bet that people would share photos online in order to print them. They failed to realize that online sharing was a new business model, not a way to sell more film.

As Clayton Christensen wrote in his book The Inventors Dilemma, you can find yourself becoming incrementally better at something that people are wanting less and less. When this happens you can’t innovate your product. But you can innovate your business model. Kodak was one example, but I have two more that are closer to the heart of us engineers. Docker and AWS EC2.

The story behind Docker is an interesting one. The company behind Docker was originally ‘dotCloud’, who were making some kind of polyglot PaaS thing that no-one really cared about. They were just about to go under when they had the insight that the tools they were building their product with were more interesting than the product itself. So they pivoted to try and build a business model around Docker, although when they started they had no idea what that business model would be.

But Docker is nothing new! It is built on top of cgroups which were added to the Linux kernel in 2007. Before cgroups were in Linux they were in Unix. We had Solaris Zones around 2004. But before we had containers in Unix they were in Linux — we had VSERVER around 2001. Although they were in Unix before that, with FreeBSD ‘jails’. Ultimately though it all boils down to the chroot system call that dates back to 1979.

Docker is not new!

EC2, my second example, was certainly nothing new from a technological standpoint. Just a virtual machine behind a REST API. What’s new about that? Nothing except the pricing model. When we boiled docker we got chroot. When we boil EC2 we get virtual memory and RPC. EC2 was incredibly disruptive, but not technically. Under the hood the technology was familiar, only an incremental improvement on what had come before.

This essay is meant to be about learning, and here I’ve been rabbiting on about innovation. The point I’m trying to make is that even though it may feel at times that technology evolves at a blinding pace, the underlying technology moves more slowly than it appears on the surface. True disruptive innovation absolutely happens, but most disruption actually happens when tiny, incremental improvements to existing technology reach a tipping point, or someone changes the business model.

So, at last, we reach the pointy end of the point. The “oh that’s interesting but I can’t apply it in my job” technology you see today could be tomorrow’s disrupter. Broad learning now could give you a leg-up when that next big ‘paradigm shift’ comes along.

2. Learning accelerates learning

The corollary to the previous point is that new technology is mostly just old technology with a version bump and a new logo. Which means that the more you know, the easier it is to assimilate new knowledge. Learning will accelerate learning. The more you know, the more you know!

Two illustrate the point let’s do a simplified breakdown of two technologies that can be easily understood in relation to their ancestors or inspiration. EC2 and Kotlin.

Simplified lineage of EC2

As we mentioned already, EC2 is just a virtual machine with a REST API. Virtual machines are build on the concepts of virtual memory — while down the other fork we see REST is like SOAP but with JSON, and SOAP itself was an RPC mechanic like CORBA, RMI or DCOM before it, but over HTTP.

This is a vast over-simplification of course, but I feel it serves to illustrate the point. Our next example is a programming languages. One of my favorites, Kotlin.

Simplified lineage of Kotlin

In the diagram above I’ve attempted to illustrate the evolution of Kotlin in terms of the languages that most directly inspired it and the languages that inspired them in turn. (This may not be historically accurate, but it’s how I think of it anyway).

As I’m fond of telling anyone who wanders too close (even strangers in the supermarket, they hate that!), “Kotlin is just C# with Scala syntax for the JVM”. If you happen to know C# and Scala, you already know Kotlin.

So learning new stuff is easy, if you already know everything else. Although, admittedly, that’s a lot to learn. Especially if you don’t already know everything else.

But there’s good news! You don’t actually need all of that knowledge in your own head to gain benefits from it. Which is my segue into a seemingly unrelated topic: diversity.

3. There is value in diversity

Having a diverse and inclusive culture is simply the decent and ethical human thing to do. No arguments. But curious souls have sought to quantify if there might be other benefits as well, and it turns out there are! According to a 2015 McKinsey report and the Credit Suisse Research Institute:

• Diverse companies are 35% more likely to have higher financial returns
• Gender diverse companies are 15% more likely to have higher financial returns
• Companies with lower diversity are less likely to have higher financial returns

Why? How does the diversity effect work? How does it improve your company’s bottom line?

Some known benefits that can improve profitability are that diversity helps you win the war on talent; strengthen customer orientation; increase employee satisfaction; enhance the company’s image and improve decision making.

It’s this last point we’re going to zoom in on. Diversity helps you improve decision making. Why? I’m not sure anyone can say for certain, but in the words of one CEO:

“Diversity creates dissent, and you need that. Without it, you’re not going to get any deep inquiry or breakthroughs”

The current thinking is that people from diverse backgrounds are more likely to challenge each other. If this is done constructively it leads to multiple perspectives and debate, which in turn create a situation in which the participants are more likely to detect novel solutions.

Intriguingly, just as there are different types of innovation there are also different types of diversity. The main types are:

• Social-category diversity —such as ethnicity, gender, age and physical disabilities
• Informational diversity — such as education, experience, tenure, skills, expertise and functional knowledge.
• Value diversity — such as ideological beliefs, values and personal differences

This being an essay on learning, we’re going to focus on informational diversity. This alone is not enough to create the benefits of a diverse and inclusive team, but it one aspect of the whole that you can address simply and effectively.

As a software-engineer you’ve probably felt what a lack of informational diversity feels like. It’s that uphill battle you face when you suggest bringing in a new language, trying a new architectural style, changing your logging format, and such as that. It’s the grumbling, the push-back, the ‘Java 7 has always been good enough for us’. It’s not where you want to be. Skepticism is fine. Boring technology is proven technology.

But “prove it” is fine. That’s a great response if it indicates a willingness to be convinced. Much better than “No. That’s not how we do it here”. It’s also better than, “Yeah, sure.” Because you might be wrong, and you might have just led the team down a six-month rabbit hole trying to justify why a gossip-based consensus protocol that requires mesh connectivity is worth drilling holes through your firewall for. Not that I’m bitter or anything.

Curiously, the way you arrange your diverse teams actually makes a difference. Let’s say you have 100 engineers in your department but only ten of them are women. You want the benefits of diversity, so what should you do? Ten teams of ten, each with one woman?

In the picture below I show the different types of diverse teams. Before moving on to the next paragraph, challenge yourself to think for a moment about which type of team might best exhibit the benefits of a diverse team.

Types of diverse teams

A uniform team is clearly not diverse, we can rule that one out. A skewed team as you might imagine contains only a token minority, and these tend to not perform so well. In studies so far, tilted teams actually seem to show more of the benefits of diversity than balanced teams. Perhaps because a balance reduces some of the dissent and constructive criticism?

This does mean, however, that as your company works towards improving diversity you may not be in a position to have all your your teams be diverse. What can you do with uniform teams? Are they doomed to play second fiddle to your creative, high-achieving diverse-teams?

Actually no. It turns out that uniform teams have strengths of their own. Uniform teams seem to perform better at ‘exploitation’ tasks. That is, work involving a high degree of production, efficiency and execution. Uniform teams are great at churning the work out. Diverse teams, on the other hand, perform better at work requiring experimentation, innovation and problem solving.

Now … what sort of work would you prefer? This is completely and totally a personal opinion, but my preference is definitely for the second type of team. If yours is too, you want to be part of a diverse team, and as we have seen, diversity of thought absolutely counts. Moreover, diversity of thought is something you can improve through continuous, broad learning. Even better, you don’t all have to learn the same things. In fact it contributes more to diversity if your team all learn different things and acquire different skills.

4. Break out of your comfort zone

In 2015 I attended the YOW Sydney conference by accident. I bumped into one of the engineering leads in the hallway (actually it wasn’t a hallway because open plan — but it was the place the hallway would have been if we had had hallways).

“Oh hai”, he said. (I’m paraphrasing). “Would you like to go to YOW tomorrow? We’re exhibiting and I’m meant to be manning the booth, but I need to attend an all-day board meeting instead.”

“Umm,” I reply, “let me just delete all my calendar appointments… I mean think about it… YES!”

So I went, and one of the talks was by Dave Thomas, author of ‘Pragmatic Programmer’, which us engineers of-a-certain-age will know well. I can summarize his talk thus:

• Dave Thomas is an old fart
• Old farts get stuck in their ways
• So do young ones
• You get comfortable, you get lazy
• What do you call a lazy programmer?

Okay — what do you call a lazy programmer? You can derive the answer by looking at the previous section on diversity. What are uniform teams good at? Production, efficiency, execution. Without creativity, innovation or debate. If you’re stuck in a rut, working on the same code-base, doing the same old thing day in and day out, there’s a name for that. To me it sounds like we’re describing a …

Maintenance Programmer

Bring it home now!

So to summarize, learning is a super-power, because:

1. Disruptive technologies will not catch you off guard. You saw them coming!
2. You will assimilate new knowledge at lightning pace!
3. You can combine powers with your colleagues and let the innovation flow!
4. You will not get stuck in a rut. You will stay passionate, find creative solutions and enjoy your work!

Kapow! Image source: Pixabay