I write terrible code, and I'm OK with that.

github logo ・1 min read

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.

twitter logo DISCUSS (8)
markdown guide
 

I think context is important here. I think we should all feel comfortable admitting that we all write terrible code at points!

  • When we're learning something new
  • When we're in a rush
  • When we haven't properly defined the problem

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.

 

Remind of me of a tag line "I don't create code, I create bugs."

 

Every code is a crap code. It's just a matter of who messed it and when.

 

Yes that's possible with little projects. With larger projects that can be difficult to find the time to refactor...

 

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.

Classic DEV Post from Oct 20 '18

Learning the Granular Details of a Programming Language?

I'm currently reading "JavaScript: The Definitive Guide" and it's a mighty long...

Mike profile image
Full-time freelancer; Former Lead Engineer / Senior Management; speaker; 14 years in development; open for consulting and freelance opportunities.