In the world of software development, a lot of attention is paid to how to become a competent developer. Let’s alter the pace a little and delve into things that you, as a software developer, shouldn’t do. Poor quality, terrible habits, and bad attitudes will prohibit you from becoming a great engineer.
Let’s start discussing them.
Quick Fixer
When it comes to tickets and features, John is a developer that loves to get things done as fast as possible. He has a reputation for delivering on time. A Google search is his go-to remedy for each problem he encounters.
It’s not a matter of choosing the first answer you see on Stack Overflow or somewhere else. The problem is that it’s being applied mechanically without comprehending the ramifications of doing so. In the future, applying anything without a thorough knowledge of the context might lead to further issues.
I’ve encountered a lot of folks who feel that completing their work fast will help them stand out from the crowd and be more successful. Short-term success is possible, but long-term failure is certain, as they lack thorough knowledge of the problems that they solved.
Who Needs Testing
Smith is a great programmer who loves to programme, but she hates writing tests. Because it slows down the development process and there are QAs to test the code anyhow, she says it’s not worth the effort.
Even while writing tests might be time-consuming at times, if you don’t have a safety net in place, it becomes increasingly difficult to maintain the code as complexity and needs rise. There are several reasons for this, some of which stem from a lack of interest in setting up a testing environment and others from a lack of cohesive testing knowledge.
The code will outlive your time spent working on it, and that’s a fact. This means you should double-check to make sure that it accomplishes exactly what it’s meant to do. Take the writing tests into consideration the next time you estimate a feature.
Over-engineering
Software that is easy to maintain, features that have an impact on the end-user, and excellent quality code are all things we strive towards. Developers, on the other hand, sometimes strive to come up with solutions that go well beyond the specifications. It’s a waste of time and energy to try to address issues that may never exist. Just a few examples: jumping right into micro-Service Architecture before determining whether multiple services are required, thinking about scale before even getting the first client, making everything customizable, thinking about performance optimizations before even noticing signs of delay, and many more.
Always apply the YAGNI and KISS principles when in a circumstance like this. The idea is to keep things basic and grow slowly. If anything doesn’t make sense or doesn’t seem to be necessary, leave it out.
Lone Ranger
Teamwork is something we are taught in school. In all sports, we learn how vital it is to be a team player. People in a team are considerate of one another, confer with one another before making a decision, and provide advise to one another.
Some developers like to code while wearing noise-canceling headphones. In addition, they don’t want to engage with you and they are uninterested in your activities. They are highly good at coding and completing jobs quickly. When it comes to coding and finishing things, they’re incredibly efficient. But they have a hard time connecting with people and explaining what they’re doing.
Hate Documentation
Documenting code is not considered part of the developer’s responsibilities, according to a few individuals. That’s not the case, unfortunately. Documenting the code is just as crucial as writing the code itself. Wouldn’t it be frustrating if you bought a new television and there was no instruction booklet to help you install and operate it correctly. You’ll immediately curse the company that made the television for putting you through that.
There is a huge difference between writing code and producing documentation about code. A developer can excel in one area and fail miserably in another. In general, this is the case. Not knowing how to write documentation is a drag. Because they don’t know how to code, many developers don’t enjoy writing code at all. It will take a long time to learn how to write documentation.
Everything in a single file
Methods and functions written by a person can go into the hundreds of lines of code. Honestly, there is no explanation for this. Someone like this doesn’t think about how to break down a problem and make the component methods more reusable by other classes or methods. It doesn’t have any indentations. A unified coding convention or style does not exist. Global variables were strewn throughout the place.
This is the most irksome aspect of the situation. It’s not difficult to write code, but developing decent code is a challenge. And the majority of folks don’t even bother to do that. Code reveals a lot about who you are as a person as writing clumsy code suggests that you’re also clumsy in other areas of your life. You will appreciate the process more if you take incremental efforts toward producing good code. Well-written code is a pleasure to look at.
Short-term Investor
Eat ➞ Sleep ➞ Code ➞ Deploy
Many developers live by this maxim. There is just one thing they want to do – code. Nobody wants to learn, test new frameworks/libraries, or learn about the domain. They don’t care if the feature they worked on is actually utilized by customers.
It’s for this reason that there are so many developers that get bored and exhausted of their work. There are times when it’s vital to be self-centered and learn from the jobs that you’re assigned. Read up on the technology or subject you’re interested in. Be curious about why clients dislike certain things. Identify impending tasks and features by asking questions to the product management team. Be proactive by going the additional mile.
The Dictator
To them, it’s either my way or no way. They has a strong point of view. Nearly everything is a subject of discussion for them. They have ideas and you have ideas, so it’s a battle. You have to choose between their solution and your solution. There’s a good chance there will be a disagreement. A certain element of the code that you implemented will always come up in conversation. Although it works, tests and appears to be alright, it causes them some discomfort.
He or she will be the first to buckle under strain and start pointing fingers because he or she represents a major barrier in productivity Even though he/she is an experienced/competent developer, this person is not a good fit for the team.
The “that’s not my cup of tea”
They just write codes. And because of this, they think they don’t have to write documentation. Graphic design is not one of their specialties, however. They fail to finish the papers. Someone else has to deal with the problem if it’s not a code issue. Despite the fact that there is a deadline, they refuse.
Java developers work exclusively on Java projects and nothing else. When they learn that something in the registry needs to be changed, they’ll panic. Having to enter data into a database will make them shudder. This group of people will do whatever to stay in their comfort zone and avoid being uncomfortable.
From personal experience, I can tell you that this is a regular occurrence among new developers. Exactly what a rookie developer should steer clear of! Make sure you’re ready to plunge in. The only way to learn is to get out there and do it. It is a sign of Good Developers who excel in exploration as they tend to go slowly or quickly out of their comfort zones.
Final Thoughts
As a result, learning from others’ failures is believed to be the most effective approach to progress. Thanks for reading and perhaps you’ll learn from this article on things to avoid and improve yourself as a programmer by avoiding rather than introducing something new.
Only removing what’s terrible may bring out what’s best, and sometimes that’s all it takes.
Good Luck!