What Are the Characteristics of a Bad Software Engineer?
In the quest to uncover the traits that hinder a software engineer’s effectiveness, we’ve gathered thirteen insights from industry leaders, including CEOs and Founders. From the pitfalls of disregarding the Importance of documentation to the oversight of ignoring user empathy, these seasoned professionals shed light on what to avoid in the engineering field.
- Disregards the Importance of Documentation
- Shows a Lack of Inquisitiveness
- Lacks Humility in Engineering
- Overlooks Crucial Details
- Neglects Adequate Documentation
- Shortsighted in System Design
- Complicates Solutions Unnecessarily
- Curiosity Deficit in Engineering
- Avoids Professional Contracts
- Habitually Misses Deadlines
- Writes Unreadable Code
- Withholds Seeking Feedback
- Ignores User Empathy
Disregards the Importance of Documentation
No software engineer is so good that they can submit code with little to no documentation. It’s these comments that make software viable for the long-term future. Engineers who refuse to document are saying, “My code is so great that it’s immediately understandable to anyone who reads it.” This implies that anyone who needs help understanding the code is insufficiently trained or experienced.
In reality, everyone has their perspective and way of understanding the world, which includes software engineering. People can be trained to learn documentation, but anyone who refuses to learn is a poor engineer, regardless of how well they can write computer code.
Mark Varnas, Principal SQL Server DBA and Consultant, Red9
Shows a Lack of Inquisitiveness
Sometimes, talented software engineers think they know best, so they don’t bother asking questions, such as “Why are we building this feature?” and “What problems are we solving for our users?”
This leads to them building what they thought they needed instead of what the users actually need. I’d hire an inquisitive junior developer over a more experienced one who doesn’t ask questions 10 out of 10 times.
Justin Silverman, Founder and CEO, Merchynt
Lacks Humility in Engineering
Bad software engineers are ones who lack humility. It is important to be humble, as humility leads to better conversations with customers, both internal and external alike. It also leads to programmers who are more open to learning different ways to do a task, whether this means learning a new algorithm, a new software language or framework, or using a new tool, like GitHub Copilot.
David Wachs, Founder and CEO, Handwrytten
Overlooks Crucial Details
I’m not technical, but I am a co-founder of a software company. I’m intimately familiar with what a ‘bad’ software engineer looks like. A major characteristic of a bad software engineer is a lack of attention to detail.
Software development requires precision, and seemingly small mistakes or oversights can lead to significant issues with functionality, performance, and security. A software engineer who consistently overlooks details, whether it’s in code implementation, design aspects, documentation, or testing, can contribute to producing unreliable and error-prone software.
This leads to longer development cycles, more bugs, and unhappy customers. Obviously, those are things you want to avoid.
Daniel Ndukwu, CMO and Co-Founder, DoxFlowy
Neglects Adequate Documentation
One thing a below-average software engineer does, besides writing inefficient code, is not providing adequate documentation. This has a knock-on effect on all other areas of the development project: testing, debugging, maintaining, and upgrading the software becomes difficult.
Proper documentation also ensures the right knowledge transfer, and backtracking adherence to certain standards is possible. One might be better off working with a junior developer who is diligent at documenting his work as opposed to a senior software engineer who is focused on delivering code without caring about documentation.
Hristina Stefanova, Senior Marketing Manager, Blue Tea Software
Shortsighted in System Design
A bad software engineer often lacks foresight. They’re like an elephant charging backward, blind to what lies ahead and the chaos they’re causing. I’ve seen developers who don’t think ahead at all, whether it’s in designing a database, planning system components, or even fixing minor bugs.
They fail to consider the consequences of their actions. This shortsightedness can be particularly harmful in large, complex systems. Although risks can be reduced with code reviews, automated testing, and staging environments, these aren’t complete solutions.
Engineers who make changes or create new features without understanding the long-term effects, or who fail to plan for the future, end up causing major problems for themselves and others.
Lucas Ochoa, Founder and CEO, Automat
Complicates Solutions Unnecessarily
One characteristic of a bad software engineer is the tendency to over-complicate solutions. This isn’t just a technical issue; it’s a soft-skill gap that directly impacts project completion. In our work at RoverPass, I always emphasize the importance of engineers who bring solutions, not just problems.
Imagine a scenario: a project that should take three months ends up taking six due to overly complex solutions. This delay can cascade, affecting product launches, marketing strategies, and customer satisfaction.
In a fast-paced industry, such a delay could potentially cost millions in lost opportunities and revenue. Engineers who can simplify processes and solve problems efficiently are invaluable; those who can’t may inadvertently cause significant financial setbacks.
Ravi Parikh, Founder and CEO, RoverPass
Curiosity Deficit in Engineering
There are a ton of little practices that I personally found to be bad practices when I was a software engineer, but if I had to put my finger on what the single worst one would be, then I’d say a lack of curiosity.
Software engineers need to WANT to know more, learn more, and tinker as much as possible because that’s how you put together the best possible pieces of work.
Just making sure something works and meets the basic criteria is fine, but if that’s all you’re bringing to the table, I don’t think it makes you stand out amongst your peers.
Dragos Badea, CEO, Yarooms
Avoids Professional Contracts
If a software engineer refuses to enter into legal contracts, it’s a red flag. Contracts are crucial—they set clear terms for the work, protecting both the client and the engineer.
By not committing to a contract, an engineer not only shows a disregard for professional standards but also opens the door to potential scams.
Without a contract, there’s nothing to enforce accountability or to fall back on if things go awry, which can severely damage the trust essential for any business engagement.
Alex Freeburg, Owner, Freeburg Law
Habitually Misses Deadlines
In my experience, a bad software engineer often misses deadlines. They can be procrastinators who habitually fail to meet their deliverables. They might not have the right skills or enough experience, which means they can’t finish projects when they’re supposed to.
This can annoy the rest of the team and the people who need the project done. It could even make the company lose money. This happens because not meeting deadlines can delay other parts of a project or upset clients. Plus, it might mean the team has to rush to finish things, which can lead to more mistakes.
Alan Redondo, Founder, Ardoz Digital
Writes Unreadable Code
The biggest sign of a bad software engineer is one who writes ugly code that’s almost impossible for future engineers to read.
A bad engineer will have variables named x, flag, arr, and str, and there will be no indentation whatsoever. They’ll also have no consistent coding style, with global variables spewed everywhere.
I actually did an interview with a software engineer who wrote code like this, and he literally told me, “But my code works, doesn’t it?”
This is a massive red flag, and if you’re hiring a software engineer, avoid anyone who writes ugly code. It shows that they don’t care about their work and are just doing the bare minimum.
Scott Lieberman, Owner, Touchdown Money
Withholds Seeking Feedback
Software engineers are like prolific authors. There is a constant need to submit first drafts and get feedback as quickly as possible. I have seen many poor-fit engineers hold onto tasks for a very long time, only to realize that the critical feedback they needed would’ve been useful earlier in the process. Good software engineers submit daily code changes for review, and they embrace the feedback, both positive and negative.
Trevor Ewen, COO, QBench
Ignores User Empathy
One characteristic that raises significant concern when evaluating a software engineer is a lack of empathy for users.
A few months ago, we were in the process of hiring an engineer to develop a custom CRM platform for our team. This applicant came highly recommended, with an impressive track record. However, during the interview process, when I asked, “How do you ensure ease of access for users?” His response left me concerned.
His portfolio of sample projects lacked the user-centric approach we value. It seemed as though he prioritized technical prowess over the end users’ experience. When I questioned him further, his answers reinforced this impression.
Our team, which includes individuals with varying levels of tech expertise, relies on intuitive interfaces and user-friendly design.
We needed an engineer who not only possessed technical skills but also understood the importance of creating software that caters to users’ needs and abilities.
Laia Quintana, Head of Marketing and Sales, TeamUp
Related Articles:
- What Are Must-Read Books for Software Engineers?
- 10 Ways to Prepare for a Software Engineering Job Interview
