Live data from Hacker News

A Million Lines of Bad Code

varianceexplained.org

91–100 of 123 posts

Re: A Million Lines of Bad Code

#91
post #31

If only my clients and recent bosses would consider refactoring a valid billing line item... I can only imagine sending an invoice today to my three top clients with "5 Hours Refactoring Bad Code That is Working But Could Be Better Looking....$400". There is just no way I would get paid. Unfortunately, I have interests outside of working on code that mostly preclude me from sitting for hours happily breaking-and-then…

Solution A is obviously to educate them: $400 as time spent to make adding the next 10 features cheaper.

Solution B is to refactor some fraction of the code you interface with when adding a new feature.

So it's "X+2 hours adding new feature" when you spent 2 hours refactoring code that feature X needed to deal with.

As far as the ethics of Solution B, then if your refactoring is actually improving your net productivity, then you truely are doing necessary work towards adding the feature (just as you would bill tests or build scripts needed for the feature along with it). If it isn't improving your net productivity, then why are you doing it?

Re: A Million Lines of Bad Code

#92

Not quite right. All the code I wrote last year looks bad to me; naieve, clumsy, artless. Because I have learned so much since then. It never gets any better. Not because I don't get better; because I DO get better. I've been writing code since 1976.

I hear this sentiment a lot (and notice it in myself, though I have a lot less experience so it hasn't been as long running), and it worries me. Are you sure it's better? Are you keenly aware that there are no, say, cycles in your coding approach? I know this year I look back at last year's code and go, "oh boy, why'd I do it that way?" And I feel like it's better, but I'm always a little afraid I'm just chasing nove…

Don't forget also that familiarity makes things seem more clear. Code you wrote yesterday needs to be particularly atrocious for you to find it hard to understand. Code you wrote a year or two ago might as well have been written by a stranger (really memorable hacks aside).

Perhaps look at code from 2 years ago and 3 years ago, and if possible blind yourself as to which is older, and rate each one.

Re: A Million Lines of Bad Code

#93
post #31

If only my clients and recent bosses would consider refactoring a valid billing line item... I can only imagine sending an invoice today to my three top clients with "5 Hours Refactoring Bad Code That is Working But Could Be Better Looking....$400". There is just no way I would get paid. Unfortunately, I have interests outside of working on code that mostly preclude me from sitting for hours happily breaking-and-then…

How about "I did my job, and if you ask me to specify how much time I spent on testing and refactoring, you're a micromanager and you're redundant because you obviously have nothing better to do"? As a developer, you need to take your own responsibility for the code and product you create, and be proud of it. Besides, it's a fallacy that time not spent on code quality would lead to more features / a better product.

Re: A Million Lines of Bad Code

#94
post #82

I don't see anything wrong with the "mean-spirited" humor in the XKCD comic. The cartoon is funny. It's supposed to be a joke. Anyways, it's not like those remarks are directed at anyone in particular -- just a fictional stick figure. I don't have any ethical qualms about laughing at his expense.

You're right to not have qualms about laughing at something that's literally just black and white pixels (and some in-between grays) that are arranged in some configuration on your screen. ;-) That said, this XKCD comic is one of Randall's rare misses. It's about mocking something which I -- as a developer -- would actually like to promote: People taking initiative and teaching themselves to code. Even people who are…

> You're right to not have qualms about laughing at something that's literally just black and white pixels (and some in-between grays) that are arranged in some configuration on your screen. ;-)

Not sure what you're trying to say here? Its a cartoon about a stick figure who can't code. Funniest part was "it's like someone took a transcript of a couple arguing at ikea and made random edits until it compiled without errors" lol

> That said, this XKCD comic is one of Randall's rare misses. It's about mocking something which I -- as a developer -- would actually like to promote: People taking initiative and teaching themselves to code. Even people who are shitty at it.

I understand that you feel passionately about this, and I agree wholeheartedly that non professionals should not be mocked. That said, I dont think that's what's going on here. What we have here, is a cartoon that's poking fun at an exaggerated circumstance. No individual or group is being (sincerely) called out or told they shouln't try to learn to code. It's all just a joke, for amusement.

Its like saying Peanuts is mean spirited for mocking people with poor hygiene with the character Pig Pen: It discourages those people from leaving their homes and interacting with people. I should instead encourage those with poor hygiene to pick up that bar of soap and go outside!

... But that's silly, right?

Re: A Million Lines of Bad Code

#95

I agree that mean-spirited feedback is not helpful/constructive. I can see how that would discourage someone who is new to programming. In fact, "feedback" is probably not even the correct name for that... maybe "bullying". However, I have to disagree with the notion of having to write a lot of shitty code to learn to write good code. Granted, that is one way to learn, but not nearly the most effective way to learn.…

This kind of thing can really have an effect on your career in the immediate future. There are a lot of expectations that people come up with regarding what you should know by X years into your career and people judge you pretty strongly on this.

I personally don't get any feedback on my code and I don't really have time to police myself on it. I end up blending in with the conventions I see in whatever current document I'm working on (e.g. presence of type prefixes, casing style, underscore usage). I always thought this was bad practice in the general population but I guess I get paid for it.

We aren't going to raise the industry-wide skill level if we let people figure it out on their own the hard way. That's valuable up until a point but eventually they should start wanting to know what the effective way of doing X is (if it exists). Individuals take a long time to arrive at an optimal point with that stuff, and may never even reach it.

I'm fairly sure NASA doesn't let staff (astronauts especially) in training learn everything the hard way. Imagine if your workplace maintained something like this: http://llis.nasa.gov/

Re: A Million Lines of Bad Code

#96
post #82

Earlier quoted context omitted.

You're right to not have qualms about laughing at something that's literally just black and white pixels (and some in-between grays) that are arranged in some configuration on your screen. ;-) That said, this XKCD comic is one of Randall's rare misses. It's about mocking something which I -- as a developer -- would actually like to promote: People taking initiative and teaching themselves to code. Even people who are…

> You're right to not have qualms about laughing at something that's literally just black and white pixels (and some in-between grays) that are arranged in some configuration on your screen. ;-) Not sure what you're trying to say here? Its a cartoon about a stick figure who can't code. Funniest part was "it's like someone took a transcript of a couple arguing at ikea and made random edits until it compiled without er…

> Not sure what you're trying to say here? Its a cartoon about a stick figure who can't code. Funniest part was "it's like someone took a transcript of a couple arguing at ikea and made random edits until it compiled without errors" lol

I'm just poking a little fun at your earlier reductionism. You're right, it's just a stick figure. A real human has not been hurt.

My main issue with the comic is that it's not particularly funny. To me. The zingers don't really zing. It's just someone whaling on someone else for three panels. And since I'm not catching onto the humor, all I'm left with is the weird feeling that the comic is condoning that kind of behavior.

Re: A Million Lines of Bad Code

#97
post #55

Earlier quoted context omitted.

Don't you feel patronized when people do that though? Be as rude as you want to me, as long as you're correct. As for myself, I tend to not call out the positive parts of something, because that's sort of implicit. I would not bother to point out that the file reading code is wrong if the whole thing was broken. I admit I'm probably incorrect here, but I notice people try this "say something positive" and it really c…

I think it just comes down to different personalities. I'm just like you. I tend to get agitated when people try to sandwich their criticisms or compliment me for irrelevant things when I just want them to get to the point. I'd very much prefer someone just telling me "your code is shitty and here is how you'd fix it and why." Unfortunately, people that take criticisms like us seem to be in the minority.

That's why I personally declare Crocker's rules[0] - if you want to tell me something, I allow you to skip pleasantries and "social hacks", and just get straight to the point.

[0] - http://wiki.lesswrong.com/wiki/Crocker%27s_rules

Re: A Million Lines of Bad Code

#98
post #92

Earlier quoted context omitted.

I hear this sentiment a lot (and notice it in myself, though I have a lot less experience so it hasn't been as long running), and it worries me. Are you sure it's better? Are you keenly aware that there are no, say, cycles in your coding approach? I know this year I look back at last year's code and go, "oh boy, why'd I do it that way?" And I feel like it's better, but I'm always a little afraid I'm just chasing nove…

Don't forget also that familiarity makes things seem more clear. Code you wrote yesterday needs to be particularly atrocious for you to find it hard to understand. Code you wrote a year or two ago might as well have been written by a stranger (really memorable hacks aside). Perhaps look at code from 2 years ago and 3 years ago, and if possible blind yourself as to which is older, and rate each one.

I'm pretty sure I remember my code. I agonize over it, put all my effort into it. I remember code I wrote in the '80. I remember the code I wrote 7 years ago, and refactored last year. Code is my life.

I've had that sneaking suspicion that maybe I'm not really getting any better, yes. But I have independent corroboration - I've worked with another guy for most of that time, and we've got one anothers' code to look at. What one of us learns, the other learns too. He's not cycling, or just writing bad code. And he says the same about me.

Re: A Million Lines of Bad Code

#99

Earlier quoted context omitted.

"Hey pretty cool program! Its a great start. I bet we can make it run faster if we changed the way files are imported to something like this... nice work" I usually hear this referred to as a "criticism sandwich": Criticism surrounded on either side with compliments.

In the martial arts community we call this "praise, correct, praise."

Canadian Snowboard Instructors call that "Positive, to and try" i.e.

That's great! To make it read files faster, next time let's try xyz.

Re: A Million Lines of Bad Code

#100
There's a difference between practice and mere repetition. You wouldn't get any better at speaking Russian if you just spoke gibberish, even if you did it for 10 years. You need to know what improvement looks like.
Post reply on HN