Judging by posts I've seen, it's time to talk about MVPs. There's a lot of misunderstanding of the notion. People take the acronym too literally. There are two definitions of MVP. The earlier one was coined by Frank Robinson, and aligns with what people think (that the MVP minimum product), but the more useful definition is the one Eric Ries describes in his book "Lean Startup." I think of Ries' MVP as:
the Minimum thing that tests the
Viability of a
Product idea.
It is not version 1.0 of your product. It's not a product at all, in fact. It's a test. If the test passes, the idea is viable, and it might make sense to build v1.0. The whole point is to not waste time building something nobody wants.
Notice that my definition didn't say "the minimum thing you can build" because the ideal MVP doesn't require any building at all. The MVP for DoorDash was pizza delivery, which tested the viability of home food delivery. No coding required. A second MVP might test online ordering with a single-page site featuring a minimal menu for a single restaurant. The MVP wouldn't process any orders—it would just forward them to a human, who would handle everything else. Again, the idea is to test the viability of a product idea, NOT to build a product. The MVP is a precursor to building. Only after those two tests (MVPs) gave you satisfactory results would you consider building something real.
MVPs must be very small. In one of his online talks, Ries suggests that you come up with the smallest possible set of features. Then cut that in half, then cut it in half again, then cut it in half one more time. Put in terms of testing theory: test only one thing at a time.
The next issue is quality, and there are two schools of thought. One is that you want to get the MVP into your potential customers' hands as quickly as possible, so using Vibe coding or sloppy manual coding to create a throwaway MVP is fine. The key concept in that last sentence is "throwaway," though. This approach effectively bets that the idea will fail, so you want to expend the least effort.
The second school looks at the MVP as the core part of a walking skeleton (the beginning of an iterative development process). Here, you're betting that the idea will work. Given that the MVP will be at the core of a real system, it must be high-quality. The feature set is very minimal, so the MVP still comes together very quickly, but the code is real, production-quality code. My experience is that high-quality code goes together faster than low-quality code, so the quality actually helps.
These two approaches cannot coexist. It's a disaster in the making to use a low-quality MVP as the core of a walking skeleton. You'll never overcome the corruption of the putrid core.
So, I'm a huge fan of the (Ries-style) MVP approach. The best way to get a product to your customer sooner is to not waste time building features they don't want. The MVP helps with that.
@rfleury Never thought of helper f-ns as code compression, you still have all the same stuff elsewhere. Not to say it's useless.
For the compression exercise ypu mention, I like to add a twist "...and make it easier to understand", which unlocks a whole new level to it.
@IKEALatvija kas tas par idiotismu, ka uzreiz pēc pacelšanas pa eskalatoru nav pilnīgi nekādas iespējas atgriezties atpakaļ, neizejot cauri visam veikalam?
I believe we'll see a wave of burnout caused by agent agentmaxxing. Spin up an agent in background to do a chore while you focus on important bits! Run it overnight to try and fix something! It all adds open loops and stuff to come back to. There's no leverage without a cost.
@MaximChistov@Merridew__ But that's beating the market by definition. If you underperform by 1-2% for 5 years and then are only down 20% when market is down 5%, you won.
@TheGracia_here You do sprintf into a preallocated buffer, move the buffer allocation to be inside the loop and you shall get ~same results between printf vs sprintf+write. It's apples to oranges here.