Here is my full chat with David Heinemeier Hansson (@DHH), creator of Rails, CTO of Basecamp, NYT bestseller author, and professional racing driver 🏎️
We discussed David's opinions on the current state of software, including excessive complexity, the role of AI, and the future of open source.
We also talked about his racing and how he approaches learning any topic from scratch.
I put it here on X in full, and is also up on Youtube, Spotify, and all podcast channels.
Chapters:
02:20 Introduction
03:42 Merchants of Complexity
13:19 Innovating the dev experience
21:53 Complexity in small projects
28:14 Incentives hurt open source
32:49 Subscription vs ONCE
35:24 David and AI
47:27 Using AI as training wheels
49:42 The art of learning
• • •
Missing some Tweet in this thread? You can try to
force a refresh
I believe 80% of performance is systemic, rather than individual. So, with underperformers, it is useful to ask yourself questions about the *context* they are working in.
Here is a 15-items checklist I built for this over time 👇
🌟 Culture
1. Are they aware of the company values? 2. Are they aware of the company vision and purpose?
🔄 Systems
3. Do they know what is expected of their role? 4. Are they assigned to a role/work that isn’t suited to their skills? 5. Are they let down by tooling / DX?
Bug fixing is not exactly everyone's favorite engineering activity.
It's a tricky process that requires coordination between several stakeholders — PMs, Customer Support, QA, and Engineers.
Let's figure out how to make it work 👇
Every team has a slightly different process, but it always involves some version of these steps:
1) ✍️ Report — bugs are entered in some kind of backlog. 2) 🚥 Prioritize — bugs are triaged and a priority is assigned. 3) 🔨 Fix — bugs are addressed and fixed by Engineers.
Out of these three, I have seen the most problems happen in the *prioritization* stage.
👑 Who takes such decisions?
⚔️ How do we avoid conflicts?
⏱️ How much time should we spend on it?