In my experience, each agent relies on a partially described document, which results in a loss of context and unnecessary modifications or improper changes. Eventually, this will lead to the creation of more jobs.

If you are not creating Subagents, you are missing out. Seriously, you can use them for more than just writing code. I have used them for all sorts of tasks. My dad was recently in town, and he is really into genealogical research, so I thought: "I'll bet I can create an agent to help with this." A few hours later, we have an agent who can handle many of the tedious tasks and pull all of the relevant information and sources back for his review. There are so many applications for this. Happy AI-ing... Seriously, what is the term for creating AI agents?

Clean Code is a Form of Respect Writing clean, well-structured code is not just a technical skill; it’s a form of respect towards you, your teammates and the future developers who will maintain or use your code. Sometimes, we spend 2 hours writing 10 lines of code that will save us dozens of hours later and make future development easier. Other times, we rush and write 100 lines in 10 minutes, but that often creates more problems than solutions. Here are some simple but powerful norms to follow: - Read and understand the existing code before modifying or adding a feature. Consider how your changes might impact the whole system. - Always think about a testing strategy for your code. - Peer reviews are essential. A 10-minute review can prevent 10 hours of debugging. - Provide clear documentation to make your code easy to understand. - Write code with collaboration in mind; make it simple for others to read, improve, and contribute. - Encourage collaborative reviewing within the team. These norms, along with others defined by the team, should always be respected, especially now that we often use LLM generated code. Accepting poorly structured code even once can normalize bad practices, leading us to the only painful solution later: rewriting the entire pipeline. At the end of the day, nothing is perfect. But let’s always keep the door open for improvement. #Menteva #coEnergy #Respect #CleanCode #SoftwareEngineering #CodingBestPractices

🧩 𝐓𝐡𝐞 𝐈𝐦𝐩𝐨𝐫𝐭𝐚𝐧𝐜𝐞 𝐨𝐟 𝐂𝐥𝐞𝐚𝐧 𝐂𝐨𝐝𝐞 — 𝐁𝐞𝐜𝐚𝐮𝐬𝐞 𝐑𝐞𝐚𝐝𝐚𝐛𝐢𝐥𝐢𝐭𝐲 𝐈𝐬 𝐄𝐯𝐞𝐫𝐲𝐭𝐡𝐢𝐧𝐠 ✨ Writing clean code isn’t just a good habit — it’s a 𝐩𝐫𝐨𝐟𝐞𝐬𝐬𝐢𝐨𝐧𝐚𝐥 𝐬𝐭𝐚𝐧𝐝𝐚𝐫𝐝. It’s about writing with 𝐜𝐥𝐚𝐫𝐢𝐭𝐲, 𝐩𝐮𝐫𝐩𝐨𝐬𝐞, 𝐚𝐧𝐝 𝐫𝐞𝐬𝐩𝐞𝐜𝐭 for the next person who’ll read your code. 🚀 𝐖𝐡𝐲 𝐂𝐥𝐞𝐚𝐧 𝐂𝐨𝐝𝐞 𝐌𝐚𝐭𝐭𝐞𝐫𝐬: 🧩 Future developers can easily understand your logic 🔍 Debugging and maintenance become faster 🤝 Teams work more efficiently and confidently 💡 Improves collaboration within the team 🐞 Reduces bugs and technical debt ⚙️ Enhances scalability and project lifespan #CleanCode #CodeReadability #CodingBestPractices #SoftwareDevelopment #WebDevelopment #DeveloperCommunity #ProgrammingTips #DeveloperLife #CodeQuality #TechInsights #ReadabilityMatters

𝗧𝗲𝘀𝘁𝗶𝗻𝗴 𝗶𝘀𝗻'𝘁 𝗮 𝗽𝗵𝗮𝘀𝗲 𝘁𝗵𝗮𝘁 𝗵𝗮𝗽𝗽𝗲𝗻𝘀 𝗮𝗳𝘁𝗲𝗿 𝗰𝗼𝗱𝗶𝗻𝗴, 𝗶𝘁'𝘀 𝗽𝗮𝗿𝘁 𝗼𝗳 𝗰𝗼𝗱𝗶𝗻𝗴 𝗶𝘁𝘀𝗲𝗹𝗳. Most development teams follow the same broken pattern: build for weeks, then frantically test everything at once before the deadline. The result? Panic, shortcuts, and bugs that slip through. The alternative is incremental testing: every small piece you build gets tested immediately, while the context is fresh and changes are small enough to debug quickly. Why this works: → 𝗙𝗮𝘀𝘁𝗲𝗿 𝗱𝗲𝗯𝘂𝗴𝗴𝗶𝗻𝗴 (you know exactly what broke) → 𝗕𝗲𝘁𝘁𝗲𝗿 𝗰𝗼𝗱𝗲 𝗾𝘂𝗮𝗹𝗶𝘁𝘆 (forces modular, testable code) → 𝗟𝗲𝘀𝘀 𝘁𝗲𝗰𝗵𝗻𝗶𝗰𝗮𝗹 𝗱𝗲𝗯𝘁 (issues caught when small) → 𝗖𝗼𝗻𝗳𝗶𝗱𝗲𝗻𝗰𝗲 𝗮𝘁 𝗲𝘃𝗲𝗿𝘆 𝘀𝘁𝗲𝗽 (solid foundation) The traditional "code everything then test everything" approach creates artificial bottlenecks and compounds complexity. When you test as you build, you're building better architecture and developing stronger debugging instincts. Your next feature is an opportunity to try this approach. Break it down, build incrementally, test each piece as you go. Read the full guide on implementing this workflow: https://lnkd.in/dsZW_uTH #SoftwareDevelopment #Testing #BestPractices #TechnicalDebt

This is the approach we've been using to build Bugster itself. Test as you code, not after. It's faster, less stressful, and produces better software. The "I'll test at the end" mindset is how technical debt compounds into architectural problems.

From Code to Product: What Most Engineers Forget When I was a junior developer, I thought writing clean, elegant code was the ultimate goal. Perfect indentation, zero lint errors, 100% test coverage — I was obsessed. But over time, I learned something humbling:   “No one cares about your code if it doesn’t solve the right problem.” Once you start meeting with C-level or customers or business team, you’ll hear common words: “Well, I don’t understand technical stuff but how to achieve the goal?” Clean code is a tool, not the destination. The destination is “impact” So next time you open your editor, remember: You’re not just coding — you’re building something that matters. #softwareEngineering

When you’ve got 15 developers on a single project, code reviews can quickly become impossible for any tech lead something’s always going to slip through the cracks, and those little misses usually show up as big headaches later. That’s why I started using CodeRabbit, and honestly, it’s a game-changer especially now with the new AI-powered version. Here’s what makes it stand out for me: It does production-ready code reviews that go way beyond basic linting. Flags missing tests, inconsistent imports, and subtle security risks the sort of stuff only a senior developer would catch. The feedback is context-aware and meaningful for our repo, not just some generic “fix this” advice. Lets me set and enforce our team’s coding standards and boilerplates so everyone follows a consistent approach. Nobody escapes the rules now! And here’s the kicker: for the vibe coders the ones who thrive on creativity and collaboration this tool fits today’s workflow perfectly. It keeps quality high while freeing the team to experiment, contribute ideas, and push boundaries confidently. Even with all my years of coding, I haven’t written detailed code in a while. CodeRabbit actually makes code reviews fun for me again and gives back feedback that feels genuinely useful. For the record, I’m not in the habit of recommending tools lightly. If I’m talking about CodeRabbit, it’s because my team and I actually use it (and yes, all three of my LinkedIn readers can vouch for that). For me, it’s like having an extra senior engineer watching every pull request one who never gets tired and always catches the small stuff.

Who enjoys code reviews? It’s always fully cringy having your code assessed. Firstly does it work? Have tests been written for it? There are some conformities with formatting, using efficient functions and expressions, naming conventions etc that you might get lazy with if no one is looking. But is it “bad”? There is often a lot of tacit knowledge in engineering teams which design patterns have been used any specific standards or conformities that are applied. These should be documented but often aren’t and who reads documents anyway? Code reviews also need to be undertaken early enough in the development process. Leaving this until last is asking for trouble. Not always having the same people taking on reviewing tasks, for their sanity and productivity. But also because it is good to take reviews from other engineers fresh eyes spot different problems. They also have different biases. Human reviewers should not be doing anything that can be automated. The potential scope of code reviews is frankly huge. You need to be as efficient as possible. Putting parameters around that is important. For everyone who has that dreaded the code review there is a reviewer who is hating that context switch.. Doing everything you can to limit the feedback and meet an agreed standard in your engineering team makes a more productive environment for everyone. Something which sounds simple often has a lot of context and nuance. Code quality is the bedrock of scaling your solution. It might be cringy but you can’t avoid it. #softwareengineering #cto

Code Reviews: Real-World Examples 🤓 After discussing the code-centric approach, let's see how it plays out in actual code reviews.  The Scenario Below some possible code review examples. Same code, two different review styles—wildly different outcomes. ❌ Non-Code-centric approach - Creates defensiveness – The author feels attacked rather than supported - Lack of explanation – No context for why something is considered wrong - Doesn't acknowledge multiple valid approaches may exist – Presents opinion as absolute truth 🎯 Result: The PR author becomes reluctant to contribute, team morale drops, and knowledge sharing stops. ✅ Code-centric approach - Uses neutral and objective language  - Focuses on code quality, not personal judgment - Considers different implementation options – Recognizes there are multiple paths to a solution - Expresses genuine interest in the technical decision – Shows curiosity about the reasoning - Invites explanation without presuming error – Creates space for learning in both directions 🎯 Result: Collaborative discussion, knowledge transfer, and a better solution emerges from the conversation. The Real Difference Notice how a code-centric review transforms a potential conflict into a learning opportunity. The reviewer treats the PR as a conversation, not a checklist—turning every review into an opportunity for mutual learning. 👉 Next Up: Key principles and actionable takeaways for your team. #CodeReview #Engineering #DeveloperExperience #SoftSkills #WebEngineering #WebDevelopment --- I post about web engineering, front-end and soft skills in development. Follow me here: Irene Tomaini