Characteristics of a Bad Software Engineer

There is a lot of fuss around becoming good developers, a lot of articles aruond traits of great engineers, tasks of senior engineers, and all the goody-goody things. Let’s change the pace a little bit and dig into things that you should NOT do as a software engineer. Qualities that are categorized as bad, and mindsets that will prevent you from being a better engineer.

Let’s begin.

The Quick Fixer

Adam is a developer who likes to deliver tickets and features quickly. He is well known to deliver things on tight deadlines. Whenever he is stuck, he does a quick Google search and applies the first solution that he finds.

The problem here is not about picking up the first solution from Stack Overflow or any place else. The problem is the mechanical application of it without understanding the consequences. Applying something without fully understanding the context can lead to more problems in the future.

More often than not, I have seen people believe that quickly finishing the tasks will help them outshine others. They might be able to impress in the short term but in the long run, they fail miserably, as they don’t have a deep understanding of the problems they have solved.

The “who needs testing”

Silvia is a wonderful developer and enjoys programming a lot, but one thing that she really hates is writing tests. According to her, it reduces the speed of development, and there are QAs to test the code anyway, why bother.

Writing tests can be cumbersome sometimes, but with increased complexity and ever-changing requirements, if you do not have a safety net, then it becomes much harder to maintain the code. Part of it comes from lacking the interest to set up a testing environment and partly from a lack of coherent knowledge of testing.

The code is going to outlive your time working on it. You should make sure that it does what it is supposed to do, nothing more and nothing less. Make sure next time you estimate a feature, you take the writing tests into account.

The Over-engineer

We all want to write good quality code, features that have an impact on the end-user, and software that is maintainable. But sometimes developers try to create solutions that are far beyond the requirements. Trying to solve the problems that might not even occur. Few examples are going straight into a micro-service architecture without even understanding the system boundaries, or whether multiple services are required, thinking about scale even before getting the first client, trying to make everything configurable, thinking about performance optimizations even before seeing signs of latency, etc.

Whenever stuck in a situation like this, always follow YAGNI and KISS principles. It essentially means that you should keep things simple and build gradually and if you think something is not needed just skip it.

The Lone Ranger

Being a team player is something that is taught to us in school. All sports teach us why being a team player is important. In a team, you think of others, consult others before deciding on an approach, you give advice to fellow teammates.

There are developers that just like to put their headphones on with noise cancellation on and code. They don’t want to interact with you, and they are not interested in what you are doing. They are very efficient with coding and finishing tasks. But they are equally bad at interacting and explaining their work to others.

The “I hate documentation”

Some people believe that code documentation is not part of their job description as a developer. Well, that is not the case. Writing documentation of the code is as important as writing code. If you bought a new Television and there is no manual to install the TV and operate it correctly, how would you feel. You will instantly curse the company who made the Television.

Writing code and writing documentation about the code are two separate and very different things. A developer can be very good at one and very bad at the other. That is generally the case. Writing documentation is boring when you don’t know how to do that. Which is the case for many developers who don’t like writing code because they don’t know how to write code. Learning to write documentation will take a long way.

The “everything in one file”

This person writes methods and functions that are pages long. There is really no excuse for this. This person never thinks about breaking down the problem and making the individual methods more reusable by other classes or methods. There is no indentation. There is no consistent coding convention or style. Global variables spewed all over the place, etc.

This is the most annoying thing for me personally. Writing code is not hard but writing good code is hard. And most people just don’t even try that. The code that you write says a lot about your personality. If you write clumsy code, probably, you are clumsy with other things as well. But if you start taking smaller steps towards writing good code, that will become a habit, and you will enjoy the process. It just feels so nice to look at well-written code.

The short-term investor

Eat ➞ Sleep ➞ Code ➞ Deploy

The motto of so many developers. They just want to code. They don’t want to learn, they don’t wish to try some new framework/library, have no interest in the domain, they don’t care if the feature they worked on is actually being used by customers.

This is why there are so many developers who get tired and bored. Sometimes, it’s important that you become selfish and learn from the tasks that are given to you. Take some time to read about the tech or the domain. Show some interest to understand why customers are not liking some features. Ask questions to the product managers to get an understanding of upcoming tasks and features. Take that extra step and be proactive.

The Dictator

My way or the highway is their motto. Highly opinionated. They have opinions about almost everything. It’s their ideas vs your ideas. It’s their solution vs your solution. I bet there will be an argument for sure. Somehow they will keep coming back to a part of the code that you implemented. It somehow discomforts them even if it works, tests, and looks perfectly fine.

This person is a big bottleneck to productivity and will be the first person to crumble under pressure and start pointing fingers. This person is not good for the team, however, experienced/good developer he/she may be.

The “that’s not my cup of tea”

They write code. They don’t write documentation. They don’t do graphic design. They don’t finish the paperwork. If it’s not code, it’s someone else’s problem. They won’t do it, even when there’s a deadline.

The Java developer just does not work on anything that is not Java. They will panic on learning that something in the registry needs changing. They will cringe at having to input things in the database. These people will do anything to avoid getting out of their comfort zone.

I have learned, from personal experience, that this phenomenon is common with new developers. And that’s exactly something that a new developer should avoid. Be ready to jump in. You will only learn when you do things. Good developers show a tendency to slowly/swiftly move out of their comfort zone in exploration.

Final Thoughts

Learning from the mistakes of others is considered the best way to grow. I hope this article will help you realize the things that you should avoid and help you become a better developer by negating instead of adding something new.

Sometimes all you need to do is remove the bad and the good automatically shines out.

Thanks for reading!