Marco Garofalo (マルコ) 🇺🇦

I just had a conversation with a wide-eyed idealist programmer who was working alone (using an AI, but that's still alone) creating an app. He had no customers, not even potential ones, just a "great idea!" He'd spent months (and burned through savings) building this thing and had never had a single human being look at it, much less validate the idea. He was using an AI for that, and it was feeding his delusion. I'm sorry, but unless the AI is going to buy your product, its "validation" is worthless. Programming (or more precisely, product development including the technical aspect) is a social activity, impossible to do in isolation. Even if you are the sole programmer, you still need to collaborate with potential customers. Something like 90+% of startups fail. The unvalidated "great idea!" delusion is one of the big reasons for that. Nobody can go it alone. Talk to people. Get some help.

You do not build trust through estimation. You build trust by delivering. I've found that once I start delivering something small but useful every day or so, people stop asking for estimates. Managers no longer need estimates and milestones to monitor progress because they can see the progress with their own eyes. Every day. Transparency trumps opaque process every time.

I was told that, of course, Agile is all about project management because that phrase appears in the Manifesto. The Agile Manifesto was written a quarter century ago. How agile would we be if we hadn't learned and adapted over those 24 years? Back then, everybody thought in terms of projects. The notion that a product focus was better appeared on the scene about 7-8 years ago, if I remember correctly, and it's now dominant. In fact, the Manifesto signatories that I know don't use "project" anymore. Similarly, we've learned to deliver work every few days—a "couple months" is now considered suboptimal. Very few orgs outside of megacorporations or government contractors create "comprehensive documentation," and they're not in the least bit Agile. So, the details have changed a bit, but the thinking that underlies the values and principles is still quite valid (and valuable). To me, an Agile shop embodies that core thinking. In any event, the Manifesto was never intended to be anything other than a snapshot in time. It was never intended to be fixed-in-concrete doctrine. To be Agile, you need to be—agile;

Nobody wants data (particularly in tabular form). Everybody wants answers to questions. Don't foist the work of figuring out the answer onto your users. The best software gives them the answer, often with no data in sight. There's a middle ground of showing the graphs you need to get the answer, but that's still not providing an answer. Do the work. Don't present the wherewithal to do the work.

You can argue all day about what customers want or need, what they'll love or hate, but if you don't ask them, you know nothing. Guesswork has no place in product design (unless it forms the basis of a controlled experiment like an MVP that you'll validate with actual conversation & feedback).

As for putting one of those mythical 10x programmers onto an average or low-performing team, local optimization doesn't work unless you're optimizing at a bottleneck/constraint. It's the speed of the entire system that matters. A trail runner in the middle of the pack who can run 4x faster than everybody else will slow down when they bump into the slower person in front of them. In a software-development system, what matters is when the last person crosses the finish line. Form a team comprised entirely of high performers and then put them at the bottleneck. Everywhere else, they're wasted. Better yet, put them to work teaching others how to become "high performing."