Code with a soul

Sometimes it’s not the big projects, but rather the small hobby projects that bring me the most joy. Back to basics. In my case: building a simple app, just to play around with vanilla JavaScript and nested CSS again. No grand plan, no roadmap, just learning by doing.

At Leukeleu, we needed a way to fairly determine who’s on duty for chores (like picking up lunch, loading the dishwasher, etc.), so we built a little web app to solve that: The Determinator. The beauty of such a project? You get to decide how it looks, how the logic works, and you can keep tweaking it until it matches your vision. Often, most of the time isn’t spent coding, but searching, fiddling, adjusting, and iterating. And it’s precisely that process that makes a project feel truly yours.

Disappointment

Last week, out of the blue, I received a new pull request. Someone (no names ;) had added functionality. Seemed well-intentioned at first glance, but it quickly became clear that it was a classic “vibe coded” addition. It worked as a prototype, but didn’t actually add real value to the app in its current form. To use a metaphor: I felt like a painter who had created a beautiful painting, only to have someone doodle a stick figure next to it.

Soulless code

A good developer cares about their code. Not just whether it “works,” but whether it’s sustainable, readable, and useful. This PR had none of that. It had no soul. And that’s exactly where things often go wrong with “quick fixes.” Something that seems to function on the surface can actually undermine the quality and coherence of a project.

You see it in hobby projects, where it’s not a big deal, but also in serious, business-critical applications.

Sound familiar?

Many organizations face this exact issue. An application that was once built with care eventually gets overwhelmed by quick fixes, half-baked features, or integrations that don’t really fit.

The result: software that’s fragile, inconsistent, and frustrating to work with. That disappointment isn’t a luxury problem. It slows down innovation, increases the risk of bugs, and erodes user trust. Just like I didn’t feel like looking at my hobby project after that PR, teams and users alike disengage when software no longer shows quality or coherence.

Code with soul

So, what makes the difference? Code with soul. Code written with care and attention. Where decisions are well thought out, the interface feels intuitive, and the architecture allows for further development. That takes more than just technical skills. It’s about respecting the work that’s already been done, understanding the context, and recognizing that software is always part of a bigger picture.

That disappointing PR became a reminder of something bigger: writing good software isn’t just about quick results—it’s about lasting value. One well-considered addition is better than ten half-baked features. And perhaps even more importantly: a developer who cares about their code builds trust. Within their team, among users, and ultimately across the whole organization.

In closing

My hobby project didn’t suffer from it. In fact, it gave me a reason to re-evaluate what quality means to me. But for organizations that rely on their software, this is a serious lesson: software without soul is software without a future. Want to know how we handle these kinds of challenges at Leukeleu? Read more about how we deal with technical debt or schedule a chat with our team.