Hacker News Reader

Comment by unwind | Hacker News Reader

So, as a programmer with at least "a lot" of experience (these things are hard to judge, especially among folks here), I'm trying to extract some learning from this.

I'm not at all sure about my classification. Probably somewhere between Librarian and Purist, perhaps (but these things feel somewhat harder to apply when most of the code is in C).

Should I fight the urge to re-write code that I see as broken, since it's just me wanting to re-shape the code in my image? That's emotionally somewhat difficult (bad code hurts the eyes) but certainly doable, but it also seems a bit counter-productive since I really think there can be some value in sharing experience. It's also, of course (?) hard to really believe that it's all narcissism, to me bad code feels objectively bad. If that even makes sense.

I guess it boils down to "co-operation is hard" for me, right now. :)

View on HN

The point is, the code wasn't broken. It just wasn't done the "right" way.

I've had to fire people because they could not stop "refactoring" code that wasn't broken. Their commits were half in the code the were supposed to be working on and half scattered, random changes like the changes from the article.

You're not "sharing experience"; you're wasting time, money and energy. You are insulting your co-workers intelligence. You are pissing off your boss.

Worse, your co-workers now have to merge your random edits into their work because they were actually assigned to work on the section of code you "fixed".

There is nothing worse than doing a pull and finding a bunch of small, conflicting and ultimately useless changes on the head, ruining your morning coffee.

Heh. Your comment actually made me blush. :)

I certainly hope I do whatever I do with a bit more finesse than what you imply. So far co-workers do not seem to be offended, and no boss has ever seemed pissed off to me.

From your remark, it sounds as if you consider "refactoring" to be almost a swear word, and something that should never happen. I just can't agree with that, even with code I've written myself I sometimes realize I did it wrong.

I practice commenting on other people's code a lot online, that seems to work pretty well, too. Of course it's even harder to notice if I'm offending people online.

> From your remark, it sounds as if you consider "refactoring" to be almost a swear word, and something that should never happen. I just can't agree with that, even with code I've written myself I sometimes realize I did it wrong.

Ha! Not really, in my career I think I am still "net negative" for lines of code; I once refactored a 100K line medical diagnostic program down to ~10K lines for instance. What is a swear word is people who use "refactoring" as an excuse to start dicking around with stuff that doesn't need to be fixed.

Refactoring certainly has it's place, but needs to have a purpose: new feature set that requires the rework, performance, what have you. Too many developers just pick something that is working and "refactor" it ... then you end up with the same thing you started with, just "better" and with different bugs.

I immediately thought that the Librarian one was sensible and correct, whereas the others seemed like very strained satire. So I'm guessing that makes me a Librarian.

But maybe a cynical, world-weary Librarian like the discworld one, as touching someone else's crappy code without some larger plan in mind seems destined to cause you heartache, following the standard "person who last touched it is to blame" rule.

The librarian's change wasn't so bad, since it was functionally equivalent to the previous one. It was also more legible than the previous one, although she probably should have left it alone.

I think I'm an agnostic. "if it already works[1] then trying to fix it is a bug in the programmer's brain".

(Note: I am a user of many ancient and venerable old FORTRAN libraries, which I have no intention of rewriting because "there is a better way." Yes the glue code is a pain, but you don't need to write it very often.)

[1] or passes the tests, if appropriate.

Many if not most developers have the same feeling, that "bad code" is objectively bad. And how nice it would be if code quality could be graded on a scale. But it really can't - one mans "elegant" is another's "over-engineered". And one mans "simple" is another's "crude".

My perception of "beauty" is the simplest code that could possibly work, with the lowest possible levels of abstraction. I like YAGNI and similar principles. That's a pretty vague formulation though, so while most can probably agree on a high level, the devil is in the details. What exactly is "simple code" for example? Short code? Easy to read? Flexible? All of the above (that'd require Carmack or Thorvalds)? It really is all in the eye of the developer.

I think the takeaway of this excellent article is that whatever your style is, do have respect for differing styles. Don't grade developers or code on what you intuitively feel. Don't assume that everybody else is an idiot and finally don't waste time on debating / enforcing the one true way of doing things.

Cooperation may be hard, but it's also essential. When you see code that hurts your eyes, don't just fix it; discuss it. Set some standards together.

Understand why other people write code like that. If everybody is constantly "fixing" everybody else's code, you're never going to get anything done. Understand the differences and find some common ground. That's the only way to move forward.

> When you see code that hurts your eyes, don't just fix it; discuss it.

This.

Reply on news.ycombinator.com