Latest news with #code
Forbes
4 days ago
- 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
Yahoo
18-07-2025
- Business
- Yahoo
Robinhood CEO says the majority of the company's new code is written by AI, with 'close to 100%' adoption from engineers
Robinhood CEO Vlad Tenev estimates that "a minority" of the company's new code is written by humans. On the 20VC podcast, Tenev said that it's become difficult to distinguish human-written from AI-generated code. He said the company has used tools like GitHub Copilot, Cursor, and Windsurf, and nearly 100% of his engineers use an AI editor. At Robinhood, nearly all of the engineers are vibe coders. That's according to Robinhood CEO Vlad Tenev, who said on the 20VC podcast that the company's human-written code was hard to distinguish from AI-generated code. Among the company's engineers, "close to 100%" are using AI code editors, he said. When asked what percentage of Robinhood's new code is AI-generated, Tenev said that it was around 50%. That's a higher percentage than what Microsoft and Google have previously said, with CEOs Satya Nadella and Sundar Pichai estimating around 30%. Tenev acknowledged that the 50% metric was imprecise, thanks to the upgrowth of "agentic" code editors. "We've moved from GitHub Copilot, which is an autocomplete system, to Cursor, and now things like Windsurf, where nearly all of the code is written by AI," Tenev said. "It's hard to even determine what the human-generated code is." Taking a guess, Tenev estimated the "minority" of new code at Robinhood was written by humans. Robinhood's stock price has been on a tear, trading up over 177% since the start of the year, with multiple factors driving its recent rally. Robinhood expanded its crypto venture by launching US private-stock tokens. Retail investors on Robinhood remain active, and the company continues to roll out new products like a predictions-market hub. On 20VC, Tenev said AI had contributed to the company's cost and efficiency stabilization, he said. "We have been pretty mum on how much we've been using it internally," Tenev said. "The impact that it's had on internal teams, ranging from software engineering to customer support, the really big internal teams, has been huge." Read the original article on Business Insider
Time of India
17-07-2025
- Politics
- Time of India
Min Sanjay Yadav among 4 acquitted in 2014 assembly polls MCC case
Dumka: State cabinet minister and Godda RJD MLA Sanjay Prasad Yadav, along with three others, was acquitted by a local MP-MLA court of the sub-divisional judicial magistrate (SDJM), Dumka, on Thursday in the 2014 assembly elections model code of conduct (MCC) violation case for lack of evidence. Tired of too many ads? go ad free now The accused were charged with the allegations of putting flags of their respective political parties and opening party offices at public places in violation of the MCC. The then block development officer (BDO) of Mahgama, Payal Raj, had lodged an FIR against the then RJD candidate Yadav, the then BJP candidate Raghunandan Mandal, the then JMM candidate Rajesh Mandal, and the then JVM (P) candidate Sanjiv Anand. Defence lawyer Dharmendra Yadav said, "Sections 123 and 133 of the People's Representation Act, 1951, and Section 3 of the Prevention of Damage to Public Property Act, 1984, were imposed against the four. Raghunandan Mandal had died during the course of the trial. Remaining three were acquitted by the court on Thursday as the prosecution failed to prove the case." After the verdict, Godda RJD MLA Yadav said, "Cases are often lodged out of political vendetta in politics. Around 95% of such cases are lodged falsely to settle political scores." RJD-led alliance would secure people's mandate in the upcoming Bihar assembly elections scheduled later this year, the minister said after coming out of the courtroom.
Android Authority
15-07-2025
- Android Authority
Gemini is working to clean up how it handles Canvas previews (APK teardown)
Edgar Cervantes / Android Authority TL;DR Google introduced Canvas in Gemini to aid with creating documents and editing code. So far, previewing code output in Gemini may involve transitioning over to a new Chrome tab. Gemini appears to be experimenting with a revised preview path that allows you to remain right in the Gemini app. Google has been making its case for Gemini going back well over a year at this point, and with all the new tools and upgrades its AI agent has received, at this point if you don't have a favorite Gemini feature, you're probably just not paying enough attention. One of its more powerful upgrades arrived a few months back as Gemini picked up support for Canvas, a tool that greatly enhanced Gemini's ability to create and edit documents. If Canvas is on your favorites list, too, we might have some good news for you, as we take an early look at a handy change to how we get its output. Authority Insights story on Android Authority. Discover You're reading anstory on Android Authority. Discover Authority Insights for more exclusive reports, app teardowns, leaks, and in-depth tech coverage you won't find anywhere else. An APK teardown helps predict features that may arrive on a service in the future based on work-in-progress code. However, it is possible that such predicted features may not make it to a public release. Right now, when you use Canvas in Gemini to generate some web code for you, going to preview its output pulls you away from Gemini and into a Chrome custom tab, like this: That's perfectly functional, if a little messy. Wouldn't it be much nicer if we were able to preview web code like that right from where we were in Gemini? Sure enough, looking into version of the Google Android app, we've been able to get Gemini to start exhibiting a slightly different workflow for these previews: Here, we can continue to directly interact with Gemini right from our preview, including when we go back to look at the generated source. Compared to the old flow, there's just a whole lot less jumping around, resulting in a much more pleasant mobile Canvas experience. All this still feels a bit cramped om mobile compared to the Gemini Canvas web experience, but we have to concede that this is still probably a change in the right direction. Got a tip? Talk to us! Email our staff at Email our staff at news@ . You can stay anonymous or get credit for the info, it's your choice.
Time of India
27-06-2025
- Business
- Time of India
Gabion walls planned for 12 Vishwamitri bridges to curb erosion
Vadodara: The Vadodara Municipal Corporation (VMC) will construct gabion walls around the pillars of 12 bridges on the Vishwamitri river to protect their foundations from being weakened by soil erosion. Tired of too many ads? go ad free now The initiative follows recommendations by a high-level committee formed by the state govt to suggest flood mitigation measures. Last year's floods led to erosion at several locations, even as the VMC undertook extensive re-sectioning of the riverbanks. Dredging work along the banks is also expected to cause further erosion, prompting the need for bank stabilisation efforts. To safeguard the structural integrity of bridges during future floods, the state-appointed committee recommended the construction of gabion walls around bridge pillars. These stone-filled mesh structures prevent soil erosion around the foundations, ensuring the stability and support of the pillars. The VMC will build gabion walls at 12 bridges across the city. A consultant was appointed for the project, and tenders were floated. The civic body's tender committee has finalised a contractor, approving a budget of Rs 36.7 crore — 14.13% below the estimated cost of Rs 42.74 crore. The civic body's standing committee discussed and approved the proposal on Friday, with additional conditions. One of the key conditions is that the work must comply with the Indian Standards (IS) code. "The defect liability period was initially set at three years, but it was extended to five years," said Standing Committee chairman Sheetal Mistry. Protection walls for buildings near river The Vadodara Municipal Corporation (VMC) will construct gabion walls at 12 locations along the Vishwamitri river to prevent future soil erosion from affecting buildings situated on its banks. The civic body will spend Rs 36.42 crore on these protective structures. As with the bridge-related project, the VMC's standing committee has approved the proposal with certain conditions — the work must adhere to the IS code, and the defect liability period has been set at five years.
