Jose Roca’s Post

I’ve noticed that engineers often struggle with creating and reviewing pull requests in a way that balances speed, quality, and collaboration. Pull requests are more than just a step before merging code—they’re a powerful opportunity to improve code quality, share knowledge, and catch bugs early. Here are some best practices to elevate your pull request process: Keep pull requests small and focused. Smaller PRs are easier to review thoroughly and get merged faster. Write clear titles and descriptions. Explain what changed, why, and any context reviewers need to understand your changes. Review your own code first. Catch simple mistakes and clarify your intent before others spend time reviewing. Be timely and respectful in code reviews. Avoid bottlenecks by reviewing promptly and giving constructive feedback. Use tools for automated checks. Linters, tests, and security scanners integrated into PRs can catch issues early. Communicate openly. Share what kind of feedback you need—is it a quick check or deep architectural input? When done well, pull requests foster collaboration, reduce bugs, and make deployments smoother.

If you had just one question to assess the quality of a software engineering team, what would you ask? Mine would undoubtedly be: 𝗵𝗼𝘄 𝗼𝗳𝘁𝗲𝗻 𝗱𝗼 𝘆𝗼𝘂 𝗱𝗲𝗽𝗹𝗼𝘆 𝗰𝗼𝗱𝗲 𝘁𝗼 𝗽𝗿𝗼𝗱𝘂𝗰𝘁𝗶𝗼𝗻? ⬇️ ⬇️ ⬇️ There are dozens of metrics you can calculate and combine, but deployment frequency is the fundamental one. A team can only deploy frequently if: - It regularly has releasable work - It's confident in making a release - The release process is fast In other words: - The team can break down monolithic tasks into smaller, self-contained units and complete them quickly. This means the product has a solid architecture that ensures low complexity and minimal dependencies. There's the analytical capability to decompose problems. The team can complete small tasks at a high pace. - The project has good test coverage and other automated quality and security checks. - There are automated release pipelines that don't require human intervention. A single metric helps us understand all of this, simple and elegant. And for those who are never satisfied, we could even raise the bar and ask: 𝗵𝗼𝘄 𝗼𝗳𝘁𝗲𝗻 𝗱𝗼𝗲𝘀 𝘁𝗵𝗲 𝘁𝗲𝗮𝗺 𝗱𝗲𝗹𝗶𝘃𝗲𝗿 𝘃𝗮𝗹𝘂𝗲 𝘁𝗼 𝘁𝗵𝗲 𝗰𝘂𝘀𝘁𝗼𝗺𝗲𝗿? This is certainly an even more comprehensive question, as it captures the difference between speed and velocity, but it's much harder to measure. If you have a simple way to do it, I'm all ears!

The biggest slowdown in engineering isn’t code. It’s confusion. Most teams focus on code-level performance. They optimize loops, reduce API calls, and measure load times. But the real bottleneck is not inside the CPU. It is inside the developer’s mind. Every time a developer pauses to ask: - "Where is this function defined?" - "Which branch should I push to?" - "Why does this component behave differently?" That pause is cognitive load. These small interruptions might seem harmless, but over time they slow entire teams down. I have seen developers spend more time recalling how things work than actually building new features. Here are a few real-life situations: - A project had different folder structures for each module. Every new developer had to relearn the layout before making any change. - Another team used inconsistent naming patterns. Engineers kept opening files to confirm what a function actually did. - One company used too many disconnected tools. People spent hours switching between Jira, Slack, Notion, and Confluence instead of focusing on real work. When you look closely, you realize performance is not only about faster code. It is about faster thinking. Reducing cognitive load creates flow. It allows engineers to spend their energy on solving problems instead of remembering details. Clean architecture, consistent patterns, and clear documentation are not luxuries. They are mental optimizations that make teams faster and happier. Fast teams think clearly first. They code fast second. 💬 How do you reduce cognitive load in your team’s workflow? #SoftwareEngineering #CognitiveLoad #DeveloperExperience #TeamProductivity #CleanCode #Leadership #EngineeringCulture #SoftwareDesign

Part 7 – Dev Fatigue (Series: The Engineering Impact of a Leaky Change Process) Developers don’t burn out from code. They burn out from friction. Unstable Priorities: Every sprint starts with shifting goals. Developers re-open completed work, re-build features, and lose flow. Productivity drops while delivery pressure rises. Incomplete Inputs: Stories arrive without acceptance criteria, dependencies stay un-mapped, and upstream decisions reach the team mid-implementation. Context switching becomes the default. Constant Interruptions: Teams balance code reviews, hotfixes, and new requests simultaneously. Focus fragments, quality suffers, and “quick fixes” multiply. Erosion of Ownership: When direction keeps changing, developers stop solving problems creatively and start following instructions mechanically. Morale dips; technical debt grows. How to Stabilize the System: • Lock Scope: Freeze sprint priorities once work begins. • Clarify Inputs: Refine user stories and dependencies before backlog commitment. • Protect Focus: Define uninterrupted build windows each day. • Close Feedback Loops: Share decisions where work happens, not in scattered chats. A predictable process is the best mental-health policy in engineering. Stability restores confidence, and confident engineers build better software. Follow Adeyinka Badmus for grounded reflections on delivery life. Follow MABY Consultancy for simplified technical insights.

Why do so many engineers, despite knowing the “best practices,” struggle to apply them? Most engineers today know what clean code means. They know why tests matter. They know version control etiquette, CI/CD, design principles, documentation hygiene… Yet when you look at the actual work, it’s full of shortcuts, inconsistency, and “I will fix it later” decisions that never get fixed. It’s not a knowledge gap. It’s a mindset gap. Many engineers operate in delivery survival mode. The focus quietly shifts from craftsmanship to completion. Leaders reward speed, so engineers prioritize velocity over sustainability. Soon, best practices turn into interview vocabulary rather than working habits. Leaders often say “quality matters,” but few build environments where it’s visible, measurable, and valued daily. We still celebrate quick deliveries far more than disciplined ones. Over time, this creates a silent tradeoff: do it fast now, fix it later. But “later” rarely comes. The fix isn’t another checklist; it’s about engineering the environment, not reminding people. What works well: -- Encourage engineers to explain why, not just what’s wrong (in code reviews, retros, etc). -- Spread good habits daily and organically (TDD, pairing, etc) -- Focus on how we built, not just what we shipped. -- Visible quality SDLC metrics, refactoring effort, test coverage trends, and learnability scores (on topics like AI, XP, teamwork). -- Independent engineering reviews. A neutral technical expert every sprint to assess code health and discipline. Their outside view resets the integrity bar before it slips too far. The goal isn’t to make engineers follow best practices. It’s to create a culture where best practices are simply how things get done. #EngineeringCulture #TechLeadership #AIinSoftwareDelivery

Anyone can write code that works. Great engineers write code that keeps working — even when the system grows, changes, or fails unexpectedly. 🧩 The difference? Anticipation. Top engineers: • Think in failure scenarios before success stories 💥 • Design APIs that are hard to misuse 🔒 • Question assumptions — “What if this input is null?” • Build monitoring, not just features 📈 That mindset turns a developer into a solution architect — someone who doesn’t just solve problems, but prevents them. 💬 Question for you: What’s one “defensive design” habit you follow that saved you from a major issue later? #SoftwareEngineering #SolutionArchitecture #CleanCode #Scalability #Resilience #EngineeringMindset

I’ve developed a strange skill over the years. I can tell how your system is built without opening your codebase… Conway’s Law basically says this: the way teams are structured ends up shaping the way systems are built. In my roles as CTO or VP Engineering, I’ve seen it again and again. A few concrete examples I’ve come across: • A frontend and backend split into separate services (one team for each), even though a monolith would have been simpler and easier to maintain. • Two backend services built with completely different frameworks, just because each team picked “their own,” without any real technical justification. • In one company I worked with, there was a public API for the customers, but two different teams managed different parts of it. Each had its own approach to documentation, so clients could clearly see the inconsistencies. In each of these cases, the software wasn’t designed around what made the most sense technically or for the business. It was designed around team boundaries. Over time, I’ve found a few practices that help soften that bias: • Full-stack, T-shaped engineers often bring a broader technical knowledge, which makes them more likely to think holistically rather than from a narrow team perspective. • Engineers with a strong product mindset can step back from the code and ask: why are we building this, and what impact will it have on the end-user? • Teams that aren’t locked into rigid compositions give us more freedom. If team boundaries are flexible, system design can adapt to what’s most effective, rather than simply mirroring the org chart. • And when teams are oriented around business goals rather than a fixed technical scope, it naturally pushes the architecture to align with outcomes instead of silos. In my experience, the best architectures emerge when we give people the room to look beyond their immediate scope and keep the bigger picture in mind. What’s the strangest Conway-shaped architecture you’ve seen? 👀

Here's what actually separates $100K engineers from $250K+ engineers: It's not LeetCode. It's not knowing every design pattern. It's not working 80-hour weeks. It's this: The ability to turn hard ambiguous problems into executable plans. Let me explain: The more skilled you are, the more general the direction you can take and succeed. The less skilled you are, the more specific the directions must be. So if you’re stuck, it means you don’t understand something. The $250k+ engineers know this very well. They thrive in complete ambiguity! They take a vague business problem and turn it into: • A clear technical strategy • Defined milestones and metrics • Risk assessment and mitigation • Buy-in from stakeholders Here's the framework I use: 1. Clarify the actual problem Don't start with solutions. Ask why this matters to the business. Most "technical problems" are actually business problems in disguise. 2. Define success metrics "Build a faster API" is vague. "Reduce p99 latency to under 200ms, improving user retention by 5%" is actionable. 3. Break it into smaller chunks. Works wonders. Big projects fail without incremental wins. Ship value early and often. 4. Communicate relentlessly Weekly updates to stakeholders. Clear documentation others can reference. No surprises. I've seen brilliant engineers stuck at the same level for years because they wait for perfect clarity. The highest-paid engineers create clarity. They're comfortable being uncomfortable. What's one ambiguous problem you could start defining this week?

An engineering leader recently described to us how his team tracks deployments: "It's embarrassing to even say this out loud," he said, "but everybody who does a deploy is putting them in a spreadsheet." This is what we call pick and axe work, and it is killing engineering productivity everywhere. → When a production incident hits at 3am, teams spend hours trying to figure out what changed because there is no single source of truth. → When a vulnerability drops, nobody knows which services are affected. → When someone asks which version of a library is running in production, engineers start pinging Slack channels and checking build logs by hand. The pattern is always the same. Scattered data, manual correlation, and hours wasted searching for answers that should take seconds. We built Crash Override because build-time data is the Rosetta Stone for your entire SDLC. When you can connect what changed in Git, what happened during the build, and what is running in production with cryptographic certainty, teams stop doing pick and axe work and start getting answers in seconds. 🚩 If your team is still tracking deploys manually or cannot answer "what changed?" in under 60 seconds, sign up for a demo. Link in the comments.