Skills

I call myself a “senior developer”. This page explains what I mean when I say that.

As a starting point, let me present the “skill list” approach. It is often followed to distinguish a developer from a senior developer. I use it myself at times, though with caution.

This approach works straightforwardly, as follows: One comes up with a long list of skills often required in software development projects. Here is an exemplary list:

Java, Ruby, Python, JS, ECMAScript, C++, Erlang, Spring Boot, Ruby on Rails, RxJava, Hibernate, Maven, Ant, Rake, SQL databases, Postgres, MySQL, Oracle, other databases, Cassandra, database design, message passing, CSS, SASS, React, JQuery, Docker, KVM, cloud admin, Kubernetes admin, Linux admin, Ansible, DNS admin, HTTP caches + reverse proxies + load balancers admin, version control system admin, git admin, ROCA, REST, micro-services, Netflix architecture, self-contained systems, crypto certificate handling, continuous integration, branching+merging workflows, version control migration, code review, continuous delivery, deployment on AWS, deployment on Kubernetes, software architecture, CAP theorem consequences, designing highly-available eventually consistent systems, interface documentation, software design documentation, best practice documentation, presentations, workshops, trainings, tutoring, agile methods, Scrum.

To find out whether someone is a senior developer according to the skill list approach, one essentially finds out which of the skills from the list the person has. Each skill earns them a tick. The more ticks, the more senior.

Of course, this being my home page, unsurprisingly this is not just an arbitrary skill list, but my skill list. Each of the skills on this particular list would earn me a tick. (And, while that list certainly makes exhausting reading, it is incomplete still.)

Learning!

This skill list approach has its value. Compare a person’s skill list to what your project demands right now. This can help you predict the short-term future, the first month or so. If said person entered your project (or company), would they have the skills to become productive right away?

But are you interested in short term productivity only? Should it be of prime importance to you?

We have a lot of progress and dynamics in our field. Whatever skills people have today will be generally insufficient two, let alone five years down the line. Not irrelevant, but insufficient.

So I recommend being interested in long-term prediction. Maximum overlap of a person’s present-day skill list with your present-day skill-demand list is a mediocre predictor of long-term performance. In the long run, learning ability is more important than knowledge.

So, to gauge whether someone has what makes a senior developer, you want to find out whether that someone is good at picking up new stuff.

Gut feeling

I have been told the higher up a career ladder some manager gets, the less clear-cut the questions become that confront her or him. Higher up the responsibility ladder, the consequences of decisions are increasingly hidden in the fog of the unknown. Of course, sharp, clear thinking is valuable at any level. But at the top of things, instinct and gut feeling are also needed. Quite urgently so.

A senior developer I expect to have well-developed and trained gut feelings, and put those to good use. In my personal case, there are certain classes of problems I tend to sense early. Things in the fog, not clearly visible at first.

I typically raise such problems with the team and the management of the place I’m at. This “gut feeling” thing is by no means intended to replace rational discourse, but rather, to fuel it. Further investigation may occasionally reveal it’s been a false alarm, and that’s ok. But often, we all end up agreeing I’ve sensed something important. Something that will hurt us later, if not addressed in time. (Or it’s hurting us already, so addressing it will boost productivity and happiness.)

Personally, I expect of myself, as a senior developer, sharp thinking, yes, but also the ability to drag out of the fog, to identify what hurts us, or will hurt us, as a software development team. I expect of myself the ability to identify problems.

Which brings me to the next step:

Problem solving

Problem solving is rather obviously wanted of any developer. But then, there are standard problems and there are real problems.

Standard problems are solved with standard means. This is the bread-and-butter job of any developer, including me as a senior developer. “Feature development”, we call most of it.

This is daily business, the normal thing, the ordinary. It finds little mention in these pages. It stands for quiet, busy times. Happy times. Let there be no mistake: I like feature development.

But then, there are the real problems. The challenges. Problems without standard, obvious, tested, proven answers. Stuff we don’t really know how to tackle. Scary stuff. The stuff of adventure.

Necessary adventure. This isn’t advertising information technology as some weird kind of amusement park or perpetual holiday season. This is about harsh reality. Not addressing such a challenge has risks attached. It may produce a road-block slowing further progress. It may even put at risk the results of a whole lot of work already thought accomplished.

So what to do when such a real problem surfaces? A problem nobody really knows how to deal with, including myself?

In such a situation, I often volunteer to try my hand at it.

Being willing to tackle a problem without knowing the outcome is also an important trait I expect of myself as a senior developer. Call of duty, if you wish. Pioneer mentality.

When addressing such a challenge, I usually find myself up to the task. Hey, though it’s been a while, I’ve earned myself a Ph.D. in mathematics!

Sharp, concentrated thinking is a good skill to have, and I love to exercise it. Also, I’ve got intuition. That “gut feeling” thing again. This time, it’s about knowing early some path will probably dead-end, without having to traverse it all the way. It’s about keeping some sense of direction in uncharted territory.

Over the years, I’ve successfully pioneered many problems that we initially didn’t know how to tackle.

Acquiring expertise

At this point, let me mention a curious highway that leads from pioneer to expert status. It is sometimes surprisingly short. This is how it works:

People in the team know I’ve pioneered domain X, solving some problem. Now they face another problem in domain X. Naturally, they’ll consult me about it.

Often enough, I can simply help them. Sometimes, it’s more difficult, but we manage to figure it out together. In the worst case, I have neither knowledge nor time to help, they’ll have to figure it out without me. But even in that case, I’ll come back later and ask them how it went. So, whatever happens will increased my knowledge regarding X.

Whatever happened, I’ve covered some distance on the highway towards eXpertise, if you pardon the pun. The idea that I’m an eXpert turns into a classic self-fulfilling prophecy.

Fast forward: Some time later, the team has solved its share of problems concerning X. A good part of the knowledge accumulated in the process has found its way into my head.

What’s needed on my part? Only a little service-orientation, general helpfulness, and basic curiosity. All of which come naturally, without thinking. (Those, too, are typical traits of any senior developer.) Personally, I’m also known to document stuff diligently. That doesn’t hurt, either.

That explained, let us now one more time consider the above skill list I claim for myself. Isn’t it a weird mixture? What the heck connects Cassandra database, DNS admin, and branching+merging workflows? Why would the same person acquire expertise in such a hodgepodge of topics?

Of course, many of my skills are just regular development skills. Stuff I’ve needed for feature development at one time or another.

But a lot is the result of solving real problems. As a senior developer, I’ve again and again traveled that highway from pioneer to expert.

To my delight, the journey continues.