Posts

React 18 shipped in March 2022. We merged our upgrade in April 2026. If you do that math, yes, we were four years behind. This is a post about what that upgrade actually looked like across a large, multi-generational codebase, and the specific issues that ate most of the time. Spoiler: the “breaking changes” in the official React 18 migration guide are the easy part. The Starting Point Our frontend isn’t one app. It’s four generations of React code living in the same monorepo, piled up over years of product growth: ...

AI coding assistants keep hallucinating EUI props. You paste in documentation, it gets ignored thirty messages later. You end up debugging code where half the props don’t exist. The fix is an MCP server, about 200 lines of TypeScript that gives any MCP-compatible AI direct access to the EUI source. What EUI is EUI (Elastic UI) is Elastic’s open-source React component library. It powers Kibana and the rest of the Elastic product suite. The library is large, over 100 components spanning basic buttons and forms, complex data grids, drag-and-drop interfaces, and charting primitives. Each component ships with TypeScript types, MDX documentation, and Storybook stories. ...

You know that feeling when you open a PR and it’s 47 files changed, 3,000 lines? The reviewer sighs, skims it, leaves a comment like “looks good,” and merges it. No real feedback, nothing caught. That isn’t code review, it’s rubber-stamping. Stacked PRs are a way out of that trap. The Basic Idea Instead of one massive PR, you break the work into a chain. Each branch builds on the previous one, and each PR targets its parent branch rather than master directly. ...

If you’re applying to hundreds of jobs and hearing nothing back, it probably isn’t you. The way the funnel is set up works against you. Big companies dominate job boards like LinkedIn partly because they pay for placement. A single listing at a well-known corporation can pull over a thousand applications, and a lot of them get auto-filtered before a person ever looks. Even a strong resume struggles to surface in that volume, especially for roles that often get filled internally or through referrals before the public pile is touched. ...

Most development sessions start with the same chore: bring up the backend, start the frontend build, open the database, get version control where you can see it. Before any actual work happens, a few minutes go to setting up the workspace. My setup gets rid of that. It runs almost entirely in the terminal, using tmuxp to build the session and a handful of tools for editing, file management, and version control. Once it’s configured, starting work is one command. ...

As a web engineer doing full-stack work, I’ve spent years inside the AWS ecosystem. EC2, DynamoDB, Redis, Lambda, API Gateway, and S3 are part of my daily toolkit. I was comfortable building and deploying on them, but I also knew there was a lot of AWS I’d never touched and a lot of architectural reasoning I’d never had to do explicitly. So this year I set myself a goal at work: pass the AWS Certified Solutions Architect – Associate exam. I wanted to go deeper on the services I only knew at the surface and get better at designing whole systems rather than wiring up the parts I already knew. I passed the SAA-C03 on my first attempt with a score of 903/1000, and this is the plan that got me there over about nine months. ...

I keep noticing that most of what I read online is worse than it used to be. There’s more of everything than ever, but it’s thinner: more articles that say nothing, more confident voices with no expertise behind them, more pages that exist to rank rather than to be read. I wanted to work out why, because I don’t think it comes down to one thing. Anyone can publish now, and that changed the filters For most of the last century, getting something published was expensive and slow. A publisher, an editor, a fact-checker, and a typesetter all stood between a writer and an audience. Those people were a bottleneck, and they were also a filter. Plenty of good work never made it through, but most of what did had been checked by someone whose job was to check it. ...

In a microservice system, the only real way to know how resilient you are is to break things on purpose and watch what happens. That’s the idea behind chaos engineering. Netflix’s Chaos Monkey is the famous example: it randomly kills services in production so the team finds out early whether the system can take it. Killing live services is overkill for most teams, especially outside production, but the underlying idea is worth borrowing. So we added a small piece of middleware to one of our services: a manually triggered, route-level failure tool that acts like a baby Chaos Monkey. ...

Designing clear, well-documented web APIs is a big part of building software. The most widely adopted standard for describing RESTful APIs is OpenAPI, a machine-readable format (usually JSON or YAML) that defines an API’s structure, endpoints, and request and response shapes. That schema becomes the single source of truth behind your interactive docs, client libraries, and server stubs. However, writing and maintaining OpenAPI specifications by hand can quickly become a chore. The syntax is verbose, and small mistakes in the structure can lead to frustrating bugs or inconsistencies across different parts of the system. ...

Our App was created in 2017. It is a React application written in TypeScript. At the time, TypeScript was gaining popularity, but strict type safety wasn’t a major concern for most teams. Our knowledge of TypeScript was limited, and the primary goal was to use it for basic type annotations rather than enforcing a fully type-safe codebase. As a result, strict mode was never turned on. The codebase ran without the safeguards strict mode brings: strict null checks, no implicit any, and tighter type inference. As the project grew, that gap started to cost us. Subtle bugs slipped through, and refactoring carried more risk than it should have. ...