Scott Hanselman (Microsoft)
Twitter can be a toxic dump for ill-informed and ill-mannered opinions. It’s also where Microsoft’s Scott Hanselman hangs out, sharing wisdom from his decades in software.
Hanselman isn’t one to preen, so sometimes it’s easy to miss a gold mine when he shares it. Like, for example, maybe you want to understand how he knows stuff. How he has become deeply familiar with key technologies. Was it through school? Or perhaps an open source project? Or maybe some work assignment?
Although each of those approaches has likely deepened Hanselman’s understanding of tech, he gives a much more basic response: “Run real sites and scale them.”
Who knew it could be so easy? Actually, that’s his point: It’s not. The more we build, the more we learn how to build. As Hanselman summarises: “This is the tip. Not tutorials. Make a thing. Register the domain; get the cert; get an A on security headers; submit it to a store; fix SEO; add Open Graph, features; make a PWA. Run a site 24/7. This is how I know stuff.”
As useful as building stuff is for learning how to build great software, Honeycomb’s Megan Gleason hopes that you’ll stop building so much software in the first place. Why? Read on.
Build less; do more
Hanselman advocates learning by doing, even as Gleason argues against writing new software in the first place. Of course, when Gleason declares that we should “BUILD LESS SOFTWARE,” she’s not disputing the value of software. Far from it. Instead, she’s pointing out that, “Centring too much on adding new functionality will break your product, your users, and your team. Maybe your business.”
That seems bad. It is bad.
Instead, Gleason argues for more software maintenance instead of software development. “Features are not the sole driver of product value,” she says. Indeed, “Quality almost never comes from new capabilities — usually adding stuff makes things worse for a time.” Where does that software quality come from? “It comes from the quiet work of tending the garden.”
The problem, Gleason says, is that “gravity will always pull you toward building more.” Not just more, but more built ever faster as customer requests pile up, with little time for software quality along the way. The problem is that customers don’t necessarily demand that quality — they want features.
“No prospect tells you they’d buy your product if only you’d complete that JS to TypeScript conversion or finish your design system.” Eventually, all this technical debt weighs down new feature development. By the time customers notice your reduced velocity, it’s too late. She concludes, “If you continue to crank out features without regard for the other dimensions of product health, enduring value will elude you.”
It's not just you
This brings us to a more meta discussion of how we fix this, courtesy of Talabat’s Dragan Stepanović, who asked developers to pinpoint the source for their company’s biggest software deficiencies. “When you look at the code bases in the company you work with, is the lack of knowledge of algorithms and advanced data structures the biggest and most pervasive problem that you see? I’d assume not.”
What is the problem developers tend to see? And is it nearly always about good software hygiene, á la Gleason?
First, from Ian Cooper, a reminder of just how critical documentation can be: “Writing code that does not account for [the reality that] someone else will need to understand it, … change it, … [and] own it” is incomplete, he argues. “You will move on; your code will remain.” Or, as I’ve written, “If you don’t have good docs, you shouldn’t ship.”
Echoing Gleason, Adam Hisley calls out a lack of focus on the maintainability of software. In his opinion, ensuring “graceful/easy-to-monitor-and-trace failure is one of the elements of software quality that I find most reliably translates into real business value but can often be lost in the rush to build features.”
Jakub Kočí adds, “The biggest problem is clarity. We’re writing code for humans first, not for machines. Making it work is just a half of the solution, making it well-structured and maintainable is another … often more difficult part.”
This brings us back to Hanselman. One of the things developers would learn from building their own site or application is the importance of hygiene for easily maintaining it. Unfortunately, based on the responses to Gleason’s and Stepanović’s threads, such maintenance seems the exception, not the rule.
