A Software Crafter's Gamble

We usually absorb the technologies used in the projects we join. Some things we learn just for fun, not with an intention to use them productively. Fact is, as software engineers, we love to learn new things. Why else would we have chosen a career that commits us to a life of continuous learning?

In this post I want to share a basic trade-off of risk and reward, which I found best described in Chad Fowler’s book “The Passionate Programmer”. Most of us probably know the idea of technology adoption following a life cycle through different stages. During each of these stages, a new segment of users accept the successful, new technology.

Adoption is lead by innovators and early adopters, willing and able to take a risk that may put them ahead (1). A decision to learn a technology in this stage is risky and potentially very rewarding — if the technology finds wider adoption. But even if that turns out not to be the case, which is likely, at least we learned something new about our craft.

For example, I was recently taking a look at Elm and I like it. I do not expect it ever to become big, but I definitely learned something about clean frontend development. If JavaScript developers suddenly come to their senses and decide to switch to a typed functional language that deserves the name, I’ll do a victory dance and join the fun, though.

The breakthrough comes with acceptance by the early majority (2). If we are early adopters, we can now capitalize on our headstart and lead the broader adoption as experts. For example, with the success of Spring Boot, a background in Spring is going to help a lot. Teams are adopting it even without that kind of background knowledge, and being part of such a team means that learning about it now is a good idea.

With ongoing adoption by the majority (3), we must face diminishing returns on our learning investment. Learning a broadly adopted technology is usually something we do as students to become employable or during the first few months at a new job. As enterprise Java developers, we certainly should know the Java language and a few parts of the surrounding ecosystem.

Mainstream technologies seem like a safe bet to increase our chances to find a job, but they do not make us significantly more valuable as technology specialists. We also have to face the most competition here. Much of that competition is off-shore or near-shore. Due to lower cost of living, engineers in e.g. India or Poland can afford to offer their services at a lower price than many of us ever could. This means, if we want to compete in an established technology, we need to do so based on skill. And building that superior level of skill takes time. Better not to get too comfortable!

Many of us consider it undesirable to learn technologies (4) that are likely about to be replaced by this next big thing. There is, however, an even later opportunity in focusing on an outdated technology that was once widely adopted. COBOL, anyone? There are plenty of valuable legacy systems left written in COBOL. Engineers who are capable of helping companies to migrate step-by-step away from such legacy systems offer an invaluable service. They are also working on making themselves redundant. Will this happen with Java as well?

So there is a wealth of technologies to choose from. It is important to learn some that are widely used and make us employable. But a good technology portfolio also contains some risky choices. It is those choices that can give us time to build true skill and even propel us to technological leadership.