dalibenothmen

No need to apologize at all. I really appreciate you taking the time to engage thoughtfully! Your feedback helped me clarify my own thinking, which is exactly the kind of conversation I love.

And that avocado slicer vs. kitchen knife analogy is perfect, it captures the nuance so well. Some tools are brilliantly specialized, while others thrive on flexibility. Maybe the real takeaway is that knowing when to reach for each is the mark of a savvy developer.

Thanks again for the great discussion, this is why I love sharing on Hackernews, nowhere else has such a density of curious, sharp-minded people who push ideas further.

That's a really fair question, and you're right that I could have been clearer about the persona I'm addressing. I'm actually part of that audience myself! As a developer and automation enthusiast, I fell in love with tools like Zapier and n8n, they're genuinely great for getting things done quickly. I still use them today for certain use cases. But here's where I've noticed the pattern: I've seen experienced developers (myself included) increasingly reaching for these visual tools even for complex workflows where code would be more appropriate. The tipping point for me was when I found myself building workflows that required custom scripts within the visual tools, dealing with 3-5 second execution times, and accepting limitations that I could easily solve with a few lines of code. You're absolutely right that the typical audience for these products isn't professional developers and it's business users, which is exactly why these tools are so successful and valuable. My frustration (and the motivation for this post) comes from seeing developers including myself choose the visual approach when we have better alternatives. This experience actually led me to build a code-first workflow automation engine with Bun and Rust that can handle computational-heavy workflows in milliseconds rather than seconds, at a fraction of the cost. I can even run it in a 1vcpu, 1GB ram VPS and still get a great performance. I think you've highlighted exactly why the post felt off, I was conflating the general success of these tools (which is well-deserved for their target audience) with a specific developer behavior that perhaps isn't as widespread as my bubble made it seem. Thanks for pushing me to clarify that distinction.

Thank you for your comment.Totally get what you’re saying and yeah, that’s a solid take. My main point was more about what happens next when those "Excel-as-solution" systems grow beyond their original scope and start needing maintenance, collaboration, or scale. That’s where things can get tricky. But I completely agree Excel often is the hero in the early stages.

Absolutely agree! I’ve seen the same thing happen. The idea that “power users” will manage workflows sounds great on paper, but in reality, it always falls back on developers. And once things get even slightly complex, I end up writing custom scripts anyway because the visual tools just can’t handle it cleanly.

At that point, you’re stuck using a tool that’s harder to debug, test, or version and still coding on the side. Totally with you on this being an anti-pattern in most serious use cases.

Totally agree. Excel is incredibly powerful, and people like Karen are doing real development, whether they realize it or not. My point wasn’t that Excel (or visual tools) are bad, it’s that when systems grow in complexity, they eventually need the same discipline, clarity, and maintainability that code provides. And that’s where things can get messy if we’re not careful.

Thank you so much for this thoughtful comment. I want to start by sincerely apologizing if the analogy came off as dismissive or disrespectful. I didn't mean to diminish from excel at all, in fact, you've highlighted exactly why Excel is so powerful and why my analogy works, just not in the way I originally framed it. Let me clarify what I was trying to get at: Excel's success comes from empowering domain experts like Karen to solve real problems without needing a computer science degree. That's genuinely amazing and valuable. The "problem" isn't Excel itself or Karen's contribution, it's when the tool becomes the permanent solution rather than a stepping stone. My point about visual workflow tools was similar: they're incredibly powerful for rapid prototyping and getting things done quickly. But when professional developers (whose core skill is writing maintainable, scalable code) use them as their primary solution, we might be missing opportunities for more robust, long-term approaches. You're spot on about the value vs. cost center perspective. In Karen's case, the smart move is absolutely to work WITH her domain expertise while adding technical structure. Similarly, visual workflow tools can be fantastic for proof-of-concept or when you need something working yesterday. I think my tone came across as dismissive when I meant to be more reflective about when we choose the right tool for the job. Thanks for pushing back on this, it's made me think more carefully about how I frame these discussions. Both Excel and visual workflow tools have earned their success for good reasons.