“Do you see what comes of all this running around, Mr. Bond? All this jumping and fighting, it’s exhausting!”

– Raoul Silva, Skyfall (2012)

Sometimes the tech industry is overwhelming. It seems like we drink from a fire-hose of new frameworks, languages, methodologies, things “considered harmful”, paradigms, tools and on and on and … oh, I need to lie down!

Managing all of this mostly involves learning how to filter incoming information while minimising the anxiety that we are falling behind or are in some other way unworthy. I have waded through said anxiety for a number of years now and I have picked up a few useful ways of filtering. I have learned most of this by doing it wrong. I would like to share it here so you can at least do it wrong in a different and more exciting way.

Grown ups talk in trade-offs

“You can tell the real by how the real interact.”

– The Game, Common

Favour sources of information which discuss trade-offs like grown-ups do. Trade-offs mean that all of the choices had merit but your constraints forced you to choose one over the others. All of the choices had merit. You had to choose one. Technology choice is always a trade-off. Always.

Sources of information (be they people, blogs, books, videos, etc.), where both the good and the bad are presented, are the most useful. Be suspicious of sources that are totally one-sided; especially for newer technologies where neither the author nor the industry as a whole may be in a good position to know the full story. These sources can be useful but your spider sense should be tingling that there is more to the story.

As a small example, I think that at this stage the trade-offs of OO style of software development are fairly well known among the community. Many developers can think coherently on where the potholes are. In contrast, the 2016 discussion of functional programming seems not to be so balanced yet. If you love functional programming but can’t clearly articulate the trade-offs (i.e. the good, desirable things you gave up in exchange for using it) then that is a gap in your understanding that you should recognise and attempt to remedy.

Some of the most interesting questions to ask of yourself and others are:

• What are the bad parts of some technology or methodology that I like?
• What are the good parts of my least favourite technology or methodology?
• What are the constraints that led me to make this choice?

Constraints are particularly interesting. It has been my experience that if my list of constraints contains only reasoned, logical engineering decisions then I am leaving stuff out. I notice in my own practice that many of my constraints have nothing to do with engineering. For example, the social structure of the team, state of the organisation, and my personal state have a huge impact and are just as influential as the engineering constraints.

There is almost no programming tool/technique that is never useful. GOTO is still a fine choice in a few contexts! A natural side effect of favouring balanced sources is that any sort of “language bashing” is a clear anti-pattern, and sources that engage in that should be avoided because they lack a nuanced approach.

The hype curve

The hype cycle is a useful way of thinking about your technology choices.

It is tempting to look at this graph and think that there might be a single point on it which represents your attitude to technology. In reality we must place ourselves on multiple places on the curve. You may be happy running the unstable master branch of your favourite library but you almost certainly prefer your file system drivers to be on the good ol’ plateau of productivity.

We must recognise that our time and attention is limited. If we choose to live on the steep slopes of the hype cycle for a particular technology then the trade-off is that other areas of the project must get by with less of our time and attention. Be respectful of where others choose to place themselves on the curve.

If we use that new exciting build tool (with the immature docs, probable bugs, etc. that go hand-in-hand with the steep slopes of the hype curve), then we have less time and attention for the features that ship to the customer. This is not to say that we should never use the “new thing” but we should be realistic about the trade-offs.

Be respectful of those who choose to hold steady on the plateau of productivity in the areas you focus on because they may be on slopes you cannot see.

Surf the big waves (books before blogs before tweets)

Each technology or methodology community has a few core ideas (things I will call “big waves”). Some examples are:

• The actor model in Erlang
• Monads in Haskell
• Functions as first class objects in Javascript
• Object design & thinking in Ruby, Smalltalk

Many of the above ideas didn’t originate in the community mentioned but that community uses them actively and has a good understanding of how they work. The big wave ideas in a community:

• have been around for a long time, perhaps since the very start of that community
• are well understood by the community, including the trade-offs
• are usually captured in books by virtue of having been around for a long time

Imagine for a moment these big powerful waves emanating from each community and bouncing around the Internet. When big waves meet they have complex interactions and generally create many more smaller waves. These smaller waves interact with each other again creating even more smaller waves. So it is with information. Big wave ideas from a community (often best captured in books) interact with ideas from other communities and produce smaller ideas (often captured in blog posts), which interact with even more ideas and produce increasingly smaller ideas (often captured in tweets).

As an example, monads are one of the “big wave” ideas in Haskell which interact with other language communities giving us blog posts (“learn monads in Javascript”) and tweets noting how confusing monads are.

I believe that the best way to understand “big wave” ideas is to try and view them while they are still a “simple” large wave rather than trying to piece them together from many smaller waves. If you want to gain a good understanding of monads then the clearest expression of that will be in Haskell and because it is a core idea to Haskell there are many fine books available which have the length to be able to teach the idea in a comprehensive way.

This is not to say that the “little waves” don’t have value but it has been my experience that is is more efficient to go to the source if you can.

Give it five minutes (or six months, or two years)!

“He said “Man, give it five minutes.” I asked him what he meant by that? He said, it’s fine to disagree, it’s fine to push back, it’s great to have strong opinions and beliefs, but give my ideas some time to set in before you’re sure you want to argue against them. “Five minutes” represented “think”, not react.”

– Jason Fried https://signalvnoise.com/posts/3124-give-it-five-minutes

The above good advice can be extended to help decide when to start looking at new technologies.

I started enforcing a “cooling off period” for new technology learning; i.e. I try to ignore any new technology for at least six months after I first hear about it. That gives me some time to see how things pan out a bit.

You may prefer a shorter or longer period but it is worth keeping things in your “peripheral vision” for an extended period before you dedicate any of your precious time and attention to it.

Old technologies a.k.a. veggies are good for you

How do you pick what to learn? I think most of us let our Twitter feed and email newsletters, etc. guide us. These can be good sources of information but they have a strong bias towards things which are new and novel. While there is nothing wrong with “new and novel”, I try to keep a list of the technologies I use on a very regular basis and add those to my learning. The payoff from this has been, frankly, huge. For example, I use Ruby, Rails and PosgreSQL every day, so I try to remember my time is better spent mastering them rather than learning that new language (much as I might find that more exciting).

Kindness is a sustaining advantage

As much kindness and patience as you can muster towards yourself and others is a sustaining advantage in all of this. Kindness is a good thing in general but I am specifically referring to cultivating it as a way of defusing the strong emotions that come with caring about a topic. Remember the hype cycle – the outcome of all that steep slopes drama is a small step increase in our overall productivity. This is a marathon not a sprint.