erik.wiffin

I spent the holidays building an event platform with an AI “vibecoding” tool to see if the results were actually production-ready. While the speed of development was incredible, my audit reveals the critical gaps—from database safety to broken SEO—that still need a human touch before you hit publish.

With large language models capable of generating convincing documents without real thought, this insightful article explores the critical need for new “Proofs of Thought” to ensure genuine intellectual engagement and prevent workplace processes from becoming mere facades.

A collection of blog posts and resources that I’ve found useful and frequently refer back to. Death by PowerPoint: the slide that killed seven people How to Socialize Big Changes at Work A Rubric for Evaluating Team Members’ Contributions to an Inclusive Culture The Ultimate Burnout Guide: Symptoms, Causes, and Prevention The Boy Scout Rule ~Robert C. Martin (Uncle Bob) Nordstrom’s Employee Handbook Has Only One Rule How Big Tech Runs Tech Projects and the Curious Absence of Scrum Don’t be spooky Scaling Engineering Teams via RFCs: Writing Things Down The Blue Tape List Questions for our first 1:1 How to Do Code Reviews Like a Human How to Make Your Code Reviewer Fall in Love with You The Kindly Brontosaurus World’s 15 Biggest Ships Create More Pollution Than All The Cars In The World Taboo Your Words Making it Virtually Easy to Deploy on Day One The Picasso Principle The Elves Leave Middle Earth – Sodas Are No Longer Free

I have always hated the phrase “Don’t bring me problems, bring me solutions!”. It feels lazy. It incentivizes people to sweep things under the rug if they can’t figure out what to do. It doesn’t give any useful direction to the person bringing you problems, because if they had solutions, they probably would have brought them already! At its best, it’s unhelpful, at its worst, it’s actively harmful. I have similar, but less strong issues with the idea of telling someone to “take more initiative”.

The demands on a manager’s time are endless and sometimes it feels like you’re being pulled in every direction at once. These demands can make it hard to focus, they make it hard to move from reacting to problems to anticipating them. In this article, I’d like to talk about how I’ve limited demands on my time, counterintuitively doing more with less. The story The very first thing I learned as a new manager was that if I didn’t put a block on my calendar at lunchtime, there was no guarantee that I would eat lunch that day.

As a Director of Engineering, I have monthly 1:1s with all of my direct reports. A 1:1 (one-on-one) is a recurring meeting with no set agenda between a manager and one of their reports. The internet is full of valuable insight into how to run them from my perspective, (ex. The Update, The Vent, and The Disaster) but somewhat more limited in advice on how to make the most of them if you’re on the other side of the table.

In this article, I will explain why I think Stripe should start treating health insurance cards like any other 3.3”x2.1” pieces of plastic with 12 digits on them and take their slice of a $4.1 trillion industry. The situation Outpatient billing is expensive and unpleasant. According to a study published in 2017, doctors spend 21.8% of gross receipts on it. That means over 20 cents out of every dollar that comes into an outpatient practice gets spent on insurance-related administrative overhead.

Or: Why is this software engineer being so difficult? So you’ve got some data. In my case, I’ve been keeping track of how successful my taco truck has been. There’s nothing crazy here: a date column, how many of each kind of taco I sold, and where I parked my taco truck that day. At this point, I’d like to create some sweet visualizations of my data, to better understand the fundamentals of my taco truck business.

When confronted with a complicated task, the first response of any developer is to dive in and start coding. This is precisely the wrong thing to do. I might sound hyperbolic, but it’s true. Every single design plan I have ever seen has resulted in a better understanding of the problem, and more importantly, a better solution delivered faster. What is a design plan? A design plan is a short document describing a proposed implementation of a new feature or refactoring.

The only way to perfectly estimate how long a task will take, is to do the task and measure how long it took. In most situations where you’re endeavoring to produce an estimate, this is not a practical way of providing it. At the other end of the spectrum, you can pick a random number and base your timeline on that. While this is a quick and easy way of coming up with an estimate, it is rarely helpful.