Metaengineering on jeffcarp

Thoughts on Helix

Mon, 12 Jan 2026 00:00:00 +0000

I’ve been a die-hard vim user for 12 years. But recently, inspired by posts from Julia Evans and Felix Knorr, I have been trying out Helix–a relatively new terminal-based editor written in Rust–and I’ve been pleasantly surprised by the experience.

Things I like

It’s snappy! Even though some of the command flows have changed, I can still get around the editor using my old vim muscle memory.

Recruiter Autoreply Bot 2

Mon, 22 Nov 2021 00:00:00 +0000

Let me state the obvious: recruiters aren’t actually sending most recruiter emails. They automate it with software. However, the recipients of recruiter emails must spend real human time either responding to or ignoring these emails. Unfortunately just ignoring the emails triggers more followup emails (they usually come in sets of 3). This adds up to a lot of wasted time.

Background

Back in 2019 I created a bot that automatically responded to recruiters I tag with a certain label in Gmail. The way the bot works is:

Setting Up a Recruiter Auto-reply Bot

Wed, 05 Jun 2019 13:16:00 -0700

If you’re a software engineer, you’re likely familiar with unsolicited emails from recruiters. Most are probably template emails. Some of them are funny, some are thoughtful, and some of them ask you to move 3000 miles, take a 50% pay cut, and code in a language you don’t know.

Impact

Recruiter emails have a measurable impact on productivity. If I were to hand-write a response to each one (taking 2 minutes), and I got 1 recruiter email a day, that’s 12 hours of work, or more than one full work day of each year… gone.

A Year of the Pomodoro Technique

Tue, 29 Jan 2019 15:19:10 -0800

The Pomodoro Technique is method for improving productivity by segmenting work into 25-minute intervals. You focus intensely on a task for 25 minutes, then take a break. Rinse, repeat.

I began using the technique to study for the cryptography course I took last winter. The benefits were clear from the beginning. I enjoyed working in 25-minute segments and started using it at work as well. I want to share with you some of the things I learned along this year-long journey.

Inspired

Sat, 19 Jan 2019 17:07:11 -0800

Inspired is a great introduction on how to be a Product Manager by Marty Cagan, a former engineer turned product expert. Here’s one of my favorite themes of the book:

Product: build the right product
Engineering: build the product right

Here are the most poignant things I learned from this book organized by category.

Product team structure

It’s important to have somebody between product marketing and engineering (i.e. the product manager). Otherwise UX gets skipped and the TL has to figure out what to build, which is a bad recipe for product-market fit.
Also a bad idea is to let sales direct engineering, if you do that you get features, not products.
Most product orgs are basically feature factories… don’t be like that.

Engineering management

Run product management and design in parallel with engineering - the PM and designers should always be 1-2 sprints ahead of eng.
To combat tech debt, give the engineering team “headroom,” i.e. 20% of resources to do with it what they want.

The importance of prototypes

It’s really important to take an engineer or two and create usable prototypes during the discovery phase. Otherwise most startups use their entire eng process and release cycle to ship experiments in order for product to iterate. This is why it takes 1.5-2 years for most companies to find traction, and why many startups fail
Cagan argues that making a full mock with all intended functionality not only is preferrable, but will actually let you ship faster by reducing risk later in engineering.

General product management

Software projects have two stages: Discovery (build the right product) and Execution (build the product right). After the discovery phase ends, the product spec needs to be locked down otherwise changes create “churn.”
Don’t rely on your manager as a mentor, it’s not their job.
To prevent surprises and make sure meetings with lots of high level stakeholders run smoothly, reach out to them beforehand to get them on board.

I thought this book had some fresh things to say about confidence. Frequently confidence is looked upon negatively in tech—something that MBAs who don’t know what they’re talking about have. But I really liked Cagan’s take on it:

Unforseen Perks of Pair Programming

Sun, 15 Jun 2014 19:03:46 +0000

As someone who had never pair programmed before, it was exciting to get thrown into the deep end during my first week at Braintree where engineers pair nearly 100% of the time.

The relative merits of pair programming have already been spoken about at length.^[1]^[2] This post is not an attempt to argue one way or another. Whether it works for any organization is probably too context-dependent for any axioms I could lay down.