Prioritize Aerodynamic Version One for Streamlined User Experience

Key Quotes

"I want version one to be the most aerodynamic version of this thing that we're making and that every little extra thing sticks out you know it just like sticks out of this object and screws up the airflow so version one should just be extremely aerodynamic like what is the tightest smoothest shape of a product we can make that's kind of how I tend to think about it now or I've been trying to think about it that way now and so part of this is like when you use something that you're building and you go through it and you keep going through it as you near the launch like do we need that little thing is that thing creating drag do we need that and you try to get rid of all the little burrs and all the little things that are just getting in the way and that to me is how you do it so it's about smoothing this object out not saying that like we can't add stuff later but version one has got to be very very aerodynamic so that's how I've been thinking about it"

Jason Fried explains that the goal for version one of a product is to make it as "aerodynamic" as possible, meaning it should be streamlined and free of unnecessary elements that create "drag." He suggests that this approach involves identifying and removing any "burrs" or features that hinder the core functionality, emphasizing that additions can be made later.

"This harks back to one of the very first principles we penned down on product development which is half not a half assed that the half that's left after you smooth everything out is invariably likely to be better than if you have a bunch of stuff that you didn't have time to smooth it all out that's all a little rough and I often look at these products that managed to do that half not a half assed thing which is such an admiration"

David Heinemeier Hansson references a core product development principle of creating a "half not a half assed" product, meaning the essential parts, when smoothed out and refined, are superior to a product with many features that are not fully polished. He expresses admiration for products that successfully embody this principle of focused refinement.

"I have this recurring model going like do you know what if you were 20 years old you'd laugh at yourself right now and the other part goes like yeah that's right that's the process of aging you start appreciating new things different things and I now appreciate trees and I appreciate smelling flowers and I really uniquely appreciate polishing code"

David Heinemeier Hansson reflects on how his appreciation for certain aspects of work has evolved with age, comparing his current enjoyment of simple things like trees and flowers to his past self. He specifically highlights a newfound and unique appreciation for the act of "polishing code" as a source of satisfaction.

"The other thing for me is I've been reading through the whole fizzy codebase we've had a wonderful team working on it I have not been writing the majority of the code I've done some of the early work on it and then I did a bunch of other things for a long time and the team did great work on it and then I get the privilege of sitting down and reading this thing like it's a book end to end and just going like oh man I really like this uh you know what this part maybe uh could use a little do over and I I love that polishing that editing phase it's like when in the rare circumstance I have the patience to put an essay aside instead of just fucking hitting publish on hello world as soon as I've written the last character which is my normal mo"

David Heinemeier Hansson describes his process of reviewing the codebase for "Fizz," comparing it to reading a book and identifying areas for improvement. He expresses a fondness for this "polishing" and "editing phase," contrasting it with his usual tendency to publish work immediately without extensive revision.

"The code has drag in very much the same way as the product itself does and you can see that smooth surface sometimes in fact when I'm reading these things a favorite tactic is you know what I lean back and I halfway squint at the code and sometimes I can just see you know what that's not the right shape there's just too many lines up here in this method and it's using too many other things there's too much indirection where's this thing referencing from I don't have this piece of context now that I'm reading it that needs to be better and the act of polishing and massaging the code in this way is actually one of the my favorite parts of writing code at all"

David Heinemeier Hansson draws a parallel between the concept of "drag" in a physical product and "drag" within code, suggesting that code can also become inefficient or difficult to understand. He describes a visual technique of squinting at code to identify areas that are not optimally shaped or too complex, indicating that polishing code is a favorite aspect of his programming work.