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, Spring Boot, RxJava, Hibernate, Maven, Ant, SQL databases, Postgres, MySQL, Oracle, other databases, Cassandra, database design, message passing, Python, Ruby, Ruby on Rails, Rake, CSS, SASS, JS, React, JQuery, Docker, KVM, cloud admin, AWS admin, Kubernetes admin, Linux admin, Ansible, HTTP caches + reverse proxies + load balancers admin, DNS admin, ROCA, REST, micro-services, Netflix architecture, self-contained systems, version control system admin, version control migration, git admin, crypto certificate handling, continuous integration, branching+merging workflows, 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, 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, naturally, the list is incomplete.)
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 such a short terms? Should you?
We have a lot of progress and dynamics in our field. Whatever skills people have today will be insufficient two years down the line.
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 skill list with your present-day skill-demand list is a mediocre predictor of long-term performance. Learning is more important than knowing. Try to find out whether the person is good at picking up new stuff.
And, ideally, try to find out what’s needed to trigger the person into learning new stuff. Read on…
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.
The consequences of decisions are increasingly hidden in the fog of unknown. Of course, sharp, clear thinking is valuable at any level. But at the top of things, instinct and gut feeling are also needed. In fact, they become increasingly important.
As a senior developer, I also need a well-developed and trained gut feeling. In my personal case, there are certain classes of problems I tend to sense early. Things in the fog, not clearly visible at first. Until you look at it from the right angle, maybe.
When that happens, I raise such problems with the team and the management structure of the place I’m at. Often, we agree I’ve sensed something that will hurt us later, if not addressed in time. Or it’s hurting us already, and addressing it will raise productivity. (Of course, it also sometimes happens that further investigation reveals it’s been a false alarm.)
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. To identify problems. Which brings me to:
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 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 answers. This is the stuff we don’t really know how to tackle. Scary stuff. The stuff of adventure.
Necessary adventure. This isn’t advertising some weird kind of holiday season or amusement park. 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 regular, standard work.
So what to do when such a challenge surfaces? When nobody (including myself) really knows how to deal with it?
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. 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, which I love to exercise.
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 to its end. About keeping a sense of direction in uncharted territory.
Over the years, I’ve successfully pioneered many problems that we initially didn’t know how to attack.
At this point, let me mention a curious highway that leads from pioneer to expert status. It is sometimes surprisingly short. It goes like this:
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.
Sometimes I can outright help them. Sometimes, it’s more difficult, but we 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 in that case, I’ll come back to them later and ask how it went. So, either way, I’ll increased my knowledge regarding X.
Either way, I’ve covered some distance on the highway towards eXpertise, if you pardon the pun. The idea that I’m an eXpert becomes a self-fulfilling prophecy.
On my part, only a little service-orientation, helpfulness, and curiosity are needed. All of which come naturally, without thinking. That I’m a developer known to document stuff doesn’t hurt, either.
Some time later, the team has solved its share of problems regarding X. A good part of the accumulated knowledge has found its way into my head.
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 have expertise in such a strange mixture of topics?
Of course, some of my skills are just regular developer skills. Stuff I’ve needed for feature development at one point in my life or another.
But a lot is the result of problem solving. As a senior developer, I’ve again and again traveled that highway from pioneer to expert.
The journey continues.