Recent content on eval ( code )
The strongest hiring signal isn’t the resume. It’s whether you are willing to make the repeated investment mentorship requires: context, feedback, hard conversations, and real curiosity about how someone thinks.
The ‘AI replaces junior engineers’ argument ignores basic economics. Junior employees aren’t just cheap labor. They’re salary insurance, pipeline protection, and the only hedge companies have against a senior workforce that increasingly doesn’t need the job.
The best engineers know how to read the room. This is not really an engineering problem, it’s a people problem. The engineers people trust most are the ones who know when to reassure, when to stay quiet, and how to make others feel understood.
Everyone assumes AI will replace most jobs within a year. The technology might be ready, but the economics aren’t. Data centers, power grids, and component costs don’t follow Moore’s Law. When demand outstrips infrastructure, token prices go up, and companies start doing the math on AI versus people.
AI makes ‘one more prompt’ irresistible. The next feature is always ten minutes away. The hardest engineering skill in the age of AI isn’t building. It’s deciding when to ship.
AI makes writing code so cheap that iterative enhancement stops making sense. Instead of refining small slices, teams are regenerating entire features and iterating on the whole thing. Agile isn’t dead, but its assumptions are bending hard.
After maintaining an authentication library with 125 million downloads for over a decade, here’s what I learned about the real cost of auth: it’s not the build, it’s the maintenance nobody plans for. And no, an AI agent monitoring your dependencies isn’t the answer.
AI made code cheap. The bottleneck was never the code. It was scoping, estimation, and communication, the skills teams treated as optional for years. That bet no longer pays off.
Constants feel clean until six files break when you rename a hash key. Class methods give you the same performance with an API boundary that survives refactoring.
Deep linking looks simple until it breaks in production because three teams own different pieces of it. Here’s the Phoenix server-side setup, including the content-type gotcha that will cost you an afternoon.
A Makefile trick that auto-populates the ngrok hostname into your Phoenix dev server. Small dev-environment friction compounds across a team faster than you’d expect.
The habits that made you successful in an office will hurt you when you go remote. Here’s how to replace observational communication with written communication.
Rails partials rot fast once multiple views depend on them. local_assigns is a forgotten built-in that handles optional variables without the nil-guard sprawl.
Server-side render Elm applications with Phoenix using a STDIO-based IO server, similar to the React approach.
Server-side render React components with Phoenix using react-stdio and OTP for isomorphic Elixir applications.
Use Guardian to manage multiple browser sessions in your Phoenix app, such as separate user and admin logins.
Embed permissions into JWT tokens using Guardian for fine-grained authorization in your Phoenix application.
Set up API authentication with Guardian in your Phoenix application using JWT tokens.
A straightforward guide to setting up browser authentication in your Phoenix application using Guardian.
A bug report has one job: give someone enough info to reproduce the problem without asking follow-up questions.
A relatable analogy that frames the rest of the handbook: expectations, estimation, negotiation, and what ‘done’ really means.
A short daily check-in to surface blockers and keep the team focused on the same goal. Not a status report.
Office habits break when you go remote. Here’s what to replace them with and why every other practice in this handbook depends on it.
A PR description isn’t for you. It’s for the person reviewing your code. Make their job easy.
How to break a problem into features that are small enough to deliver, clear enough to estimate, and valuable enough to justify the work.
How to run a planning session that produces a clear, committed backlog with known decision makers.
The project lead’s daily checklist for making sure the board reflects reality and nothing is quietly falling apart.
Force yourself to articulate the problem before jumping to a solution. The proposal starts with the problem.
The team’s primary self-improvement mechanism. Useless without action items; powerful with them.
A simple 0-3 pointing scale, how to run a session, and why you’re measuring confidence not hours.
The fundamental unit of work on the board. What the team is building, why it matters, and how to verify it’s done.
The board should answer ‘what are you working on?’ in 30 seconds. Here’s how to set it up and keep it honest.
Serial founding engineer who has built teams from zero to exit at multiple companies. Senior Staff Engineer at Shopify. More than a decade of remote engineering leadership.