What Makes a Good Technologist

A recent job application asked me to reflect on the characteristics that define a good data scientists. I really liked the question and the kinds of thoughts it generated in my mind, so I decided to poke around this topic a bit more and think about the kinds of qualities that make a good technologist. The term technologist is quite broad in scope - indeed, most of the appliances we use in every day life (including writing - the applicance I’m using to communicate with right now!) is a technology. However, for the purposes of this exploration, I am going to limit the word technologist to mean someone who works with computer technologies and produces applications that are used by others. While perhaps unnecessarily limiting, this definition fits well with the way the word and its close relative ‘techie’ is used these days and also means that I can draw on my four years experience in the industry.

Deep curiosity

The desire to know why and how things work. This could be curiosity about anything - our fellow humans, a load balancer, a programming language, an organisation, a political system, the natural world, the nature of time. Curiosity about technical things is often described in terms of analysis, that is, disassembling something into parts to learn how it works. While this is definitely one way to explore technical systems, another one is careful observation and experimentation. Systems can exhibit emergent properties that may not be clear when the components of a system are examined separately. The behaviour of software at runtime can exhibit properties that are not obvious from static analysis of its components. A system running in a staging environment may not develop the same quirks that a system running in production under extreme load does. Curiosity sometimes means being frustrated, because sometimes there is no clear answer. Or perhaps the answer begets even more questions. Sometimes, the answer is a trade off, that rather pesky ‘it depends’ that tends to frustrate those that have a need for every problem to have a neat and tidy solution.

Pathfinding

Often, there will be no answer available or the answer will not be documented. The amount of software components, middleware, languages and libraries is growing (probably exponentially) and technologists are increasingly becoming heavily specialised in a single programming language, a family of web technologies separated by function (as demonstrated by the classic division between frontend and backend development), a part of the software development lifecycle (for example application development versus ops - though the devops movement has made significant efforts to bring the two closer together), a layer in the application stack (database administration and tuning, building infrastructure etc). Being an expert in everything is starting to become nearly impossible. On a daily basis, you are likely to encounter and have to work with tens of different abstractions that have been developed by other programmers to solve their problems and you are going to have to figure out a path to apply their generalised solution to whatever problem you are solving at the moment. Sometimes, the abstraction will not be documented well and you will have to open the lid and peer into the can of worms, traverse the lines of code and poke and prod at the program to understand how it works. Sometimes, you will work on an area of a stack and all the people on your team who used to be experts in this area have long left for other adventures. There will be no one to ask, so you will have to become good at finding paths without a map.

Patience

Premature automation and abstraction are hard to abstain from. From the blurbs in job applications to presentations at popular tech conferences, we are constantly exposed to the message that programmers are supposed ‘automate, automate, automate’ or abstract a particular solution to a library that can be re-used by others. It’s good to do these things, but with a dose of patience. Don’t lock yourself into an abstraction until you have sufficient understanding of the problem and its solutions. Don’t spend time automating something just for the sake of automating. Badly done automation usually has a far wider blast radius than a single manually run command.

The hammer and the nail problem

When you have a hammer, everything looks like a nail - is that how the saying goes? When you are a programmer, all problems, even the deep complex social problems, look like something you could easily solve with an app. We as technologists have come to have a certain level of disdain for discussion, writing and humanities - something that I have participated in and regret. Our ideal hero remains the lone techie in the hoodie who comes up with a brilliant app in his parents garage or college dorm room, goes on to raise millions in VC funding, reach eye-watering unicorn valuations, gets profiled in Wired and takes the stage at Techcrunch. Code can solve everything, except when it can’t. Sometimes the right answer to a problem is not code. Keep this mind and think about it regularly.

We’re trained to think about tradeoffs when we build applications and systems, but we rarely think about tradeoffs when it comes to society. We rarely ask, who really benefits from this technology I am building? It’s a cool piece of tech and that makes it fun to work with, but who will really pay the cost once it’s put into production? The media critic Neil Postman once remarked that the people who pay the price for a technology are often not the same who profit from it and this thought has been on the forefront of my thinking about my career and its effects on society for a few years.