Category: Uncategorized

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.

To understand the purpose of software, we first need to understand what software actually is. So what is it? It’s a tool. Nothing more, nothing less.

We developed tools, over the course of our evolution, to help us gain significant advantage over other species and to make our lives better. Our brain’s capacity to create sophisticated technology is what brought us to where we are today. We developed an unprecedented way of living, here on this planet and, in the last few decades, we changed it so drastically and so fast, that we can barely understand the impact it has on our environment and on ourselves.

The advanced technology we use today is mostly created and run by software. Farming tools, communication devices, transportation, scientific research, weapons, etc., they all have software controlling most stages in their processes. So the purpose of software, as the tool that it is, is to operate other tools, which in turn will serve us in solving specific domain problems.
Software development became such a big deal in our society, that ever more people are doing it and want to do it. Unfortunately, a lot of software developers (and dare I say the majority) make software development a purpose in itself, not giving the actual domain problem too much thought (or not at all in many cases). This doesn’t make any sense. How can you know your tool is actually helping?
Some might argue that software can be broken down into components, which can be independently built and then integrated at the end. Somewhat similar to a car factory. I understand the need for this mindset: it makes reasoning about things, easier. However, because of the “soft” nature of software, it is orders of magnitude easier to customize and change it than it is for car parts. This is actually the reality of software development: constant change. Still, it seems like most of the time, we build software systems that are difficult to change and maintain. Attempts have been made, to change this (e.g. XP, agile, lean, etc.), but somehow we took those ideas and turned them on their head until we ended up where we started, software difficult to change and maintain.

It’s difficult to see software as merely a tool, when there are countless hours being spent just to learn a particular programming language or operating system. There are egos at stake, personal targets, preferences. Social aspects basically. I don’t doubt similar things happen in other industries as well, but the nature of software integrates better with our capabilities. This has been observed quite some time ago already (Conway’s law).

We need to find better ways of creating and using this tool, because, let’s not forget it’s just a tool and it’s meant to make our lives better.