Latest news with #RamachanderRaoThallada
Forbes
23-07-2025
- Forbes
Bad Coding Habits That Hurt Team Efficiency And Collaboration
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
Forbes
02-07-2025
- Business
- Forbes
Why Supply Chains Need A Governance, Risk And Compliance Mindset
Ramachander Rao Thallada is the Governance, Risk, and Compliance (GRC) Executive for Manulife, a modern financial institution. As the international industrial economy transitions from the age of Industry 4.0 to the more human-centered and morally driven vision of Industry 5.0, manufacturing priorities are being redefined at their core. No longer is the debate only about smart automation or data-based effectiveness. The new imperative encompasses resilience, ethics, sustainability, human-machine collaboration and most importantly, governance. Modern companies are investing heavily in digital capabilities, autonomous procurement systems, AI-based forecasting, robotic process automation and quality assurance driven through the Internet of Things (IoT). But with all this accelerated change, too many are too often missing a vital foundation: disciplined processes for governance, risk and compliance (GRC) that hold these technologies within secure, transparent and ethically responsible parameters. Learning From The Financial Industry Within the financial industry, GRC frameworks have been infused into all business layers for many years. From the process of onboarding vendors to the rollout of new technology, each step is controlled, traceable and linked to enterprise-level profiles of risk. These controls are intended not only to avoid fraud and noncompliance but also to ensure the ability of institutions to withstand shocks, be they economic, cyber, operational or any others. Manufacturing and supply chain operations, though, traditionally ran with a different mindset. Pushed by velocity, margin tension and dispersed operations, they tend to view good governance as a reactive activity—an auditing necessity rather than a proactive facilitator. Consequently, many organizations now find themselves open to disruptions that a highly integrated GRC model could either alleviate or obviate. Adopting the principles of GRC in the manufacturing process is timely and much needed. Indeed, several of the fundamental objectives of Industry 5.0 are unattainable without the help of a strong governance framework. Take the advent of AI-powered quality assurance systems. These are trained through machine learning to identify product anomalies in real time. However, if they're trained on partial data or unbalanced data and their decision-making process is opaque, they enable systemic errors that remain undetected until harm has been caused. If AI isn't subjected to proper model validation and made audit-ready—the essentials of a GRC approach—AI turns into a liability and not an asset. In the same way, blockchain technology is poised for supply chain transparency. Its decentralized ledger technology can create unalterable records of each point in the sourcing and delivery process. Its power is only as robust as the governance rules programmed into each node, though. If a single supplier in the chain is unethical, the whole chain is undermined, regardless of the technical sophistication of blockchain. This is why visionary manufacturing executives are beginning to explore the extension of GRC concepts from finance into their worlds. Such concepts—risk scoring, escalation processes, regulatory compliance mapping and ongoing monitoring—become ever more directly related to smart factories and global supply chains. Achieving The Promise Of Industry 5.0 To achieve the promise of Industry 5.0, businesses can't just deploy tools—they must instill principles as well. That involves designing principles into every layer of operation. It starts with procurement: Who signs off on vendors? How do you define ethical sourcing? Are fallback providers planned for high-risk parts? Those are questions that take more than spreadsheets and gut feeling—rule-based systems, risk dashboards and automated notifications are needed. People are governed, too. As humans and machines work increasingly in tandem, there have to be well-defined lines of responsibility. Who signs off on the end product when AI detects a discrepancy? Who takes the blame when a system makes a sourcing decision? GRC solutions provide the tools to ask and answer the questions systematically, preventing finger-pointing and confusion in high-risk settings. In addition, industry goals for sustainability—a focal point of Industry 5.0—are essentially impossible to achieve without governance. Auditable systems must verify carbon offsets, monitor the environmental, social and governance (ESG) performance of suppliers and confirm product life cycle compliance. Stakeholders no longer accept greenwashing. They demand proof, and this proof has to be produced through governed data flows. Interestingly enough, the financial industry has already shown the way. Its embrace of real-time compliance monitoring software, fraud detection AI and automated risk report systems provides the model for what's possible. Not only do these systems secure, but they also liberate. When the climate shifts, governed systems move quicker and with greater effectiveness than ad hoc systems. These same advantages hold for manufacturing. Businesses that integrate GRC into their digital core are more likely to adapt to changing tariffs, environmental policy, labor law and supply shocks. They become not only more robust but also more trusted across their partners, the government and customers. As Akash Kadam and Harshad Pitkar (download required)—mechanical engineers with a focus on manufacturing and supply chain— put it, 'Traditional supply chain models are linear in nature and siloed in operation, but always have been instrumental in meeting the demands of the marketplace. But ... globalization, customers changing requirements, and the increased speed at which technology is developing make traditional supply chains unable to respond to existing needs in an agile or resilient manner." Conclusion Ultimately, Industry 5.0 is all about advancing industrial systems to the next stage of maturity—a stage that unifies the creativity of humans and the precision of technology. But this union will fail if there's a lack of definite, enforceable standards. Governance is what turns intelligence into responsible intelligence. Now's the time for manufacturing to embrace what finance has known for years: Innovation thrives in structure, and the brightest systems are designed not only to operate but to be trusted. GRC doesn't inhibit progress—it's the future of responsible manufacturing. Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?
