Hacker News new | ask | show | jobs
by YZF 1081 days ago
Most of my early career was "greenfield". I really loved doing that. Sometimes that meant me doing everything. Guess where the buck stops? There's no way to disconnect the final result from the work. Keep in mind though that green field pretty quickly turns into maintenance. You ship something, guess what, there's bugs to fix. You want to add a feature, you have an existing code base. The nice thing is that there's no one else to blame. Is it really hard to add a feature? You (or your team) messed up. Does the quality suck? You (or your team) messed up.

Even in well established code bases there can always be "green" new pieces. These are choices to make: should we refactor the code, should we fix the old code, should we rewrite pieces of it. There is no one answer that always works. The problem is when you look at something and your answer is always a rewrite just because you didn't write the original code. I've seen people/team rewrite perfectly good code for no business reason, just because they want to.

In terms of code written by others, sometimes that's a thing of beauty, a piece of art. Sometimes it's just garbage. I'm sure we've all seen some code where we go wow, this is incredible. And then we've all seen code where we go wtf. I don't really see the need to dig too deep there, what's great is great and what's garbage is garbage and then a lot is somewhere in the middle. I sometimes look at code I've written in the past and I think it's really great; and sometimes I go wtf. Usually the latter is where I was not familiar enough with the problem space or the code base I was working in. Questions to ask are: does it work? what's the cost of maintenance? Ugly code that works well, doesn't need to be touched, can be fine.