Senior developers

I guess this can be about senior anything, but I’ll stick to developers here.

There are loads of senior developers out there (and I don’t mean señor developer 🙂 this time). At least that’s what they call themselves and most of the time, it’s because the industry recognizes them as such.

I argue that, at least in most of the cases that I’ve encountered, this title is meaningless. Why? It should imply a lot of things, but it usually implies years spent in the industry, which is by far not enough to drive a team, to come up with adequate designs, to talk the client’s language etc.

I have seen far too many seniors that slow businesses down, or even drive them towards critical situations, because they know better. Classical example: senior developer imposes major code refactoring, in order to “stabilize the system”. Another example: senior developer destroys junior’s confidence by completely dragging their work through mud, trying to prove all the ways in which the junior is unworthy.

I’ve met a few real seniors. The experiences I’ve had, while working with them, can be represented by just a few words: safety, familiarity, clarity, simplicity, confidence. This is not at all related to how many technologies, frameworks or languages they master (although they do master several), but how well they can get their ideas across and how they can shed light on problems.

Oh yeah, by senior developer I mean also technical leads, team leads, architects and all the titles we like to invent to make ourselves feel better. How many times have you heard an architect saying something very clear and simple, with real business benefits? Now, how many times have you listened to an architect, having no clue what’s going on? Fun times, right?

Senior C# Developer (of course the caps make a difference…). Did you stop to think what that even means? Sure. It means a person working with C# for more than X years (5, 10?). Again with the time quantification… I’ve interviewed senior java developers, with 15 years of experience (almost exclusively java), that knew the language very well, but had no clue about JVM details. Good luck dealing with performance issues in production…

A senior developer is someone who makes things clear both in business and technical talk, who is really fun to work with, laughs and teaches you things. One key trait, as far as I can tell, is the diversity of things they’ve experienced: programming languages, industries, companies and life in general.

Harmful employees

What is a harmful employee? You’ve surely met your share in your career. Maybe you’ve been (or still are) one yourself. How can you know?

Usually, instincts will tell you when you are dealing with one and if all of them seem harmful, chances are that you are in fact the harmful one.

Let’s see what being harmful, as an employee, means. Businesses are run by people. The success of a particular business is directly translated into how well those people can contribute to it. Contributing poorly, means the the overall business health is less than it could be.

Considering business goals are rock solid and well communicated to everyone (meaning everyone understands what they need to do), here’s what a harmful employee looks like:

Poor technical skills that don’t improve

What this usually means is that the person does not actually want to do that particular job. Assuming they’ve had proper training and coaching, there is no reason to push them further into doing what they dislike. I call these people passively harmful.

A concrete example: Joe has to learn Python, to cope with the new tool-chain the team has adopted. After a month of study, Joe doesn’t seem to be able to do anything productive with Python.

Ever-present and putting a negative spin on everything

Some other helpful criteria is criticism, know-it-all (yet not helping and coaching), constantly using  the straw-man’s argument by focusing on meaningless problems and amplifying them. I call them actively harmful.

These people are very destructive, because they tend to shut team members off, blocking a serious part of the business resources. No matter if they do have some technical skills, overall they are more harmful for the business if they stay. They should definitely go!

A concrete example: Sarah has a senior role (tech lead, architect etc.) within team X. One of her duties is to do daily code reviews for the team. She always adds patronising comments, letting team members know they are not doing their jobs right.

I would always choose the friendly-and-inquisitive over the rigid-know-it-all-senior type.

We’ll talk in a future post about what the “senior” qualifier is used for and what it should reflect, in the context of software development.