David Hoff-Vanoni

2025 hot take: I'm not sold on Test-Driven Development (TDD). After years in the industry, I’ve seen few teams fully commit to TDD and even fewer stick with it long-term. I’ve been on teams that have completed projects with TDD and ones that started with TDD but dropped it when it became more of a blocker than a boost. The biggest untold truth? TDD success stories often come down to survivorship bias. The teams that succeed with TDD would likely succeed without it, too. Why? Because the teams that have the most success with TDD are usually made of senior engineers who’ve built similar systems countless times before. Here’s how I see it: If you’ve studied for a test so well that you could write both the questions and the answers before you take it, you’re going to ace that test no matter what. In essence, TDD works best when you already know the answers. But really then TDD isn't the main or even a contributing reason for a project's success. What do you think? Is TDD overrated or am I missing something?

368

326 Comments

‘In this episode of “The Engineering Room” Dave Farley chats with renowned author, speaker and expert software developer Kevlin Henney.’ https://lnkd.in/gsenvBMQ ‘In their wide-ranging discussion they talk about: • Why Kevlin Henney is famous for big public software failures! • Software Engineering, mathematics and the interesting gap between formal programming and sloppy humans. • Architecture, empiricism and three ideas for design. • Coping with incomplete knowledge and making stuff that works in the real world. • Confidence, certainty and loose-coupling. • Learning from actual failure, not just simulation. • Programming is deceptively easy to start, and gets complicated really quickly: Low Code is no exception.’ Continuous Delivery Ltd Bernard McCarty #ContinuousDelivery

21

"You can have a great strategy for the next billion-dollar developer product, but the battle is won in the trenches of daily iterations." I love this clip from Lee Robinson (VP Product, Vercel). Lee helped scale Vercel to 1M+ developers and has some of the clearest thinking of developer marketing that I've read. We talked about: - Getting into the developer's mindset - 3 pillars of a great developer experience - Why developers don't trust your marketing A few quotes from Lee: "Most developers don't adopt a tool the first time they hear about it. It's probably the 10th time." "Great documentation is great writing. The tech industry is plagued with jargon and fluff. It would be much cleaner if people wrote more like how they talk." "The battle is won in the trenches. It could be a two-paragraph docs change or a small UX improvement. For every developer that complains, 100 more won't say anything." 📌 Watch now: https://lnkd.in/g-g-u3E5 Also available on: Apple: https://lnkd.in/grhhYVyh Spotify: https://lnkd.in/gGyvBKmX Newsletter: https://lnkd.in/gGkkYG4M

115

3 Comments

If you are into Frontend development, this is a really cool survey: https://lnkd.in/g7scsiF9 A few highlights: - React is a clear winner with nearly 70% usage - Typescript is having a blast, which is great news (94% of frontend developers have used Typescript in the last year) - Majority of React users seem to use it together with Next.js - Angular seems to be going down - Node is the runtime of choice (96%), while Deno only has 2.6%

15

Have you ever wondered how video game Auto-Tiling in games works? Excalibur.js contributor Justin Young is on🔥with this latest post about authoring tile maps with aesthetically pleasing tiles! The algorithm is surprisingly grokkable and low effort to implement 🤯 https://lnkd.in/gsVHwc5V #gamedev #typescript #javascript

4

3 Comments

As a long-time Line 6 Helix user, I found this interview with its architect Eric Klein really interesting. Much good talk about user experience and usability. "If somebody tells you there's a problem with what you're offering them, they're almost always right. But if someone tries to give you a solution to that problem, they're almost always wrong." Chimes strongly with my experiences over the years. Address needs. Solve problems. Taking feature requests from users is how products can die.

6

this meme led to an interesting convo: friend: Borg are perpetually in a build phase. never take a step back to fix the cables. me: That's a lot of technical debt. friend: can you imagine how they just "hack together" a species's technology into their own stack? me: To tech folks, that kind of software assimilation is more frightening than actual assimilation. Imagine if they kept you human just long enough to complete the integration into their Frankenstack. You'd be *begging* to be assimilated.

3

2 Comments

I once asked a lead engineer on Angular: Which is better: Angular or React? His response: "Both require good engineering to be effective." So, my developer friends, consider this a reminder that "frameworks" like Diátaxis are fine, but they still require good engineering--such as UX, information architecture, style, maintenance processes, and so on--to create great documentation experiences for your customers. Alas, the framework alone isn't enough.

35

7 Comments

Some unconnected thoughts on this “ghost developers” panic: Despite tech being a major economic driver for a couple of decades, MBA programs, and therefore the state of management thinking, are rooted in manufacturing. The mindless drive for efficiency in all kinds of businesses makes the most sense if you’re talking about factories and logistics. Not so much for knowledge work. Software is the only huge field where “R&D”, “production” and “services” are collapsed into one big undifferentiated mass. The output of product development is code shipped to production, and it needs to be continually maintained and updated. The closest thing software has to a manufacturing model is offshoring engineering to eg India or Eastern Europe, while keeping design and product/eng leadership in the US, but that creates ongoing problems because you can’t just hand off specs to India for manufacturing and move onto the next launch. Offshore teams need ongoing support because the customers need ongoing product support. Because engineers produce the actual shipping product, while they’re closer in spirit to fellow managers/leaders or an R&D team, the manufacturing mindset can only really make sense of engineering as the factory floor, and MBAs’ whole thing is looking for ways to extract extra pennies by optimizing manufacturing and distribution. They can’t actually do that with software, but they aren’t technical enough to know that, and it doesn’t stop them trying. So, “ghost developers” — which, of course, is just engineers writing good docs, being in meetings, talking to customers, supporting each other with code reviews or pairing — seems like gross inefficiency because it looks like a factory producing fewer LOCs than companies are paying for. Remember how, when Elon took over Twitter, we’d hear about him asking coders to _print out_ their latest contributions to the codebase, and if the pile was too short they got fired? Elon is a manufacturing guy, not a software guy. Even the “Stanford researchers” part is MBA culture gone wild — they have _no idea_ what’s involved in making software, and can’t even talk to their teams effectively, but they think their dumb mindset is “science” and now they have “research” telling them they could fire half their teams and be more productive. 🫠

1

Having a ton of fun writing an ORM for V2 of Case Kit. Typescript has such an incredible type system. I have autocompletion for column names, the ability to include relations, relations of relations, etc etc etc... all returning properly typed data (no classes in sight). It's been really satisfying seeing it coming together, and it's been great getting my hands dirty with some (relatively) complex generics. And to head off the obvious question… why aren’t I just using Prisma? Well there’s a couple of things I’m doing differently that I think are marginally better: there’s no code generation involved here, it’s just types (inspired by Drizzle); there’s no Rust binary you need to deploy, and it hews much closer to Postgres behaviour and syntax (the aim here is not to abstract away which database you’re using). But the real blocker to me using Prisma was that its extensions don’t support modifying queries of nested relations - a hard requirement for me due to the way I have multitenancy and soft deletes set up. It’s not shown in the video but the Case Kit ORM lets you write simple middleware that will be applied to every level of a nested query. Perfect for setting timestamps or adding clauses on tenant id or things like that.

21

For folks who've used copilot or other genAI tools a lot, I'm curious how good the unit test generation ends up being long term. I'd be concerned that you'd end up with a lot of test suites that verify exactly what you implemented, which are not going to be as useful as TDD cases that are more focused on the intended behavior rather than the code you wrote (which might have latent bugs to begin with)

17

1 Comment

🎉 Another small milestone this week: my FOSS, code-review-oriented interview tool CodeRev.app crossed 1000 users this week! Built with #vuejs and #nuxtjs, it's designed for teams that want a free, easy-to-use, and lightweight tool to add code reviews into the #interview process. Give it a spin for your next interview! You can check out the GitHub repo here: https://lnkd.in/eBTFV5Mx and start using it at https://coderev.app

16

If you've ever had to deal with inconsistent UX, multiple generations of design systems, and the perpetual back and forth between UI and backend developers - there's hope, you are not alone. And let me just say it out loud - there's no "full stack" development - it is simply impossible for an engineer to stay up to date on all the development across JavaScript, frameworks, Node.js, Kubernetes, Java, etc. You either have deep and somewhat narrow, or broad and shallow. These problems are quite common for everyone who has inherited an existing product (which is like 99.9% of us). This blog post by Kyle Shevlin about building a tightly-enforced composable design system resonated with me. #UI #designsystem #react https://lnkd.in/gStEWHtC

10

Check out this example of tech solving a practical, but often overlooked need. This innovative project combined an e-ink display with a web interface to help Jan's mom with amnesia. What I love most about this idea is its intentionality. It’s not just a flashy gadget but a thoughtful solution to an everyday problem. It bridges the gap between technology and utility in a way that feels human-centered, showcasing how even simple innovations can make a meaningful impact. This is a reminder we don't always need complex solutions - simple solves can go a long way! Have y'all come across similar creative uses of technology for everyday challenges? I'm especially interested in more use cases with e-ink displays around the house. https://lnkd.in/gMamFuXk

14

2 Comments

While some folks hire entire Figma design teams for their personal websites, I'm here at 6:30 AM explaining to my partner why I need a third coffee to "write stuff." 2022: "I'll share monthly insights about building companies!" 2024: checking it -> Writing consistency matches crypto winter performance 📉 But look - AI got better at English faster than I got better at writing. That's what we call product-market fit. New strategy for 2025 - Actually write 12 articles - Convince partner these dawn coffee raids are essential business ops Track my progress (or lack thereof) here: https://lnkd.in/e6bkkxvH P.S. If my partner reads this - yes, this is exactly what I'm doing at 6:00 AM either wiring or reading the book. Note: Will open source my coffee consumption metrics in Q3 2025. Full transparency, like web3 promised.

30

1 Comment

The entire plot of the Iliad is like one big code review gone bad. You just spent the better part of the week painstakingly building out that killer new feature. In fact, it's some of your best engineering, the unit tests are a work of art, and the function names would make Uncle Bob proud. But not so fast! The next thing you know your work is completely ripped apart by someone more senior. This is what sparked the rage of Achilles! Agamemnon used his opportunity to save the Greek army as a means to assert his dominance over Achilles, rather than leading as he should. Agamemnon took what was treasured by Achilles in front of everyone setting in motion the epic on anger and pride. At one time or another we've all been tempted like Agamemnon when giving a review. So remember, code reviews aren't a means to satisfy our own pride and insecurities about our position. Have you ever been in a code review that felt more like a battle than a collaboration? Let's turn these moments into opportunities to learn and grow with each other rather than using each other. How do you ensure your code reviews are constructive and empowering? "Achilles’ wrath, to Greece the direful spring  Of woes unnumber’d, heavenly goddess, sing!  That wrath which hurl’d to Pluto’s gloomy reign  The souls of mighty chiefs untimely slain;" - The Iliad, Book 1

7

1 Comment

Last night I released my #RustLang crate steady_state="0.0.16" About it: https://lnkd.in/gq-w86k3 (give me a star) I hope to clean up docs and tests for a 1.0 release next month. Right now I am asking for feedback. #Makers #inventors #builders #programming 38

1