Live data from Hacker News

Throw away your first draft of your code

ntietz.com

81–90 of 230 posts

Re: Throw away your first draft of your code

#81
post #10

The temptation to throw away all of your code - be it a prototype or a "grown" code base - arises often. Often it is a bad idea. I get it, though, there is an inherent attractiveness in the idea of starting fresh from a clean slate. Except, more likely than not, you'll soon find yourself in a similar situation to the one you started from. The fundamental problem is that it is easy to underestimate the edge cases. Sur…

I don't really feel that attraction to complete rewriting. I wonder if the people who do are very smart, and thus able to hold more state in their head, so ugly code bothers them more even if it's not actively a problem, because they are able to have background tasks in their mind to worry about it? And at the same time, perhaps their code is less encapsulated, because they didn't optimize for abstraction, they optim…

Speaking personally my urge to rewrite at least partially comes from not truly understanding the problem and the solutions to it until I've written something reasonably functional. It doesn't matter how much time I put into sitting and theorizing, there's always things I didn't anticipate and assumptions that turned out to be incorrect.

This usually means that rewrites are significant improvements across the board, especially if they're done a relatively short time after the original is finished since it's all still fresh in my head.

This may be a weakness of sorts on my part though, I lack formal engineering training which might be why purely mental modeling (no code) doesn't work all that well for me.

Re: Throw away your first draft of your code

#82
post #37

I rewrote a mission critical application. The original app was something else. One function had 1500+ lines of code. It was the ugliest thing I have seen in my life. We wrote cleaner code in early college years. However, that code ran the business for 12 years with almost 0 modifications. People created work around for some stuff. Error handling was poor. But the goal was achieved and business continued to grow. I th…

> I think devs in general sweat too much about code quality I think if they sweated a little more then poor quality code wouldn't find itself into the codebase.

Bad code doesn't usually come from lack of effort. It usually comes from business requirements that grow over time with deadlines attached.

Re: Throw away your first draft of your code

#83
post #37

I rewrote a mission critical application. The original app was something else. One function had 1500+ lines of code. It was the ugliest thing I have seen in my life. We wrote cleaner code in early college years. However, that code ran the business for 12 years with almost 0 modifications. People created work around for some stuff. Error handling was poor. But the goal was achieved and business continued to grow. I th…

Some disputes about quality are simply differences of opinion or style.

There's not really a book or standard on opinionated code quality that satisfies a majority of the people in the field. There's way too many ways to build things for that to exist.

This leaves it up to individual teams to approach a shared consensus (with some wiggle room) within their domain and tool set.

One thing that is universal is how strict the enforcement of a team's quality standards. So as a developer, you have to decide whether you like strict or lax enforcement of quality standards. Everyone can decide that but I think most don't.

Re: Throw away your first draft of your code

#84
I have a similar process, but I do it after hours because I treat it as exercise.

The task isn't about what the resulting system does, but how - the aim is to figure out where certain patterns are applicable and where they break down.

Ideas include: using a design pattern like Entity Component System, exploring whether a certain way of formatting code is actually more readable, producing a drop-in replacement for a small utility.

I firmly believe this makes you an overall better programmer. That being said I think it would be wise to refrain from doing that at work.

Re: Throw away your first draft of your code

#85
post #10

The temptation to throw away all of your code - be it a prototype or a "grown" code base - arises often. Often it is a bad idea. I get it, though, there is an inherent attractiveness in the idea of starting fresh from a clean slate. Except, more likely than not, you'll soon find yourself in a similar situation to the one you started from. The fundamental problem is that it is easy to underestimate the edge cases. Sur…

Game companies implicitly do this, throwing out old versions of their code (sort of). You make a game. Ship it. Start on a new game. Your previous game is now sort of a practice run for making a new game from scratch. Continue, ad infinitum. It's weird: you rarely have to maintain something for 20+ years, and you get to always improve and iterate on how you did things last time. But, are you training yourself to writ…

what you do you get good at. if you don't have to maintain there is no point in getting good at it or any reason to think you will gradually get better at it.

Re: Throw away your first draft of your code

#87
post #82

Earlier quoted context omitted.

> I think devs in general sweat too much about code quality I think if they sweated a little more then poor quality code wouldn't find itself into the codebase.

Bad code doesn't usually come from lack of effort. It usually comes from business requirements that grow over time with deadlines attached.

It can still be a lack of effort put in trying to convince product managers etc that more time is needed!

But almost all PRs I review have something in them that suggests the developer not putting as much thought/care into what they were doing as I'd like to see (and I'm just as capable of doing the same).

Re: Throw away your first draft of your code

#88
post #65

I've never respected this advice, even though I hear it often enough. The reasoning appears to come down to this: > If you know that you're possibly keeping the code, you do things in a "proper" way, which means moving slower combined with the idea that it's faster to redo work than it is to refactor. I don't buy either of these propositions as a universal rule. For the first, it seems that a mindset of avoiding prem…

> I most often get things right enough the first time that it really only needs to be refactored going forward. I think it really depends on your values and what you’re working on. If you have the mindset of a product engineer, the thing you care the most about is how well the software works for your users. The code is an unfortunate necessity. When I build react apps, I tend to think like this. The code I write firs…

I agree that it depends on factors like what you describe which is why I am asking those giving the advice like this to consider the context at all. I also happen believe that the contextual bar should be placed high. I have to say, what comes to mind when I read your comment was "What about this does refactoring not accomplish?" In the metaphor of building a house, refactoring is what keeps it tidy and organized, and rewriting would only appear necessary in the case of your trash chute leading into a bathtub or some other critical design flaw that could only be addressed timely by redesigning the entire house.

If you are in a context where you are in danger of making critical design flaws often, or where circumstances make it hard to make changes after committing, then I absolutely agree that rewriting is effective. That's just what I mean by a high bar, one that I personally don't encounter very often in my work.

Re: Throw away your first draft of your code

#89
post #10

The temptation to throw away all of your code - be it a prototype or a "grown" code base - arises often. Often it is a bad idea. I get it, though, there is an inherent attractiveness in the idea of starting fresh from a clean slate. Except, more likely than not, you'll soon find yourself in a similar situation to the one you started from. The fundamental problem is that it is easy to underestimate the edge cases. Sur…

Game companies implicitly do this, throwing out old versions of their code (sort of). You make a game. Ship it. Start on a new game. Your previous game is now sort of a practice run for making a new game from scratch. Continue, ad infinitum. It's weird: you rarely have to maintain something for 20+ years, and you get to always improve and iterate on how you did things last time. But, are you training yourself to writ…

Minecraft is reaching that 15+ year mark

Re: Throw away your first draft of your code

#90
I've always called this the "green-path prototype", which is building what you thought you knew, without implementing edge cases. The edge cases will get discovered and noted along the way and they should be documented (with a comment or other method that doesn't get lost). Pretty much any time you only handle a subset and don't handle the 'else's.

The real implementation should consider the green-path and edge case notes, decide the desired structure/decomposition and pick and choose from the green-path rather than try to start with it as v1 of a final form.

Post reply on HN