Bad Coding Habits That Hurt Team Efficiency And Collaboration

Forbes

4 days ago

In the fast-paced world of development, clarity is key—but many developers fall into habits that obscure their code and make life difficult for their teammates. Writing good code isn't just about getting it to work; it's about making it maintainable, readable and clean.
From vague comments and tangled logic to pull requests that try to do too much at once, code that only makes sense to its original author isn't sustainable. Below, members of Forbes Technology Council share common bad habits developers fall into—and what they should be doing instead to write cleaner, more team-friendly code.
1. Logging Inconsistently
One bad habit developers fall into is following poor logging practices like vague, inconsistent logging statements. This makes it incredibly difficult for fellow developers to debug efficiently. Fix it with practices like providing contextual information. - Ramachander Rao Thallada, Manulife
2. Overengineering Code
One bad habit developers fall into is overengineering, which complicates code unnecessarily and adds features with no real value. Instead, they should focus on creating flexible solutions that align with business goals, ensuring the code is understandable and maintainable for fellow developers. - Andrey Kozyrskiy, Specific-Group
Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?
3. Clinging To Personally Preferred Tools And Languages
Something I've seen holding teams back is individuals clinging to their preferred tools, programming languages or styles over seeking the tools and processes that are most applicable to all. Languages and frameworks are just tools in your toolbox; real engineering is about curiosity and problem-solving. When teams embrace that, it's easier to align on what works best for the organization and engineering pace at each stage. - Eva Nahari, Vectara
4. Skipping Pseudocode And Inline Comments
Pseudocode, pseudocode, pseudocode. Pseudocode helps you plan your code's logic before you write it, acting like a detailed blueprint. Comments within your code explain the purpose and how it works for anyone reading it. Together, they make your code clearer, easier to understand and simpler to maintain by others. - Vasanth Mudavatu, Dell Technologies
5. Withholding Descriptions
When companies value knowledge as power over shared learning, developers find it useful to leave out descriptions of what they have done. A developer often comes to hold the belief that if they are the only one who can figure out their code, they will hold onto their job. - Laureen Knudsen, Empower Consultant Group
6. Making Code Too Abstract Too Soon
We're so heavily trained in college to build extensible, reusable code that we fall into the bad habit of overcomplicating code by making it too abstract too soon. I encourage my team to strike a good balance between concreteness and abstraction. For example, inheritance should be used carefully, not assumed as the default. DRY is great, but clarity matters more; repetition is okay using IDEs with AI. - Gabriel Labrada, Process Street
7. Writing 'Clever' Code
One bad habit is writing 'clever' code that no one else can understand. This is a classic case of misplaced confidence, making the code brittle and hard to maintain. Instead, prioritize clarity over cleverness. Code is read far more than it's written. True seniority is shown by writing simple, explicit code that empowers your teammates. - Marcin Nowak, Decerto
8. Prioritizing Conciseness Over Clarity
One common pitfall is prioritizing conciseness over clarity—writing overly compact or tightly packed code that's difficult to read or maintain. While it may function well, it creates friction for others. Instead, developers should favor clear, well-documented code with intuitive structure, making collaboration and future updates significantly smoother. - Shrushti Kenekar, Global Partners
9. Relying Too Heavily On Patching
Developers often engage in patch coding, where they fix issues as they arise without considering scalability, reusability and long-term maintenance. Instead of focusing on short-term solutions, ask questions about requirements, identify potential for reuse, and adopt pattern-based thinking. These strategies can help reduce technical debt and ease future upkeep. Vibe coding will address this problem soon! - Buyan Thyagarajan, Eigen X
10. Creating Oversized Pull Requests
One bad habit is pushing a large number of changes (lines of code and files changed) into one pull request. It is convenient for the developer writing the code to do this because it reduces the number of change iterations and test cycles. However, for the peers reviewing the pull request (and eventually when releasing the code), it's a nightmare to actually review the code meaningfully or debug when there's a failure. - Madhuri Sesha Sarma, Carta Inc.
11. Skipping Structure And Functional Clarity
While doing code reviews, I have often noticed devs failing to outline what the code does and its functionality, as well as not maintaining consistency with established patterns. Decoupling functional from nonfunctional code, implementing modular design, organizing the structure, and aligning with defined enterprise standards will make it easier for anyone reviewing or trying to understand the code. - Ugandhar Dasi, T-Mobile US
12. Writing Without Comments
One bad habit is writing code without comments or meaningful naming. It forces others to waste time deciphering logic. Instead, devs should use clear, descriptive names and concise comments to explain why (not just what) the code does. This makes collaboration and maintenance much easier. - Roshan Mahant, LaunchIT Corp.
13. Coding In Isolation
One bad habit is coding in isolation, focusing only on what works rather than on how others will build on it. This leads to brittle, opaque systems that are hard to scale or maintain. Developers should think like system designers, not just problem solvers. Clear structure, contextual comments and consistent patterns turn code into a durable asset instead of a liability. - Satpreet Singh, Pinnacle Digital Advisors
14. Tightly Coupling Logic With UI Or Infrastructure
With years in engineering, I have seen devs tightly couple logic with UI or infrastructure, making reuse and testing painful. Instead, they should design code with separation in mind so it is easier to extend, mock and hand off across teams without breaking everything. - Gopinath Kathiresan, Apple Inc.
15. Leaving Cryptic Or Outdated Comments
One bad habit? Leaving cryptic comments like '// temporary fix' … from 2017. Instead, write clear, intent-driven comments and meaningful commit messages. Code is read more than it's written—treat it like a message in a bottle to your future teammates (and your sleep-deprived future self). - Sumit Bhatnagar
16. Using Hardcoded Values Or Ignoring Design Tokens
Front-end devs using hardcoded values or ignoring design tokens make it harder for others to understand, update or extend the code. It forces extra guesswork and risks inconsistency. Instead, stick to shared design variables, as this keeps the codebase clear, scalable and aligned with the design system. - Aishwarya Suresh, Medtronic Inc.
17. Skipping Branch Strategy And Clear Commit Messages
Skipping a clear branch strategy and writing vague commit messages causes major headaches during debugging and deployment. Without consistent naming conventions (like feature/ or hotfix/) or a defined model such as trunk-based development or GitFlow, CI/CD quickly becomes messy. Use clear branch names and descriptive commit messages to make reviews, merges and issue tracing much easier for everyone. - Jae Lee, MBLM
18. Failing To Document Design Decisions
Sometimes the rationale for tricky design decisions is lost. Devs rely on verbal handoffs or assume that everyone on the team knows the context. Design decisions should be captured in design docs and decision logs so that future devs can see the 'why,' not just the 'what.' - Amy Gu, Dynamsoft
19. Writing For Machines, Not Humans
A bad habit is writing code for machines, not humans, using clever shortcuts with no context. Instead, devs should treat code like a shared language that is clear, modular and self-documenting. Bonus move: Tokenize contributions so those who write the most valuable code build equity in the platform they help create. There is true value in competent participation. - Charles Morey, MobilEyes Inc.
20. Having Poor (Or Missing) Documentation And Logging
Too many devs write cryptic code with poor documentation and bad logging (missing context, wrong levels or no logs at all)—making debugging a nightmare. Here's what to do instead: Use descriptive names, explain decisions in comments and log key events with proper context (user ID, request ID, error details and so on) to swiftly identify and resolve issues. Code should be readable; logs should tell the story. - Uttam Kumar, American Eagle Outfitters