Traditional Code Review Is Dead. What Comes Next? makes the case that humans won’t be able to keep up with code reviews when AI is at scale. It concludes that humans should move to testing behaviors in a preview environment (i.e. manual testing) instead of line-by-line reviews. Personally, I don’t see how you can ship AI-generated code without a traditional code review. However, I do agree that humans will be the bottleneck when AI is operating on code at scale. Is there a better solution?
-
AI-Ready Frontend Architecture
To get the most out of AI it makes sense to architect your frontend in a well-known and predictable way. I’ve been thinking about what an AI-ready frontend architecture might look like but have yet to test and recommend a specific solution. However, Nelson Michael has an interesting take on the problem in the article A Developer’s Guide to Designing AI-Ready Frontend Architecture.
Here are some key points:
- AI amplifies weak architecture
- Teach AI your architecture explicitly file
- Directory conventions matter more than ever
- Use design systems as constraints
- The use-case pattern is the backbone
- Use middleware for cross-cutting concerns
- Pay special attention to auth, testing, and observability
-
Dave Kiss on Ideas and Execution
I was so disappointed when I first heard the adage “ideas are a dime a dozen.” I had plenty of ideas. The hard part, I learned, was actually building the damn thing. Plenty of people have pointed out how that barrier is gone now, but I like how Dave says it.
Remember when coming up with a great idea was the easy part? Ideas were worthless. What was valuable was the commitment. The grit. The planning, the technical prowess, the unwavering ability to think night and day about a product, a problem space, incessantly obsessing, unsatisfied until you had some semblance of a working solution. It took hustle, brain power, studying, iteration, failures.
-
Simon Willison on Technical Blogging
Simon gives some solid, and surprising, advice for technical bloggers:
My number one tip for blogging is to lower your standards! Aim to hit publish while you are still actively unhappy with what you have written, because the only alternative is a huge folder full of drafts and never publishing anything at all.
-
Robots.txt is Required for Google
Fix Your robots.txt or Your Site Disappears from Google
Google now requires a robots.txt file or your site won’t get indexed.
-
Attention Residue
What Is Attention Residue? The Hidden Focus Killer That’s Sabotaging Your Productivity
Attention residue is when human attention remains “stuck” on a previous task after switching to a new one. It happens because the brain can’t instantly switch “mental sets.” Instead of a clean break, a “background process” continues running on the unfinished or emotional previous task. So your focus gets fragmented and your cognitive capacity is reduced.
The Cost of Context Switching
The article argues that multitasking is a myth; it’s actually rapid task switching with heavy neurological penalties. I 100% agree with this.
- Productivity Loss: Constant toggling can cost up to 40% of productive time.
- Recovery Time: It takes an average of 9.5 minutes to fully return to a productive workflow after a digital interruption.
- Cognitive Decline: Residue impairs working memory, problem-solving, and creativity. It mimics the effects of a lower IQ and contributes to chronic decision fatigue and burnout.
- The Zeigarnik Effect: Incomplete tasks occupy more mental RAM than completed ones, exacerbating the residue.
The Upside: Productive Residue
Residue is only negative when your attention is scattered across different topics. When applied to a single deep-work task, residue can be an asset. The subconscious continues processing the single problem during breaks (incubation), leading to breakthroughs.
7 Strategies to Eliminate Residue
The author outlines seven methods to minimize cognitive drag:
- Master Single-Tasking: Create an environment where only one task is possible. Use blockers and dedicated devices to force focus.
- Design Transition Rituals: Perform a “brain dump” or physical movement (stretching, walking) between tasks to signal the brain to close the previous mental set.
- Strategic Time Blocking: Batch similar tasks (e.g., all emails at once) to reduce the frequency of mental gear-shifting.
- Control Information Diet: Turn off non-urgent notifications. Most workplace residue comes from treating email/Slack as a synchronous, always-on activity rather than a batched task.
- Create Boundaries: Use physical cues (headphones, closed doors) and digital hygiene (separate browser profiles for work vs. leisure) to compartmentalize focus.
- The “Parking Lot” Method: When a distracting thought or incomplete task pops up, write it down immediately to “offload” it from working memory, then return to the current task.
- Schedule Recovery: Build in buffer times between high-intensity tasks and use a “shutdown ritual” at the end of the day to sever the connection to work stress.
-
Read One Book Per Week
There are some great tips for reading more in this post. My favorites are:
- Always have a book. Keep a book in every room and on every device.
- Read all three types of books, paper, audio, and e-books.
- Don’t finish every book. I have a textbook that I only need to read half of.
-
Software Engineering Topics Worth Writing About
Some topics I think are always worth writing about and sharing:
- Your process, failures and successes, to figuring something out
- How to hack on some major open source project
- In-depth comparison of projects or approaches, down to source code, benchmarks, and architecture when relevant
- Building minimal versions of some production system
- How some major systems works under the hood, down to the code
- Mistakes you made in structuring organizations, or production architecture, or testing, etc.
- How to get the dang configuration right for testing Electron apps in Github Actions
-
What I Care About as a Lead Engineer
I care about different things now that I have grown into a lead engineer. There are some things that I have started to care more about, and some things that I have started to care less about.
What a lead cares less about
- Personal Commit Volume
- Junior/Senior View: “I need to ship a lot of code to prove my value.”
- Lead View: “I need to unblock others so they can ship code.”
- As a lead, you spend time on code reviews, design, answering questions, and clearing the path. As a result, the number of commits you make decreases.
- The Latest and Greatest Software
- Junior/Senior View: “Let’s use this new beta framework; it’s faster, cooler, and more modern.”
- Lead View: “Can we hire for this? Is it stable? Does it have good documentation?”
- Leads focus on long-term maintainability and hiring over cutting-edge trends. As a lead, I shy away from big rewrites if they are not critical.
- Micro-Optimization & “Perfect” Code
- Junior/Senior View: “This function can be 5 ms faster if I rewrite it three times.”
- Lead View: “Is it good enough to ship today?”
- Seniors often chase architectural purity. Leads are more open to taking on technical debt if it gives a business edge, like meeting a deadline. They need a plan to pay it off later.
- How the Team Solves the Problem (Implementation Details)
- Junior/Senior View: “This is exactly how I would write this class.”
- Lead View: “Does the interface match the spec? Does it pass tests? Then do it your way.”
- Leads learn to delegate ownership. Nitpicking every line of a Senior’s code to match their style creates a bottleneck. It also demoralizes the team. They care about the contract (inputs/outputs), not the implementation.
- Being the “Smartest in the Room”
- Junior/Senior View: “I need to have the answer to every technical question to show authority.”
- Lead View: “I need to find the person who has the answer.”
- A Lead’s value comes from synthesis and decision-making, not encyclopedic knowledge. They feel at ease saying, “I don’t know, let’s ask the database expert.” This change means they now route knowledge instead of sharing it.
- Rigidity in Process
- Junior/Senior View: “The ticket had incorrect formatting, so I won’t do it.”
- Lead View: “This is urgent; I’ll fix the ticket later.”
- While Leads usually enforce process, they also know when to break it. They focus less on sticking to strict rules, like needing 100% test coverage for a prototype. Instead, they focus on the practical needs of the business.
What a lead cares more about
Lead engineers change their focus from output, like writing code, to outcomes. This includes system reliability, team speed, and business value. Their focus is on the big picture. They focus on the product’s technical success. Their concerns are strategic, not tactical.
- The “Bus Factor” (Risk Mitigation)
- The Concern: “If we lose someone tomorrow, does the project die?”
- The Action: Leads obsess over knowledge silos. They push for rotating key tasks. They need documentation for complex systems. They also avoid obscure technologies that are hard to hire for.
- Force Multiplication (Developer Experience)
- The Concern: “Why does it take 45 minutes to deploy a one-line change?”
- The Action: Leads care about the feedback loop. They invest time in CI/CD pipelines, local dev environments, and linting tools. If they save 5 minutes for 10 developers, that’s 50 minutes of extra productivity per build.
- Observability & Average Recovery Time
- The Concern: “How do we know it’s broken before the customers tweet about it?”
- The Action: Seniors care that the code passes tests; Leads care that the code emits logs. They focus on metrics, dashboards, and alerting. This way, when issues arise, they can find the root cause in minutes, not days.
- Technical Debt as a Financial Instrument
- The Concern: “Are we paying too much ‘interest’ on this legacy code?”
- The Action: Leads don’t aim for zero technical debt; they aim for managed debt. They talk with product managers to “buy” time for refactoring. They explain the cost of inaction. For example, they say, “If we don’t fix this now, feature X will take twice as long to build next month.”
- Alignment with Business Goals
- The Concern: “We are building a Ferrari, but the business needs a moving van.”
- The Action: Leads are the filter between “cool tech” and “profitable tech.” They prevent over-engineering. If a basic CRUD app can solve the business problem, they will block the team from building a complex microservices architecture. Even if the team wants to do so.
- Consensus and “Disagree and Commit”
- The Concern: “Is the team paralyzed by debate?”
- The Action: Leads care about decision velocity. They lead technical talks and make sure everyone’s voice gets heard. They also finalize decisions to resolve ties, helping the team move forward.
The transition from Senior to Lead is fundamentally about trading personal output for team output. It requires letting go of the immediate satisfaction of closing tickets to focus on the often invisible work that keeps the system healthy and the team moving. By prioritizing business alignment, risk mitigation, and developer experience over technical perfection and personal commit counts, a Lead Engineer ensures that the team doesn’t just ship code, but delivers sustainable value.
- Personal Commit Volume
-
Anti-AI Hype
Simon Willison’s response to Don’t fall into the anti-AI hype
I’m glad someone was brave enough to say this. There is a lot of anti-AI sentiment in the software development community these days. Much of it is justified, but if you let people convince you that AI isn’t genuinely useful for software developers or that this whole thing will blow over soon it’s becoming clear that you’re taking on a very real risk to your future career.
Don’t fall into the anti-AI hype
Whatever you believe about what the Right Thing should be, you can’t control it by refusing what is happening right now. Skipping AI is not going to help you or your career.