Assume you get to know a person and want to gauge whether that person is a senior developer. How do you find out?
“Skill list” is one approach often followed. You come up with a long list of skills often required in software development projects. Here is my sample list:
Java, Ruby, Python, 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, JS, React, JQuery, Docker, KVM, cloud admin, AWS 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, designing highly-available eventually consistent systems, interface documentation, software design documentation, best practice documentation, presentations, workshops, trainings, agile methods, scrum.
To find out whether someone is a senior developer according to the skill list approach, you find out which of these skills the person has. Each skill earns them a tick. The more ticks, the more senior.
On a sideline: This is my home page. So here, I have the license to brag, right? So let me nonchalantly mention: Each of the skills on that particular list would earn me a tick. And, while the above list certainly makes exhausting reading, it is incomplete still.
The 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 insufficient two, let alone five years down the line. Not irrelevant, but insufficient. (With the exception of weird, slowly-moving places. The kind of place where a real senior developer would not want to dwell for long. At least, I wouldn’t.)
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 is more important than knowing.
Try to find out whether the person is good at picking up new stuff.
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 can also put to good use well-developed and trained gut feelings. 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 structure of the place I’m at. Occasionally, further investigation reveals it’s been a false alarm. But often, we all agree I’ve sensed something that will hurt us later, if not addressed in time. Or it’s hurting us already, so addressing it will boost productivity.
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 is rather obviously wanted of any developer. But then, there are standard problems and there are real problems.
Standard problems are those that can be 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. This is the stuff we don’t really know how to tackle. Scary stuff. The stuff of adventure.
Necessary adventure. This isn’t about advertising information technology as some weird kind of amusement park or perpetual holiday season. This is about reality. Not addressing such a challenge has risks attached. It may produce a road-block slowing further progress. It may 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, even if 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.
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 diligently document stuff. This 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 point in my life 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.