About: Full-time freelancer; Former Lead Engineer / Senior Management; speaker; 14 years in development; open for consulting and freelance opportunities.
I admit, I write terrible code. It's beyond spaghetti. Let's forget this whole MVP stuff.
Writing terrible code is actually a great thing, it allows you to look back on it in time and revise it, use your further knowledge to rewrite and implement it a better way. If you've never written terrible code, you've never learned how to code.
I think context is important here. I think we should all feel comfortable admitting that we all write terrible code at points!
However, that doesn't mean we're satisfied with that code. I'd hope that "terrible code" is our starting point. That we start there and make it better. That we don't put code in production unless we are confident it is reasonably maintainable for others, or even our future selves!
There is no shame in terrible code. We should normalize terrible code writing. But I'd caution us against accepting terrible code as a final solution.
Gunna go ahead and disagree here. Writing terrible code is never a great thing. Looking back on terrible code you've written should bring great shame and embarassment.
The opportunity to revise, rewrite, and reimplement is time wasted, since you're resulting in a net gain of zero, from the consumers perspective.
For code where you're the sole proprietor, though - sure.
That seems pretty double standard there. Writing terrible code is a natural part of developing, not everything you do will be immediately perfect. You shouldn't feel no shame nor embarrassment from it. If you rewrite your code down the line for the better, then you're making customers happy by improving on existing work and likely adding new features in the same breath.
I would argue that you should always be writing the best code you can write at the time. For you, at the time, that isn't terrible code, that's the best you can do.
The impression I got from the original post was that you're consciously writing bad code, recognizing it, and dismissing it. That was more what I was responding to.
Regarding rewriting bad code: If something works, I would generally not touch it. It's usually not worth the time and mental load. That's only if it works though. You can have the most steaming pile of garbage code, but if it works, there's absolutely zero reason to ever touch it.
I really like the honesty in this post. It’s true — writing “terrible code” is part of the process, and looking back at it later is often the best way to measure how much you’ve grown. Nobody gets to clean, scalable solutions without passing through the messy stage first.
My current focus is on expanding my business into the U.S. and European markets, especially with AI and Machine Learning projects. Collaboration with other developers who are also learning, revising, and improving over time is a big part of that goal. Posts like this remind me that growth comes from practice and persistence, not from perfection on day one.
Thanks for sharing this perspective.
Yes that's possible with little projects. With larger projects that can be difficult to find the time to refactor...