Not enough to be a developer — you need to be a good one
Labelling a person as “good” or “bad” based on developer skills is too much for me. I prefer the terms “weak” and “strong”.
A strong developer solves tasks efficiently with the required quality.
A weak one — doesn’t.
There are some traits of a weak developer, which I expose in this article. But before we go on — a small disclaimer:
Anything on the internet can’t be applied to 100% of cases. Some strong developers can have a couple of traits from this article. It doesn’t make them bad developers. But most weak developers would probably have the full set of the following negative traits and something exotic in addition.
Now, let’s go to the traits of a bad software developer:
Some people are 100% sure that they know the “right” answer to everything. The sad thing is that they usually don’t have arguments or relevant experience to prove their point of view. They just think so.
Have you ever heard any of the following?
Android is better than iOS
iOS is better than Android
language X is better than language Y
framework X is better than framework Y
language or framework Z — sucks
free apps are better than paid ones or vice versa
only bad developers need tests
good developers always write tests
This list goes on and on.
Any of the above theses may be true in some situations. But usually, weak developers don’t bother too much about thinking. They take the rule and apply it the 100% of cases.
Another problem with these theses — they could be only true or false. There is no 3rd option. Polarization never helped to solve the issue. People stick to one point and take it personally if someone disagrees. It doesn’t make relationships and communication easier.
A weak developer would rather blindly follow the dogma instead of thinking and analyzing what is the best option.
Following the ideology/principle/rule without checking do they apply to reality is stupid. Even worse — it is inefficient.
Being inefficient is a trait of a weak developer.
It would be better to develop critical thinking ability. Sharp thinking is one of the most important traits of a strong developer and a smart person.
Over-engineering is a common problem for new developers. Often they do not know the most efficient way to solve a problem and try to reinvent the wheel. It is OK, in the very beginning.
But sometimes time passes, but the habit of over-engineering remains. Even experienced developers overdo it from time to time. Then it may be the red flag of a weak developer.
Classic examples of over-engineering:
Wasting time for a feature whose actual value is low. Imagine a developer who created an elegant and complex logging system for an application with 2 screens. Creating this system took more time than writing the whole application logic. This is over-engineering.
Work hard to cover all possible edge cases. This may be a wise solution if the price of error is high. Imagine you develop AI for surgery or software for space rocket launching. But in most cases application should solve the task with the required level of reliability. If a discount system in a supermarket has data collision 1 to 100,000 cases — people can live with it.
Innovations for innovations. Sometimes there is already an existing solution in the project. But a weak developer wants to launch a new library to do the same stuff in the “better” way. Or just rewrite the same logic with another set of entities and dependencies. It may be useful for a developer — he learns new and improves skills. But it isn’t so useful for the team and project.
The best code is no code
If the problem could be solved simply, then do it. Keep it simple. That is what a strong developer would do.
No clear speech — no clear mind
The way a person speaks can say a lot to the one who listens.
Definite speech means clarity of mind. Mark Twain
Mark Twain was not a software engineer, but he made many sharp and precise observations about the world. The above is one of the best.
When you write code you use the same structures of the brain as when you speak. Actually, these are the same structures used for thinking. A developer creates a solution inside the mind and then writes it down with the programming language.
Programming is the process of formalization of abstract thoughts.
What does it have with clarity of speech?
The strong engineers usually speak better than the weak ones. Strong developers can explain the idea in simple words without overcomplicating the process. Which is rare for a weak one.
The better you think, the better you speak, the better you code.
A person that constantly jumps from one topic to another would probably do the same in the code. Someone who speaks with complex and huge sentences with many clarifications will probably write similar code.
Just pay attention to the following things:
How big is the developer’s vocabulary?
How often does he correct himself?
How does he start and end phrases?
How holistic and consistent his thoughts are?
How fluent is his speech?
Does he use a lot of parasitic words?
How concise and capacious is his speech?
Like anything else, this trait is not 100% criteria of a weak developer, but the correlation is high enough to use it.
Of course, we must exclude people with some physical features such as stuttering or speech problems.
This relates to a lack of experience and conservative thinking. A weak developer will tend to solve any task with the same tool. Like a joke:
If you have a hammer in your hand, everything looks like a nail.
Often this approach is the consequence of first experiences. A weak developer used approach X in the first project, and it worked. So, now he will try to apply approach X to every other project in his life.
It may be acceptable for a new developer. But there is a problem. Such an approach blocks developers. There is no way to grow professionally if a developer always uses the same stack of technologies.
Another issue is the progress of IT field. It develops fast. There is no way to be a strong developer if you use a tech stack from 2014 in the 2022.
The main difference between weak and strong developers is efficiency. There is time and place for any tool.
The key is to understand what to use and when.
regular expressions are a powerful tool, but using them for all work with strings in the project is too much
Eclipse is a great code editor that allows you to work with Java, but Android Studio fits better for Android development
C is a wonderful language, but you shouldn’t use it for writing a website front-end, there are better languages
All of the above is not about the tool — it’s about the person who uses it. A strong developer will use appropriate tools that fit the context. A weak one will use his favorite, just because…
The above are traits of a weak developer. They are not 100% criteria, so don’t label people too early if you notice one of the above traits. Still, they are red flags of a weak developer. So pay close attention to these traits.
Feel free to correct me if I was wrong somewhere. Or share your personal point of view on the weak and strong developers.