What type of developer are you: A technician or an artist?

When I used to work for a big computer manufacturing company, I once had a boss with an interesting hiring philosophy. He divided technical talent into two groups: technicians and artists.

If he wanted someone who knew how to work a piece of technology inside and out, was able to follow instructions exactly and could be relied upon to do what needed to be done when it needed to be done, he hired a technician. If he needed someone to solve a particularly perplexing problem or develop a viable resolution within the constraints of a given budget, he hired an artist. He didn’t expect a technician to do the work of an artist and vice versa.

What type of developer are you? And, what type of developer is made for the current state of the IT industry? Let’s find out.

A two-edged sword

Over the years, I’ve found the talent divide between technician and artist to be consistently accurate. Also, I’ve noticed that as companies grow and mature, the number of technicians in the workforce tends to outweigh the number of artists. This is a two-edged sword.

In a company with a lot of technicians, an employee who can follow directions is well suited to the command and control management style under which large companies operate. Can you imagine how difficult it would be to manage a company the size of Google without a high degree of compliance, reliability, and predictability among the workforce? At some point, if the company wants to get anything done at a strategic level, somebody at the top needs to say, “Go here” and the company needs to follow those directions. Following directions has value and technicians understand this.

On the other hand, employees that consider themselves to be primarily technicians run the risk of limited employability when change comes.

“You can retire on this circuit board.”

For example, my friend Mark studied to be an electrical engineer. After graduation, he was fortunate enough to get a job in the aircraft industry. His job was to maintain a small circuit board that was essential to the operation of the aircraft. Shortly after he arrived, Mark’s boss took him aside and said, “Mark, you can retire on this circuit board.”

Mark saw his future unfold before his very eyes. His entire world would become that circuit board. Every detail, every solder point, every piece of electricity that surged through the circuit board would be his to contemplate and control. He and that circuit board would become one.

A short time later, Mark quit and went back to school to become a landscape architect. Why? Mark didn’t want to wake up out of a job 20 years later because a newer, better circuit board was introduced. He recognized that he could be unable to find gainful employment because all he knew about was a circuit board that nobody wanted. Mark understood the risk at hand and acted accordingly.

The risks of a technician

I’ve seen Mark’s situation play out more than once with this type of developer.

A bright software engineer out of college who did all the right things — studied hard, passed the tests, got certified, followed all the rules — gets a job with a big tech company. They are assigned to take care of some tech that’s not of their making. The engineer absorbs the technical legacy of others and might be able to improve upon that legacy. The engineer becomes reliable and does what needs to be done at the appropriate time. The rewards are ample for years, maybe even decades. They become what is called a “Go to person.”

Then one day, the tech stack changes. All the old rules are no longer valid. The technician-engineer needs to learn to operate in this new world. They go to “training” to learn the new rules only to find out that the technology is so new, that a lot of it is made up as it evolves. The only rule is that “You need to figure it out.”

Many technicians flounder. While they’re more than capable of filling out technical prescriptions sent to them by other employees, the actual figuring stuff out element lags. On the other hand, artists don’t have this problem. They’ve been figuring things out all their lives.

If you give me a tuba…

The scenario mentioned above leads me to the famous quote from John Lennon: “I’m an artist, and if you give me a tuba, I’ll bring you something out of it.”

Artists are very good at seeing possibilities within a given set of constraints. An accomplished artist can make something out of anything. Also, they tend to be quick to adapt to new surroundings.

Whether the artist is a software developer, painter, musician or chef, they’re always on the lookout for something new. Hence, their attraction to the big picture, like getting the concepts and synthesizing the old with the new to create something unique. They don’t need to go to “training” because they train themselves continuously on how to absorb new ideas and create better ones.

Artists bring a lot to the technical landscape, but they lack many of the qualities that technicians have. They aren’t very good at following rules and they can be unpredictable or unreliable. Just ask any manager who had to suffer a missed deadline because a prima donna type of developer spun their wheels trying to create a breakthrough that may never see the light of day.

Artists can also be high maintenance, which is why they often tend to work in the safety and confinement of the R&D departments in larger organizations. What artists consider to be random inspiration can seem to those on the outside like catastrophic chaos.

Still, there are significant benefits to be an artist in technology.  Artists don’t share the same unemployable risk of their technician counterparts. While technicians languish when change comes, artists are often the perpetrators of said change.

In the event things go south and the business suffers a downturn, it’s the artists who will be in high demand because of their eye for innovation. Just look at Microsoft before the advent of Azure, for example. It wasn’t a pretty picture. Compliance, while safe, will only get you so far when the chips are down, and the wolf is at the door.

But, the thing to remember is that most times, the chips aren’t down. In fact, for a big company with a sizable legacy of technology, most times the chips are stacked up very nicely for everyone’s benefit. As a result, few companies want to rock the boat unless it’s sinking. Only then will the business do whatever it takes to stay afloat, such as calling in the artists to figure it out.

The best of both worlds

It might seem as though I described the technician’s life to have the benefit of compliance with the risk of unintended obsolescence. Also, it might seem as if I painted the artist’s life to be one of freedom, independence and unencumbered employment. This makes a nice story, but the reality is a bit different.

If you want to be a competent, viable professional in technology, you need to hone both sensibilities to a very fine degree. You need to combine the discipline that goes with learning the “rules” with the courage to go beyond them. You can’t have one without the other. Remember, that behind every inspired performance, there are hours of mundane practice.

In terms of employability, the trick is to stay engaged and current. Don’t depend on your employer to take care of you. Your employer’s essential goal is to make money. No money, no business. It’s that simple. The company’s need to support your technical proficiency only goes as far as is economically feasible. It’s not a good thing or a bad thing. It’s the way it is.

If you fall into the trap of doing only the minimum within your current technical boundaries to earn a paycheck and expect your employer to educate you when the boundaries need to change, you run the risk of unintended obsolescence.

The easiest thing in the world is to paint yourself into a corner and call yourself a technician or an artist. While taking sides is all the rage these days, the harder, probably more lucrative career path is to be a competent combination of both.

App Architecture
Software Quality
Cloud Computing