DEV Community: Tolu

The Coverage Mirage

Tolu — Tue, 24 Mar 2026 10:03:01 +0000

[

](https://substackcdn.com/image/fetch/$s_!cQXg!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F3a0f1e7a-4560-40b4-ad4f-d16ae2050ca4_1408x768.png)

The Blocked Pull Request

It is 3:00 PM on a Thursday, and the sprint demo is in exactly eighteen hours. Sarah’s pull request has been stalled in review for three days over seven lines of code. The reviewer, a well-meaning tech lead, just posted a message in the team Slack channel: “@sarah please add a dedicated unit test for the API_URL configuration wrapper.” The wrapper simply reads a standard environment variable. Meanwhile, the feature this pull request unlocks is the subject of daily executive status checks.

Sarah is deeply frustrated, the reviewer is entrenched in a philosophical stance on code quality, and the product manager is escalating the delay to the engineering director. The team is currently paralyzed by a battle over theoretical purity while a completed business deliverable gathers merge conflicts. Cycle Time is increasing, PR Lag is spiking, and the working relationship between engineering and product is fracturing.

This scenario plays out in engineering departments every single week. It is what happens when testing transforms from a pragmatic risk management tool into an unyielding ideological gate.

The Liability of Perfect Coverage

A junior engineer thinks of testing as a binary proof of correctness. They believe that if the test suite turns green, the software works perfectly. A senior engineer knows that testing is entirely an exercise in risk economics. Tests are not free. They require constant maintenance, they inflate continuous integration times, and they frequently cement early architectural assumptions into place.

Absolute test coverage is a liability rather than an asset. A perfectly tested codebase is often a remarkably rigid one. When every single line of code is wrapped in a mock-heavy unit test, routine refactoring becomes an agonizing, multi-day chore. Engineers find themselves spending hours updating brittle tests that assert implementation details rather than verifying actual business behavior.

Aiming for 100% test coverage is a failure of prioritization. It implies your team is spending the exact same engineering effort on validating a static footer configuration as they are on the core payment processing logic. Perfect coverage is a glaring symptom of misallocated resources, usually driven by engineers who feel safer writing tests for trivial getter methods than tackling complex technical debt.

The Volatility-Impact Matrix

How do you balance this reality when your engineering director has instituted a strict 85% coverage gate in SonarQube? Or worse, how do you handle inheriting a legacy system with zero tests while leadership demands that feature delivery continues at its current frantic pace?

We can look to how Google manages this tension. In Software Engineering at Google (Winters, Manshreck, and Wright), Chapter 11 explores their internal engineering practices. The authors acknowledge coverage as a useful tool for finding untested code, but warn that demanding an absolute percentage across the board frequently incentivizes developers to write poor, assertion-free tests just to hit the target. Building on their philosophy, I use my own heuristic: test coverage beyond 80 percent usually offers severely diminishing returns. Forcing absolute coverage across every file artificially constrains deployment velocity, and in my experience, rarely prevents enough production bugs to justify the maintenance cost. Instead of chasing a vanity metric, strong engineering cultures emphasize evaluating the impact of a failure against the frequency of change.

Consider using a Volatility-Impact matrix to evaluate your own team’s testing strategy. If you cannot decide between High and Low Volatility for a specific file, use your commit log churn rate over the last thirty days as a tiebreaker. When evaluating impact, remember that High Impact code will take down the system or corrupt data if it fails, whereas Low Impact means a failure is localized, easily recoverable, and does not cause a systemic outage.

High Volatility, High Impact: This is the core domain logic that changes every sprint. Your billing router, your primary authentication flow, or your order processing state machine. This code requires heavy, redundant testing layers including unit, integration, and contract tests.

High Volatility, Low Impact: UI components or presentation logic that changes frequently based on marketing requests, but rarely causes systemic outages. Lean on fast unit tests for core logic and accept some manual QA leakage for the visual rendering. Over-testing here creates massive maintenance overhead for very little safety.

Low Volatility, High Impact: Legacy modules or base infrastructure components. These rarely change, but if they break, the system goes down. Write robust integration tests to ensure they stay functional from the outside, but do not waste time backfilling granular unit tests for every private method hidden inside them.

Low Volatility, Low Impact: Static content generators or internal admin scripts. Minimal to zero testing is acceptable here. A single, high-level smoke test confirming the script executes without throwing a fatal exception is usually sufficient to manage the risk.

The reality of office politics is that management metrics quickly become operational targets. When a rigid coverage gate blocks a critical hotfix, engineers will rationally write meaningless, assertion-free tests just to satisfy the automated pipeline. Acknowledging this gamification is the first step toward surviving a toxic metrics culture. If your current environment stubbornly mandates these rigid gates, you have to manage upward to incrementally change the definition of quality, while providing your team with cover to focus on actual risk.

Scripts for Negotiating Coverage Mandates

Navigating test requirements means actively negotiating with two distinct factions. You have the feature-hungry product manager who sees tests as an unnecessary delay, and you have the rigid engineering gatekeeper who demands perfect coverage regardless of context.

When Product wants to skip tests entirely to meet an arbitrary deadline, avoid talking about engineering purity or clean code. Frame the conversation entirely around predictable delivery and operational risk.

Consider using this script in your next sprint planning: “If we ship this payment feature without covering the edge cases in the transaction router, we are accepting an unquantified risk of silently dropped payments. I can merge it today to hit the deadline, but we need an explicit agreement with leadership that any production fallout next week completely overrides our upcoming sprint commitments. Are we comfortable taking on that operational risk?”

Conversely, when a manager or peer reviewer blocks a pull request over a lack of coverage on low-risk code, pivot the conversation away from philosophical quality and toward engineering return on investment.

Consider using this script as a pull request comment: “I understand our CI gate flags anything under 80% coverage on new modules. However, the uncovered lines here are primarily structural boilerplate and logging fallbacks. Writing tests for these specific paths will take roughly [X hours based on your estimate] and will tightly couple our test suite to implementation details we plan to deprecate next quarter. I propose we merge this as-is and track the deprecation in the backlog, so we can focus our engineering time on the core data transformation logic in the upcoming ticket.”

Mapping Churn to Coverage

Stop guessing where your testing gaps are. Vague anxieties about code quality do not help you prioritize your week, and they certainly do not help you defend your architectural decisions in leadership meetings.

Block off 60 minutes on your calendar today for a specific diagnostic exercise. Open your version control system and use your commit logs to identify the top five most frequently modified files over the last thirty days. Pull up the specific automated test coverage reports for those exact five files.

Next, find five files in your repository that have not been touched by an engineer in over two years. Check their coverage.

If your high-churn files have low coverage, your team is operating with unacceptable daily risk. You need to pause feature development on those specific components until protective tests are backfilled. If your static, two-year-old files have 95% coverage, you have documented historical proof of over-investment in stable code. Use this specific data to adjust your team’s pull request review guidelines tomorrow morning, explicitly focusing your engineering effort on the files that are actively changing.

Sustainable Velocity

Tolu — Tue, 10 Mar 2026 10:01:11 +0000

[

](https://substackcdn.com/image/fetch/$s_!9YQG!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F89eb7071-1760-4620-b12f-3c329b2def88_1408x768.png)

We all know the feeling of the “Hero Push.”

It is Thursday evening. The feature is due on Friday. The team stays online until 11 PM, fueled by caffeine and adrenaline, hammering out code to cross the finish line. You merge the final PR, drop a celebratory GIF in Slack, and log off feeling like champions.

Then Monday morning arrives.

The CI pipeline is broken. Customer Support is logging bizarre edge-case bugs. The database is throwing deadlock errors. You spend the next two weeks cleaning up the mess you made on Thursday night.

You didn’t actually move faster. You just borrowed velocity from the future at an exorbitant interest rate.

If you are reading this, you already know chronic “crunch time” is bad. You know burnout is real. But understanding that the system is broken does not magically give you the power to fix it.

The Traffic Jam Paradox

Crunch does not happen because engineers type too slowly. It happens because of a failure in organizational negotiation.

To negotiate effectively, you only need one concept from queuing theory: Utilization vs. Throughput.

Think of a highway. At 50% capacity, cars move at the speed limit. At 100% capacity, it becomes a parking lot.

Engineering teams work the exact same way. If management demands 100% utilization, collaboration dies. Your finished PR sits idle for three days because your reviewer is fully booked. A team running at 100% utilization is not an engine. It is a traffic jam.

The Reality of Pushing Back

This is the part where most advice columns tell you to “just decline meetings” or “say no to your boss.”

That is dangerous advice. If you work at an agency, a startup under massive investor pressure, or a company with a founder who rules by decree, showing up with a spreadsheet that implies the business made a bad decision is a career risk.

If your environment is truly toxic, yes, you should update your resume. But what do you do for the six months it takes to find a new job?

You practice Defensive Documentation. You work your 40 hours, you clearly document what features will drop, and you let the bad deadline fail. You act as a heat shield for your junior developers, telling them to log off at 5 PM.

Let’s be brutally honest: this is a calculated risk. Letting a deadline fail in a toxic culture can absolutely get you performance-managed or fired, regardless of how clean your paper trail is. But burning yourself out for a system that will gladly replace you tomorrow is also a risk. You have to choose which risk you are willing to take.

However, if you have a baseline level of psychological safety, a Senior Engineer has a responsibility to push back. You just have to do it correctly.

Arguing with the Right Metrics

Telling your manager “the team is burning out” is an emotional argument. Emotional arguments rarely win against delivery dates.

But you also cannot use bad data. Trying to correlate “story points delivered” with “bugs created six months later” is statistically noisy. A smart VP or Finance partner will tear that argument apart.

Instead, argue using metrics that are impossible to dismiss: Cycle Time and PR Review Lag.

When utilization hits 100%, code review is the first thing to die. Bring this specific metric to your leadership. Say: “During our last crunch push, our PR review lag went from 4 hours to 3 days. We aren’t actually shipping faster. We are just piling up undeployed inventory and increasing merge conflicts.”

You cannot argue with a PR sitting untouched for 72 hours. It perfectly illustrates the traffic jam.

When the Manager Already Said “Yes”

The most common failure mode is not a villainous CEO. It is a well-meaning Engineering Manager who agreed to a bad deadline in a leadership meeting without consulting the team.

Now the date is promised, and the crunch is mandated. What do you do?

You cannot throw your manager under the bus in front of Product, but you can force reality into the room. You do this by negotiating scope, not time.

First, you need context. Do not guess what is important. Spend 15 minutes with your Product Manager and ask one question: “If we can only ship one feature on Friday to keep the contract alive, which one is it?”

Once you know what is actually load-bearing, you approach your manager with a concrete compromise.

“I know we committed to Friday. Based on the current blockages, we will miss that date unless we cut something. We can hit Friday if we drop the reporting dashboard and ship just the core pipeline. How do you want to communicate this to Product?”

You are not whining. You are giving your manager a lifeline to go back to stakeholders with a professional compromise.

Your Homework

This week, you are going to diagnose your team’s traffic jam.

Open your team’s sprint board right now. Count the total number of tickets currently marked as “In Progress” or “In Review.” Divide that number by the number of engineers on your team.

Is that number greater than 1.5?

While Kanban experts will rightly tell you that WIP limits should be calibrated specifically per team, 1.5 is a solid baseline heuristic. It accounts for one active ticket per person, plus a small buffer for tickets currently blocked in review or QA. Anything higher strongly predicts context-switching and review bottlenecks.

If your number is higher than 1.5, your highway is jammed. Bring this specific metric to your next 1:1. Say: “Our WIP-per-engineer is currently 2.4. We are starting a lot of things but finishing them slowly. I recommend we implement a strict WIP limit next sprint so we can clear the review backlog and actually get code merged.”

Every time you bleed to save a bad deadline, you are not being a hero. You are training your organization that the deadline was reasonable. You are proving that their broken estimation process actually works.

Stop masking organizational failures with your weekends. If the system is worth fixing, let the bad deadline fail, point to the traffic jam, and force the system to change.

Code That Survives You Leaving

Tolu — Tue, 03 Mar 2026 09:59:24 +0000

[

](https://substackcdn.com/image/fetch/$s_!ttBz!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F2e0be7b0-c79f-44f5-b374-01ebbc609a7b_2816x1536.png)

“The best code is code that survives you.”

An engineer left our team mid-project. He’d been there five years and was the only one who truly understood our transaction processing service. We knew he was knowledgeable. We didn’t realize how much undocumented knowledge he held until he was gone.

For a month, our deployment velocity dropped to zero. Every change required reverse-engineering his logic. A simple bug fix that should have taken two hours took two days because we had to understand the entire system first. We spent hundreds of engineering hours rebuilding context that should have been documented all along.

The service worked perfectly. The documentation was non-existent. Comments explained what the code did, not why it existed. The architectural decisions lived entirely in his head.

He wasn’t malicious. He was busy. He never made sharing knowledge a habit, and neither did we require it. When he gave his two weeks’ notice, we realized too late that we’d built a single point of failure into our team.

The Indispensable Trap

Some engineers believe that being the only person who understands a critical system creates job security. They’re half right.

You won’t get fired. But you also won’t get promoted. You can’t take a peaceful two-week vacation without your laptop. You can’t transition to exciting new projects because you’re permanently chained to maintaining the old one. You become a prisoner of your own expertise.

Deep technical knowledge is valuable. It’s often what gets you promoted to Staff or Principal levels. But the difference between a senior engineer and a senior leader is this: senior engineers make themselves valuable. Senior leaders make their teams capable.

The measure of your impact isn’t how much your team needs you today. It’s how well they function when you’re not there tomorrow.

You can’t transfer years of undocumented context during a two-week notice period. Knowledge transfer isn’t a final handover event. It’s a continuous architectural habit.

Here are three practices that make your work survive your departure:

1. Document the Ghosts

Junior developers write comments explaining what the code does. Senior developers write comments explaining why the code does it. Staff-level developers document the ghosts: the paths they explicitly decided not to take.

When the next engineer inherits your codebase, they’ll see a clunky workaround and think, “This is inefficient. I’ll just rewrite it.” Without context, they’ll step on the same landmine you successfully avoided.

Architecture Decision Records prevent this. Here’s a real example:

# ADR 003: Use 45-Second Timeout for Billing Service

## Context
Initial implementation used 30-second timeout. During load 
testing with realistic African mobile network conditions, 
we observed legitimate transactions completing in 31-35 
seconds due to payment provider API latency.

## Decision
Increased timeout to 45 seconds.

## Consequences
- Slower user experience (acceptable tradeoff)
- Must monitor p95 latency; if it exceeds 40s consistently, 
  we need to optimize the service, not reduce the timeout
- If payment provider improves API performance, we can 
  revisit this decision

## Alternatives Considered
- Keep 30s timeout, retry failed transactions: Created 
  duplicate transaction risk
- Async processing: Adds complexity, doesn't improve user 
  experience for time-sensitive payments

This ADR saves the next engineer from making the same mistake twice. It shows what you tried, what failed, and why the current approach exists.

2. The 3 AM Runbook

Most documentation gets written at 2 PM by a calm engineer with coffee. That documentation is useless during actual incidents.

Real runbooks need to work for a panicked engineer at 3 AM who’s never touched this system while the production database is degrading.

Bad runbook:

“Ensure the cluster state is healthy before proceeding.”

Good runbook:

Symptom: Billing service pods in CrashLoopBackOff

First step: Run kubectl get pods -n billing

If you see CrashLoopBackOff:

Check logs: kubectl logs -n billing billing-service-[pod-id]

Common cause: Database connection pool exhausted

Quick fix: Run this script: /scripts/restart-billing-safe.sh

DO NOT restart the master database node (causes 2-3 min downtime)

If problem persists after 10 minutes: Escalate to @platform-team in Slack

Related: See ADR 007 for why we use connection pooling

The difference is specificity. The first version requires expertise. The second version provides a checklist that works even when your brain doesn’t.

3. Context Over Cleverness

Highly abstracted, clever code that only you can read isn’t a feature. It’s a liability.

I’ve seen brilliant engineers write elegant, sophisticated solutions that get completely rewritten six months after they leave because nobody else could maintain them. The cleverness that made them proud made the code fragile.

Boring, readable code survives. Undocumented clever code gets rewritten.

This doesn’t mean write bad code. It means optimize for the next person who has to understand it, not for demonstrating your mastery of advanced language features.

If your code requires deep expertise to modify, add comments that build that expertise:

// Using binary search here because linear search was too slow
// for datasets >10k records (measured at 3.2s vs 45ms)
// If dataset size drops below 1k, linear might be simpler

In 2026, documentation increasingly serves as context for AI-assisted development. If your team uses LLMs for codebase onboarding, your ADRs and detailed comments become training data that helps new engineers ramp up faster. But even without AI tools, clear documentation helps humans understand your work.

The Two-Week Notice Test

Here’s an exercise to test your own replaceability:

Look at your team’s current sprint. Pick the one task that would completely stall if you were unavailable tomorrow.

Don’t fix it by writing code. Fix it by writing documentation.

Spend one hour creating a runbook:

Context: Why does this task exist? What problem does it solve?
Prerequisites: What needs to be true before starting?
Step-by-step instructions: Specific commands, not general guidance
Common failure modes: What goes wrong and how to fix it
Who to ask if stuck: Escalation path when documentation isn’t enough

Then test it. Hand the runbook to a teammate and ask: “Could you complete this task using just this document?”

Their answer tells you if your documentation is good enough.

If they need to ask you clarifying questions, your documentation has gaps. Fill them. Repeat until they can execute without you.

The Real Career Advancement

Some engineers worry that making themselves replaceable makes them less valuable. The opposite is true.

Teams that depend on knowledge-hoarders can’t scale. Teams that depend on knowledge-sharers can.

When you document your expertise, you free yourself to work on harder problems. When you make your current role easy for others, you create space to grow into the next one.

The engineers who get promoted aren’t the ones who hold knowledge. They’re the ones who multiply their impact by sharing it.

Make yourself replaceable. It’s the fastest path up.

What task on your current sprint would stall without you? And what would it take to document it so thoroughly that it wouldn’t?

The Subtle Art of the Technical Veto

Tolu — Tue, 24 Feb 2026 10:01:02 +0000

[

](https://substackcdn.com/image/fetch/$s_!ubRZ!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F06be4a9e-ad96-4738-bc93-5d42da0f7439_2816x1536.png)

”Authority is a currency. Every time you say ‘No’ you spend it.”

We all know that one Senior Engineer. Let’s call him Rick.

Rick is brilliant. He knows the codebase better than anyone. But everyone hates asking Rick for a code review. Why? Because Rick finds a reason to block everything.

He blocks PRs because of variable naming preferences. He blocks architectural RFCs because “we tried that in 2019 and it failed.” He blocks library upgrades because “the new version is bloated.”

Rick thinks he is the Guardian of Quality. The team thinks he is the Department of No.

Eventually, the team stops inviting Rick to design meetings. They start merging code when Rick is on vacation. They build “Shadow IT” systems just to bypass his approval.

Rick has lost his Political Capital. When a truly dangerous security flaw actually appears and Rick screams “Stop!” nobody listens. He has already spent all his bullets on variable names.

As a Staff or Principal Engineer, your job is not to be the Gatekeeper. It is to be the Cost Revealer.

You cannot do that if you veto everything. You need a framework for when to pull the emergency brake and when to let the train keep moving.

The Veto Matrix: Risk vs. Reversibility

Before you say “No,” you must ask two questions:

How high is the risk? (Is this a mild bug or a data breach?)
How reversible is the decision? (Can we fix this tomorrow or are we stuck with it for 5 years?)

1. Low Risk / Reversible (The “Nitpick”)

Example: A junior dev uses a slightly inefficient loop in a non-critical background job.
Your Action: Approve.
The Comment: “This is O(n^2). It’s fine for now because the dataset is small, but if we scale, we will need to refactor. Merging.”
Why: If you block here, you are just flexing your ego.

2. High Risk / Reversible (The “Guardrail”)

Example: Deploying a routine code change on a Friday afternoon when SRE is offline.
Your Action: The “Yes, If” Veto.
The Tactic: Attach a Price Tag.
The Comment: “Yes, we can deploy this today. If you are willing to join the on-call rotation this weekend because SRE is offline. Are you okay with that risk?”
Why: You aren’t saying “No.” You are saying “Here is the cost.” Usually, when you expose the price tag, they withdraw the request themselves. Note: If they accept the cost, document their decision and help them mitigate the risk. Your job is to reveal trade-offs, not make business decisions.

3. Low Risk / Irreversible (The “One-Way Door”)

Example: Choosing a new niche database for a minor service.
Your Action: The “Disagree and Commit.”
The Comment: “I believe this database adds unnecessary operational overhead. However, it fits the use case. I am noting my objection in the doc, but I will support the team’s decision.”
Why: This builds massive trust. You showed you have an opinion, but you prioritize the team’s momentum over your preference.
The Caveat: Do not use this if the “One-Way Door” leads to a cliff. If the decision creates 5 years of painful technical debt, move it to Quadrant 4.

4. High Risk / Irreversible (The “Hard Veto”)

Example: Hardcoding encryption keys, violating GDPR compliance, or deploying a bulk-delete script without safeguards.
Your Action: The Hard Veto.
The Comment: “I am blocking this. This implementation exposes customer PII and violates our compliance constraints. We cannot ship this under any circumstances.”
Why: This is why you saved your bullets. When you use the Hard Veto, the room should go silent because they know you don’t use it lightly.

A Real Example: The “November Blackout”

At a previous e-commerce company, a Product Manager wanted to switch payment gateways one week before Black Friday to save 0.5% on transaction fees.

The Junior Engineers were arguing about API compatibility. The PM was ignoring them.

The Staff Engineer didn’t argue about APIs. He used the Price Tag tactic from Quadrant 2.

He wrote: “We can switch gateways. However, we cannot complete the integration testing before the code freeze. If this gateway fails on Black Friday, we will lose approximately $4.5M in orders per hour. I am willing to approve this if you sign off on that risk.”

The PM withdrew the request five minutes later.

The Engineer didn’t say “No.” He just put the $4.5M Price Tag on the table and let the PM decide if they wanted to pay it.

The 2026 Edge: Policy as Code

In the past, the Senior Engineer had to be the “Bad Guy” in the code review. Now, we use tools to be the Bad Guy for us.

Don’t argue with a junior dev about Terraform formatting or S3 bucket permissions. Write an Open Policy Agent (OPA) rule or a GitHub Action that automatically blocks the build if an S3 bucket is public.

The Script: “Hey, I’d love to approve this, but the CI pipeline is blocking it because of the Security Policy we agreed on last quarter. We’ll need to fix that permission to get it merged.”

Now it’s not You vs. Them. It is Us vs. The Robot. You can step to their side of the table and help them “beat the robot.”

Your Homework

Remember Rick? If Rick had used this framework, he would have Approved the variable naming PR (Quadrant 1), Disagreed and Committed to the library upgrade (Quadrant 3), and saved his Hard Veto for the security flaw (Quadrant 4).

The team would have trusted him when it actually mattered.

Look at your last 5 Code Review comments. Count how many times you blocked or requested changes.

Ask yourself: “If I had approved this immediately, would the company have lost money or customers?”

If the answer is “No,” then you are leaking political capital. Next time, try the “Disagree and Commit” approach. Write: “I would have done this differently [Link to reason], but this works. Approved.”

Watch how much weight your “Hard Vetos” carry when you’ve built trust through selective approval.

The Best Code is Useless If Nobody Merges It

Tolu — Tue, 17 Feb 2026 10:02:36 +0000

[

](https://substackcdn.com/image/fetch/$s_!YsUY!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F044d2dc5-7c88-4aba-b57b-ce6a4145a2e8_2752x1536.png)

You have the perfect plan.

You wrote a 6-page Design Doc.

You architected a migration that will pay off 10 years of technical debt.

You present it to the team in the All-Hands meeting.

And then... nothing happens.

There is uncomfortable silence. A Staff Engineer asks, “What about the legacy auth support?” The Product Lead asks, “Do we really have time for this during Q4?” The Manager says, “Let’s put a pin in this and circle back next quarter.”

Your brilliant idea dies in the conference room.

Why?

Because you treated a political problem like a technical problem.

You assumed that if the Logic was sound the Decision would follow. But in an organization logic only validates the solution. Consensus ships it.

If you want to drive technical change you cannot just be a Great Architect. You have to be a Coalition Builder.

The Failure: The “Grand Rewrite” Trap

Early in my career I watched a Principal Engineer try to move a monolithic Java app to Go.

His technical argument was flawless. He had charts showing memory reduction, concurrency improvements, and faster build times. He spent two weeks writing a 20-page RFC.

He presented it to the VP of Engineering.

The VP asked one question: “Does this help us launch the Enterprise Tier by March?”

The Engineer said: “No, but it ensures we can scale in Q3.”

The VP killed the project immediately.

The Engineer was right about the technology. But he was politically naive. He hadn’t built a coalition with the Product leaders to understand their pressures before he pitched his solution.

The Alternative History

If he had spent one week talking to the Product Lead before writing the RFC he would have discovered the pressure to launch the Enterprise Tier.

He could have framed his pitch differently: “I know we need to launch in March. If we carve out just the User Service to Go now it will prevent the Enterprise Tier from crashing on Day 1. We can migrate the rest in Q3.”

That pitch would have been approved.

The Success: The “1,000 Coffees” of React

Contrast that with how React took over Facebook.

In 2011 when Jordan Walke introduced the prototype (FaxJS) he didn’t get a standing ovation. He got pushback.

Senior Engineers hated the idea of putting HTML inside JavaScript (JSX). It wasn’t just “fear of change.” It was a legitimate technical objection regarding the Separation of Concerns.

If the React team had tried to force a top-down rewrite of the News Feed they would have failed. The “No” votes from the Staff Engineers would have buried them.

So they didn’t ask for a rewrite. They built a Coalition.

They found one team that was struggling with performance (Instagram). They helped them fix one specific problem using React. It worked.

Then they found the Ads team. They solved one complex form state issue.

They went desk by desk and solved individual pains for individual influencers.

By the time React was proposed as the standard for the main app the “Separation of Concerns” debate didn’t matter anymore. The evidence was overwhelming and more importantly the voters were already convinced.

Nemawashi: The Art of the Pre-Meeting

What the React team instinctively understood is a concept Japanese business leaders have formalized as Nemawashi.

It literally means “digging around the roots.” In gardening you prepare the soil before you transplant a tree so it doesn’t go into shock. In business it means you never present a big idea in a meeting unless you have already won the votes.

The All-Hands meeting is not for Deciding. It is for Ratifying.

If you are hearing serious objections for the first time in the big meeting you have already failed.

The Hierarchy of “No”

Building a coalition isn’t just about getting your peers to like you. It is about navigating Power Dynamics. You need to identify who actually holds the Veto and tailor your conversation to them.

[

](https://substackcdn.com/image/fetch/$s_!Ds2E!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Ff4613b69-c830-4078-a7da-39e7e8a4a58b_2048x1152.jpeg)

1. The “Pocket Veto” (The Staff Engineer)

They are the technical authority. They can’t fire you but they can poison the team’s opinion.

The Pitch: “I’m looking at this migration but I’m worried about how it impacts the legacy cache. You know that system better than anyone. How would you handle it?”
The Follow-Up: If they say “It’s too complex,” you respond: “That is exactly the kind of concern I need to understand. Walk me through your worst-case scenario so I can protect against it.”

2. The “Resource Veto” (The Manager)

They agree with the idea but “can’t afford the time.”

The Pitch: “If we don’t fix this tech debt the Q3 roadmap is at risk because build times will hit 45 minutes. This project buys us insurance for the launch.”
The Follow-Up: If they say “We still can’t afford the time,” you respond: “What if we broke it into three phases and only did Phase 1 before the launch?”

3. The “Strategic Veto” (The VP/CTO)

They care about P&L and strategic alignment.

The Strategy: Never pitch technology. Pitch enablement.
The Pitch: “This migration isn’t just an infrastructure change. It directly enables the ‘Global Latency’ OKR you announced last month.”
The Trap: If your project doesn’t align with their OKRs, do not pitch it. A “No” from a VP is often permanent because you have just signaled that you don’t understand the company’s priorities. They will remember that the next time your name appears in their inbox.

The 2026 Edge: AI as a Red Team

We used to have to guess where the landmines were. Now we can simulate them.

Before I talk to a skeptic I use AI to “Red Team” my proposal.

The Prompt:

“Act as a cynical Principal Engineer who believes in ‘If it ain’t broke, don’t fix it.’ I am proposing we switch from REST to GraphQL. Tear my argument apart. Focus on caching complexity and N+1 query risks.”

This isn’t about generating text. It’s about generating strategy. It forces you to prep for the hard questions so you don’t freeze up in the real conversation.

When to Walk Away

Sometimes you do the Nemawashi, you build the coalition, and the answer is still “No.”

Maybe the business is running out of cash. Maybe there is a secret acquisition in the works. Maybe the “Cost of Consensus” (months of meetings) is higher than the value of the migration itself.

A Senior Engineer knows the difference between “I failed to persuade” and “The timing is wrong.”

If you have aligned the Logic and the Consensus and it still doesn’t ship don’t burn bridges. Document the trade-offs, commit to the current path, and wait. The constraint will change eventually.

Your Homework

Think about the next big proposal you want to make. Do not schedule the meeting.

Identify the one person who is most likely to block it (The Skeptic).

Schedule a 15-minute coffee chat.

Do not pitch your solution. Use this script:

“I’m exploring a few ways to solve [Problem X] and I know you have a lot of context on the risks here. Before I write anything up I wanted to get your take on what I should avoid. What are the landmines I’m not seeing?”

Listen. Take notes.

If you can solve their specific fear in your document you have just turned a Veto into a Vote.

The irony is brutal. The code might take two weeks to write but the coalition might take two months to build. It feels like “overhead.”

But here is the truth I have learned after almost a decade in the trenches: The perfect solution that never ships is just a Notion doc. The 80% solution that everyone agrees to becomes the foundation for the next decade.

Write great code. But spend even more time making sure someone actually merges it.

The “Best Practice” Trap

Tolu — Tue, 10 Feb 2026 00:59:13 +0000

[

](https://substackcdn.com/image/fetch/$s_!C2Ty!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F8f211230-3840-4290-965d-ca4adb27fe3c_1024x572.png)

In God we trust. All others must bring data.

In 2023 the engineering team at Prime Video did something that looked like career suicide.

They had built a tool to monitor video quality streams using a modern Serverless architecture. It used AWS Lambda and Step Functions. It was decoupled. It was scalable. It followed every single industry best practice.

There was just one problem. The bill.

At just 5% of expected load the cost of passing data between these distributed components was astronomical. The “correct” architecture was going to bankrupt the project.

So they did the unthinkable. They argued against the industry standard and proposed moving back to a Monolith.

They didn’t win that argument by saying “Monoliths are better” or by debating architectural purity. They won by showing the math.

They proved that by packing the components into a single process they could eliminate the expensive data transfer costs.

The result? They reduced their infrastructure costs by 90%.

They didn’t follow the Hype. They followed the Evidence.

The Problem with “I Think”

We have all been in that meeting where two senior engineers are locked in a stalemate.

One wants to use Rust because it is memory safe. The other wants to use Go because the team knows it. They argue about “best practices” and “what Netflix does” for an hour.

The meeting ends with “let’s take this offline” which is just corporate-speak for “let’s argue on Slack for three more days.”

This happens because we try to lead with Opinion.

When you are a Senior Engineer you often have to influence decisions without having direct authority. You can’t just say “Do it my way because I said so.”

If you want to win these debates you have to stop arguing about Preferences and start arguing about Trade-offs.

The Toolkit for Persuasion

You cannot mandate decisions but you can guide them. The trick is to bring evidence in a format that people can actually evaluate.

1. Code Wins Arguments Theoretical arguments go in circles forever. Code ends the conversation.

Next time someone says “I think Library X is faster” don’t argue with them. Spend two hours building a rough prototype. Run a benchmark.

When you say “I built a minimal version of both. Option A processes 1,000 transactions per second and Option B processes 450” the debate ends immediately.

2. Speak the CFO’s Language Engineering managers and VPs care about Velocity and Cost. You need to translate your technical preference into their language.

Don’t say “Serverless is cool.” Say “Serverless costs $X per stream. A Monolith costs $Y per stream. Moving to a Monolith saves us 90% of our operating budget.”

Management listens to ROI. They tune out technical preferences.

3. The “Steel Man” Technique The fastest way to lose a debate is to ignore the other side’s valid points. If you want to win you must articulate their position better than they can.

Before you present your solution say: “You might wonder why I am arguing against Serverless given its flexibility. I agree that it offers superior scaling for bursty workloads. However our workload is constant which makes the cost premiums of Serverless a bad investment for us.”

When you acknowledge the trade-offs you earn trust. You show that you aren’t trying to “win” a fight. You are just trying to be right.

A Real Example: Uber’s Heresy

Prime Video wasn’t an isolated incident.

In the early 2010s Uber did something that shocked the engineering world. They migrated their core trip data from Postgres to MySQL.

At the time Postgres was considered the superior database by almost everyone. It had more features. It had a better community. Moving to MySQL felt like a step backward.

But the Uber infrastructure team didn’t argue about features. They argued about Disk I/O.

They presented evidence showing that the way Postgres handled updates was crushing their hard drives at Uber’s specific scale. Every time they updated a trip record Postgres had to rewrite too much data. MySQL was “dumber” but handled these specific updates much more efficiently.

They didn’t choose the “Best Database.” They chose the Best Tool for the Constraint.

Your Homework

Look at the next technical alignment on your team’s calendar.

Prepare one piece of evidence before you walk into the room or join the call.

It could be a spreadsheet comparing cloud costs. It could be a rough prototype benchmark. It could be a list of tickets from the last time you tried this approach and failed.

Don’t go in with an opinion. Go in with data.

The Most Expensive Code is the Code Nobody Wants

Tolu — Tue, 03 Feb 2026 10:01:16 +0000

“Measure twice, cut once.”

It is an old cliché but the team at Segment (the customer data platform) learned it the hard way.

In 2018 their engineering team followed the industry hype and broke their core product into 140 microservices. It was an architectural marvel. It followed every “best practice” in the book.

Three years later they published a famous post admitting it was a disaster.

The complexity had exploded. Engineers were spending more time managing message queues and debugging distributed traces than shipping features. In 2020 they had to burn months of effort to move everything back to a Monolith.

What went wrong?

They jumped to the Solution (Microservices are scalable!) before rigorously validating the Problem (Does our team size justify this operational complexity?).

The root cause is always the same. The rush to code beats the discipline to think.

Senior engineers prevent this with a deceptively simple practice. They write things down before they write code. Not because they love documentation but because three days of planning prevents three years of pain.

The “Google Doc” That Saves Months

When an engineer says “let me write an RFC before we start” they are not adding bureaucracy. They are buying insurance.

RFC stands for Request for Comments. It is a structured document that forces you to answer the hard questions before you open your IDE.

The magic isn’t the format. The magic is that it forces Explicit Thinking about Implicit Assumptions.

In the Segment case, an RFC would have surfaced the core question: “Do we actually have the staff to maintain 140 separate deployment pipelines?”

Someone would have commented: “No. We will spend 50% of our week just keeping the lights on.”

That comment would have saved them millions of dollars.

What Good Looks Like

You don’t need a complex template. You just need to answer six questions in plain English.

1. What problem are we solving? Don’t use vague product-speak. Use specific pain.

Bad: “We need to re-architect the backend.”
Good: “Our current monolithic build takes 45 minutes to deploy. This costs us 10 developer-hours per day in waiting time.”

2. What approaches did we consider? List at least three options. This proves you didn’t just fall in love with your first idea.

Option A: Microservices (High scale, high operational cost).
Option B: Modular Monolith (Medium scale, low cost).
Option C: Serverless (High vendor lock-in).

3. What are we proposing and why? Give a recommendation with clear reasoning.

Verdict: “We recommend Option B. It solves the deployment speed issue without requiring us to hire a dedicated DevOps team.”

4. What are the tradeoffs? Every decision has a cost. If you pretend there are no downsides nobody will trust your plan.

Tradeoff: “A Modular Monolith is harder to split up later if we grow to 500 engineers. We accept this risk because we are currently only 20 engineers.”

5. What could go wrong? Paranoid thinking during planning prevents panic during execution.

Risk: “What if the build time doesn’t actually improve?”
Mitigation: “We will prototype the build pipeline for one module before migrating the rest.”

6. What are the open questions? Admitting what you don’t know encourages others to help you.

Question: “Do we need to update our CI/CD provider to support this?”

The AI “Red Team”

The hardest part of writing an RFC is seeing your own bad ideas. You are biased. You want your solution to work.

This is where AI becomes a superpower. Not for writing the text but for challenging the logic.

Before I share a draft with my team I paste the “Tradeoffs” section into Claude or ChatGPT and I use this prompt:

“Act as a cynical Principal Engineer. Read this architectural proposal. Tell me exactly how this system will fail at 10x scale and list three edge cases I have forgotten.”

It simulates a harsh review instantly. It finds the holes in your logic before your boss does. Use AI to stress-test your thinking, not just to fix your grammar.

The “Async” Review

The best part of an RFC is that it kills meetings.

You write the doc. You share it in Slack or Teams. You let people comment on their own time for 3 days.

The Skeptic will ask: “This database schema looks complex. Have you considered a simple key-value store?”
The Product Manager will clarify: “Actually we need to support offline mode. This architecture relies too much on the cloud.”
The Junior will ask: “How does this handle user timezones?”

You fix the flaws in the document. Fixing a flaw in a Google Doc takes 5 minutes. Fixing that same flaw after you wrote the code takes 5 days.

Disagreement during the RFC phase is productive. Disagreement during the Code Review phase is expensive.

[

](https://substackcdn.com/image/fetch/$s_!ujIr!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F8089aafa-cbae-4baf-bfd1-4524c0e0bfe5_2816x1536.png)

A Real Example: The “Comfort Zone” Trap

A fintech team needed to store data for a new transaction service. They had a “Golden Hammer” which was a specific technology stack they loved and used for absolutely everything.

When this new complex feature came up the team naturally reached for their favorite tool again. It was the comfortable choice.

But the Lead Engineer wrote an RFC to challenge it.

He pointed out that their “favorite tool” was actually terrible at handling the specific requirements of this new feature.

He wrote: “If we use our standard tool we will have to write massive amounts of hacky code to make it work. It will be buggy and slow. I propose we use a specialized tool that is designed for this exact problem.”

The team pushed back. “We don’t know that new tool! It will take too long to learn!”

But the RFC made the tradeoffs clear. The cost of learning the new tool was high but the cost of maintaining the hacky solution was higher. The team agreed.

Six months later that decision saved them. The feature ran perfectly. If they had skipped the RFC and stayed in their comfort zone they would have been drowning in technical debt.

When to Skip It

Don’t be the person who writes an RFC for a button color change.

Skip the RFC for:

Small, reversible decisions.
Urgent bug fixes.
Work that takes less than 3 days.

Write the RFC for:

Architectural changes.
New tools or libraries.
Decisions that are hard to reverse (like picking a database or a framework).

Your Homework

Look at the biggest ticket in your current sprint.

Ask yourself: “If I am wrong about how I plan to build this, how expensive will it be to fix later?”

If the answer is “Very Expensive” then open a blank document. Write down the problem, three solutions, and your recommendation. Send it to your team.

You might just save yourself three months of work.

Technical Debt is a Financial Loan. Treat it Like One.

Tolu — Tue, 27 Jan 2026 10:02:45 +0000

If you tell a Product Manager that the code is “messy” or “ugly” or “needs a refactor” they tune you out.

They can’t see the code. To them the app works, the buttons click, and the customers are happy. They assume you just want to tidy up your workspace because you are a perfectionist.

But if you tell them, “We have taken out a high-interest loan that is taxing every new feature by 20%,” they listen.

The problem isn’t the code. The problem is the language.

Engineers who get the budget for refactoring don’t necessarily have cleaner codebases. They have better communication strategies. They stop talking about “cleanliness” and start talking about “liabilities.”

It is not a mess. It is a financial instrument.

Ward Cunningham gave us the term “technical debt” in 1992 but most teams only use half the metaphor. They treat debt like a mess to be cleaned up, like a teenager’s bedroom.

That is not how debt works. Debt is financial. It has a Principal, it has Interest, and it compounds.

Think of it like a credit card.

The Principal is the shortcut itself. It is the hard-coded API endpoint or the copy-pasted validation logic. You saved 3 days of dev time by doing this. You swiped the card to buy speed.

The Interest is the extra time you pay every single time you work around that shortcut. Every new feature takes 20% longer. Every bug fix requires archaeological digging.

If you don’t pay down the principal, the interest compounds. That 20% tax becomes 50%. Eventually you hit Technical Bankruptcy where 100% of engineering time is spent keeping the lights on and 0% goes to shipping new value.

This progression is predictable. It isn’t dramatic. It is a slow suffocation. Teams don’t notice until they realize they can’t ship anything anymore.

[

](https://substackcdn.com/image/fetch/$s_!BFvn!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F03cb96dc-b343-43ec-8458-1a21f7d943fb_2752x1536.png)

How AI Changed the Economics

Paying down technical debt used to be purely manual labor. It was tedious, unglamorous work that nobody wanted to do. But AI has changed the math on this.

First, it acts as an Auditor. In the past we had to guess which code was causing the slowdowns. We would say things like “The billing controller feels messy.” That is an opinion.

Now tools like CodeScene or Stepsize analyze git history to give you data. They can tell you that the Billing Controller was modified 45 times this month with high complexity. They can tell you it is costing you $10,000 a month in wasted dev time. Those numbers are defensible in planning meetings. Opinions are not.

Second, AI acts as the Janitor. AI struggles with writing complex new systems from scratch but it excels at translating old ones. It turns the work nobody wants to do into a 10-minute task. You can ask it to write a test suite for a legacy function or explain what a 5-year-old regex actually does.

The “Subprime” AI Trap

But you have to be careful. There is a new danger here.

Junior engineers using AI to generate thousands of lines of code they don’t understand are creating Subprime Debt.

The code ships fast so the velocity looks great. But nobody, including the AI, understands how it actually works. This isn’t just debt. It is a toxic asset. The knowledge to fix it doesn’t exist anywhere in the building. When that code breaks, you are in big trouble.

Strategic vs. Destructive Debt

This brings us to the difference between Junior and Senior engineers. Juniors aim for zero debt. They want perfect code. Seniors know that some debt is good.

You have Strategic Debt , which is like a Mortgage. You say “We are hard-coding this integration to hit the Black Friday launch. It is not elegant but we will refactor it in January.” This is smart business. You bought speed with a clear repayment plan.

Then you have Destructive Debt , which is like a Payday Loan. You say “We didn’t write tests because we were in a hurry.” This is just negligence. You took out a loan with no plan to pay it back.

The Conversation That Gets Budget Approved

So how do you actually get the time to fix things?

When a Product Manager asks why a feature requires 5 story points instead of 3, do not explain that “the code is bad.” They cannot evaluate that claim.

Reframe it as a business decision using this script:

“To build this feature we have two options.

Option A: We build it on the current foundation. It takes 3 days now but it increases the cost of all future features in this module by 10%.

Option B: We spend 2 extra days paying down debt while we build this. It takes 5 days total but future features will be faster and cheaper. The break-even point is just 3 features from now.

Which approach makes more business sense to you?”

This transforms refactoring from a “developer preference” into a “financial investment” with measurable ROI. PMs almost always choose Option B when they understand the compound costs.

The Senior Shift

Stop arguing about code cleanliness. Start managing your technical portfolio.

Go look at your backlog. Identify one “High Interest” liability that is taxing your team every week. In your next planning meeting do not ask to “refactor.”

Ask to “retire a high-interest liability.”

Language matters.

The "Not Invented Here" Trap (Now Turbocharged by AI)

Tolu — Tue, 20 Jan 2026 10:02:50 +0000

We can build this better.

That is the most dangerous sentence in software engineering.

It usually starts innocently. You need a job scheduler. You look at the open-source options or the cloud offerings and you sniff. “These are too heavy,” you say. “We just need something simple. I can write a lightweight scheduler in a weekend.”

Three months later, you aren’t working on your product. You are maintaining a buggy, half-baked version of Cron that only works on Tuesdays.

This is the Not Invented Here (NIH) syndrome. It is the ego-driven belief that if we didn’t write the code, it isn’t good enough.

[

](https://substackcdn.com/image/fetch/$s_!B7yF!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Ff5d1133b-7e9c-45aa-b907-3e440e843df8_2816x1536.png)

The AI Trap: The “Free Puppy” Problem

In the last two years, AI has actually made this problem worse.

Tools like Claude Code , GitHub Copilot , and ChatGPT have lowered the barrier to entry for building complex things. Now, a Junior Engineer looks at a paid tool like LaunchDarkly (for feature flags) or Retool (for internal dashboards) and thinks: “Why pay? I can just ask Claude Code _, _to scaffold a Redis-backed toggle system or a React admin panel in 10 minutes.”

And the AI might actually do a great job. It might write the perfect streaming logic with correct backpressure handling.

But that is exactly the trap.

The “Free Puppy” Problem: AI makes acquiring code free. But code is like a puppy. Getting it is free, but you have to feed it, walk it, and pay the vet bills for the next 10 years.
The Black Box Risk: You now own complex logic that you didn’t design. When that “perfect” streaming script fails at 2 AM because the AI didn’t know your specific load balancer kills connections after 30 seconds, you are stuck debugging “borrowed brilliance” that you don’t fully understand.

AI has made the cost of writing code near zero. But the cost of owning code remains as high as ever.

The Three Paths: Build, Buy, or Integrate

When you decide to “Buy” (or use open source), you aren’t escaping work. You are trading one type of work for another.

Building: You own the logic, the bugs, and the roadmap. You are the god of your tiny world.
Buying: You outsource the logic, but you are at the mercy of a vendor’s roadmap.
Integrating (The Reality): This is where most modern engineering happens. You aren’t building a payments engine. You are building the glue between your app and Stripe.

Where AI Actually Helps: Instead of using AI to generate the core system (Building), use AI to generate the glue code (Integrating). AI is incredible at writing the boring adapters, transformers, and API wrappers that make integration painful. Use it to lower the “Integration Tax,” not to fuel your “Build” addiction.

The “Core vs. Commodity” Test

How do you stop your team (or yourself) from falling into the trap?

Next time you are debating a technical decision, call a timeout. Get the team in a room and ask this specific question:

If we build the world’s best version of this feature, will our customers care?

It clarifies things instantly.

Scenario A: You are debating building a custom Authentication System because “Cognito is annoying.”

Question: “If we build the best login page in history, will customers buy more of our product?”
Answer: No. They just want to log in.
Decision: Buy/Integrate.

Scenario B: You are a Logistics Company, and you are debating building a Route Optimization Engine.

Question: “If we build the best routing algorithm in history, will customers buy more of our product?”
Answer: Yes. Faster delivery is why they pay us.
Decision: Build.

Go look at your team’s backlog right now. Find one ticket that involves building a utility, a helper tool, or a “simple” version of a paid product.

Ask yourself: “Is this a free puppy?”

If the answer is yes, delete the ticket.

If your Product Manager asks where it went, just tell them you “proactively eliminated a high-interest operational liability to protect future velocity.” They won’t be angry; they’ll be too busy nodding to realize you just deleted their feature.

Build the Core. Buy the Commodity. Use AI to glue it all together.

How to Sell Technical Work to Non-Technical Leaders

Tolu — Tue, 13 Jan 2026 10:02:07 +0000

[

](https://substackcdn.com/image/fetch/$s_!nPG2!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fa6c9c622-7e1f-445b-93e1-8b4b96e61cf3_2816x1536.png)

If you can’t explain it simply, you don’t understand it well enough.

We have all had that moment. You push “deploy” and for a split second your heart stops. You stare at the monitoring dashboard and pray the graphs don’t turn red.

In 2012, for the engineers at Knight Capital Group, the graphs didn’t just turn red. They exploded.

Because of a manual deployment error where they missed just one server out of eight, an old piece of code woke up. It was supposed to be dead code, often called “technical debt,” but instead it started buying high and selling low like a maniac.

In 45 minutes , the algorithm lost $440 million. The company was bankrupt before lunch.

I think about that story a lot. Not because of the money, but because of the conversation that likely happened six months before the crash. I guarantee you those engineers knew their deployment process was manual and scary. They knew that dead code was sitting there like a landmine.

But they probably went to management and said, “We need to refactor the deployment pipeline to reduce configuration drift.”

And management heard, “We want to spend money to fix something that isn’t broken.”

If they had said, “We are sitting on a $440 million risk that could wipe out the company in under an hour,” the check would have been signed before they finished the sentence.

The “Rosetta Stone” of Engineering

The biggest lie we tell ourselves as engineers is that executives “don’t get tech.”

Trust me, they get it fine. They just keep score differently. While you are sweating over Latency , Code Quality , and Uptime , they are looking at Revenue , Cost , and Risk.

If you walk into a meeting speaking “Kubernetes” and they are listening for “Q3 Revenue” you are going to lose. You need a translator.

The Translation Dictionary

I used to get frustrated when my cleanup projects got rejected. Then I realized I was pitching the wrong things. Here is how I learned to translate “dev speak” into “money speak” for my boss.

1. The “Refactoring” Pitch

What you want to say: “This code is spaghetti and I hate working in it. We need to rewrite it.”
What you should say: “Our current messy code slows us down. Right now it takes us 4 weeks to ship a feature. If we clean this up, we can ship 3 features a month instead of one, without hiring more people.”

2. The “Security” Pitch

What you want to say: “We need to upgrade this library because it has a CVE.”
What you should say: “We have a vulnerability that makes a data breach likely. The average breach costs a company like ours $4 million. Spending $10k now reduces that risk to almost zero.”

3. The “Infrastructure” Pitch

What you want to say: “We need to use this cool new cloud tool.”
What you should say: “Every minute our site is down, we lose $5,000 in sales. This tool guarantees we stay up, protecting $200k in revenue next year.”

The One-Page Rule

The next time you want to propose a big technical change, please, I beg you, do not send a 10-page architecture document. Nobody reads it.

Send a One-Pager. Just four bullet points:

The Problem: What is broken, and how much money is it costing us?
The Solution: What are we building? (Keep it high-level).
The Cost: How long will it take?
The Payoff: What does the business get out of it?

The Senior Shift

Junior engineers think their job is to write code. Senior engineers know their job is to deliver value using code.

When you start speaking the language of the business, something magical happens. You stop being the “cost center” that needs to be managed, and you start being the “business partner” who gets the budget.

Try this today: Look at the ticket you are working on right now. Can you explain why you are doing it without using a single technical term?

If you can’t, do you really know why you’re doing it?

The True Cost of Technical Decisions

Tolu — Tue, 06 Jan 2026 10:02:14 +0000

There are no solutions. There are only trade-offs. Thomas Sowell

We all want to build cool stuff. It’s why we got into engineering.

In 2016, Uber made what felt like the coolest technical decision on the planet. To handle their insane growth, they decided to split their monolithic codebase into microservices. On a whiteboard, it looked brilliant. Elegant. Scalable.

Fast forward three years, and they hadn’t built a sleek machine; they’d grown a jungle.

They had over 2,000 distinct microservices. Trying to debug why a ride request failed felt less like engineering and more like archaeology, tracing a single click through 50 different services owned by different teams. They were spending more time tracing function calls than shipping actual value to customers.

It took them years and millions of dollars to unwind that “brilliant” decision into something manageable.

This is the hard truth that took me years to learn: Complexity isn’t a badge of honor. It’s a tax. And you pay it with your most precious resource; your time.

The “Weekend Project” Trap

We’ve all been there. You look at a vendor like Auth0 or Datadog charging $500 a month and think, “What a rip-off! I could build a basic version of that in a weekend.”

And you’re right. You probably could build it in a weekend.

But then you spend the next two years patching it, securing it, upgrading it, and waking up at 3 AM when it breaks because you didn’t account for daylight savings time in a specific timezone.

Your salary is real money. If buying a managed tool saves your team just three hours of collective engineering time a month, it has usually paid for itself. Stop treating your time like it’s free.

The Jungle You Create (The Hidden Costs)

When you choose to build something that you could buy, you aren’t just saving license fees. You are planting vines that will eventually choke your productivity.

The Maintenance Vine: Code is never “done.” It’s a living liability that needs constant feeding. Every line of custom infrastructure code you write is a line of feature code you didn’t write.
The Opportunity Cost Vine: While your team is busy reinventing a payment gateway that Stripe already perfected seven years ago, your competitor just shipped the game-changing feature that’s going to steal your market share.
The “Bus Factor” Vine: You know that “lightweight, custom” internal tool Bob built? Well, Bob just quit to join Google. Now you are the only person on earth who understands how it works. Good luck taking a vacation this year.

The Senior Engineer’s Rule: Only Build the Magic

So, how do you decide? You can’t outsource everything.

My rule of thumb has become simple over the years: Outsource the plumbing so you can focus on the magic.

BUY the boring stuff. Authentication, email delivery, basic monitoring, standard payments. If 10,000 other companies need the exact same thing, don’t build it yourself.
BUILD your differentiator. The thing that makes your company unique. The secret sauce algorithm. The core user experience that nobody else has. That’s where your brainpower should go.

Early in my career, I optimized for “Resume Driven Development.” I wanted to build everything from scratch because it felt like real engineering.

Now? I optimize for sleep and shipping. My job isn’t to write the most code; it’s to solve the problem in the smartest way possible so the business wins.

Take a look at your Jira board right now. What ticket are you dreading? Is it wrestling with some custom, over-engineered beast that isn’t core to your product?

What would happen if you just deleted that code and bought a solution instead? (Okay, you will probably need some consultations and approvals before you light the legacy repo on fire since I really don’t want you to get fired because of my post, but you get the point.)

That is the difference between just coding and actually engineering.

My TensorFlow Journey

Tolu — Sun, 05 Jan 2020 09:36:02 +0000

Ever since my undergrad days, where I first got to know about Artificial Intelligence, I became so fond of the various disruptions that come with it and then a decision was made. I decided to specialise in AI.

Making such decisions like mine comes with a lot of commitment to self-development since undergrad lecturers only briefed about it. I decided to get books on Machine Learning and the approach was with the core Python and I was able to understand few concepts from it after which I left it to pursue few gigs since I was a grad already.

Fast forward to 2019, I was introduced to Tensorflow Lagos meetup, I signed up to attend, but so sad I couldn’t, make it there, but after the event the organizer did well to share the resources used at the meet up, and lo and behold they shared the link to the Udacity Course on Intro to TensorFlow for Deep Learning by TensorFlow

I have been on the course for some weeks now, and it has been very insightful. Thanks to the authors of the course

Paige Bailey
Magnus Hyttsten
Juan Delgado

I will be sharing in a series, which will be released every week what I have learnt, what I am learning and what I am expecting. You are welcome to join me on this wonderful experience of becoming a TensorFlow expert before the new year ends.

Each day holds a surprise. But only if we expect it can we see, hear, or feel it when it comes to us. Let’s not be afraid to receive each day’s surprise, whether it comes to us as sorrow or as joy It will open a new place in our hearts, a place where we can welcome new friends and celebrate more fully our shared humanity.