There are so many articles about the skills a software engineer should have, but almost none about which skills should alert you about how bad he is. I’ve met many software developers the last ten years and I would like to share my thoughts about the kind of people I think are not bringing anything to make a company more forward.
The content of this article is subject to debate: hiring someone is a highly subjective matter.
The bad guys
The Debugger God
I’m sure you have already met him in your life. This guy can debug anything under fire. The software is failing hard in a critical mission? You can always rely on him to find out the bug with his amazing debugging skills. He knows every single feature the debugger have from conditional break points to remote debugging a production server.
He just likes to let any development on the side to fully throw all his power on debugging and fixing the critical issue your client encounters right now. It seems like he likes a lot the reward of solving an impossible bug in an big ball of mud rather than solving the real problem.
This kind of guy is especially hard to get rid of as he is usually very friendly and always willing to do more than necessary to see your clients happy. In fact, his presence is already the sign there is something wrong in your code. If you need a guy with amazing debugging skills, be prepared to pay him well: your business won’t be running anymore if he’s not here to solve the daily critical issues you are going to encounter.
This guy doesn’t want to ship quality software because he wouldn’t have anything to debug anymore. He doesn’t have any satisfaction shipping software that works fine. He likes to see your customer smile when he fixes something.
The DIY guy
A good software engineer should be able to do everything by himself. The first time I heard this sentence, I thought how impressed I would be to meet such a guy. The Do It Yourself guys loves to create new things. He has a lot of imagination. You will immediately be impressed by how many things he has already created by his own. Most of its code is driven by self-made libraries and tools to help him in his task.
He spent countless hours writing an optimized Java Web UI Generator which performs better than Google GWT. Would you hire such a guy who can create so many things by his own? I would suggest not to. Software developers should be seen as Bricklayers, not builders. Software developers should mostly assemble existing libraries together.
Now that you have hired this guy for a few months, you start to understand your mistake. He started replacing the well-documented open-source libraries by his own optimized and flawed ones. He feels like open-source libraries are doing too many things he does not need.
The DIY is not comfortable working with external libraries. If he didn’t write the code, he’s not willing to dive in it to understand how it works. He thinks it’s better to spend time creating libraries optimized for him rather than using any industry-proven standard.
The Gold digger
This kind of guy is extremely difficult to get out of the woods. He is always willing to upvote your decisions as long as he can climb in the social ladder doing so. He is extremely friendly, but don’t be fooled: he is friendly with you only if it can help him to increase his annual raise, or if it could help him reach a better position.
This kind of guy spends most of its time having small talks at the coffee machine. His purpose is absolutely not to deliver software. In fact, you know he is a poor developer because you have already reviewed some of his commits. Your manager think he is great at his work because he often claims someone else good work for himself.
Beware of the guy who always thinks like you. If you want to improve, hire someone able to contest your decisions and who understands what quality software means.
The Real-estate agent
Understand me, it’s not about buying or selling a house. But I’ve met guys who were more like a real-estate agent than a software developer, this is why I named them like this. I don’t hold grudges against people willing to completely change their life style by switching from one job to another. On the contrary I’m impressed by anyone who has the will to do this.
But, I’m talking about a bad real-estate agent who became a really bad software developer. For every single problem, he just suggested to buy software to solve the issue. When you’re a software company willing to solve an important problem with a simple solution, your future customers will be reluctant to buy you something you acquired from another company. If your company cannot bring any added value by itself, there is little reason for it to be.
He worked for a very big legacy company before moving to the startup I was working for. That should already have served as a warning to us. He was basically willing to setup a process for every single task anyone had to do. Every single communication with him had to go through a formal process and a dedicated tool. He found it way more convenient than walking a few meters to talk to each other in person.
It seems like he’s eager to put processes on everything to feel like he controls. His eaten fingers were showing evident signs of stress. He always had an example of a complicated process taken from his previous work to do simple things. It took me quite a time to figure out that all these processes were just firewalls between him and us.
Every single process was here to protect him from any responsibility he might have. This guy justs wants to cover his ass behind paper-work. He’ll never admit any error he may have made. Even worse, he loves to distract attention by applying a Divide and Conquer strategy: another way to keep a low profile.
This guy has no interest in improving your business, he just wants to have a warm secure place with minimal responsibilities and maximum income.
The copy-paste guy
If your company measures software development productivity by the number of lines being written every single day, he will outperform any people you already know. Instead of reusing software components, or refactor existing parts to meet his needs, he’ll just copy and paste the entire thing and modify a few lines to its needs. He can generate thousands of lines of code in a single of day. He just thinks it’s harmless. He thinks it would be a waste of time and risky to refactor existing code.
Needless to say that duplication is evil. Every single bug in the copied code now needs to be fixed at least twice.
The first time someone told me about him, I was really impressed: “He takes time to ship features, but when he finally ships, it’s perfect and every single corner case is handled”, told me a co-worker. Ask him to make a wooden car for your son, and you will end up with a battery powered mini-tesla with two solar panels as backup in case of battery failure. He likes to think way beyond the scope of the feature to develop. He’ll forecast needs years before they happen.
He likes to spend countless hours fixing all the small corner cases that may happen in his code. He tries to think about everything, the code he delivers is therefore very complicated because he tries to forecast the unforecastable. It would be good to have battle tested code if it wouldn’t be only tested through manual or integration tests. Don’t expect any unit test, it’s not testable due to the accidental complexity.