The xkcd thing is just one webcomic, I reckon it is just a joke and probably Randall Munroe did not consider its implications or think it would be taken seriously. Though xkcd is really popular and probably is relatively influential (especially in programming circles)
That being said, I totally agree with this article. Also 'read a style guide' is one of the worst possible suggestions I could think of. Style is just style. Its one of the least important things I could think of. It depends on your work situation but in many cases why not just go with whatever style you are happy with personally and makes sense to you.
A Million Lines of Bad Code
81–90 of 123 posts
Re: A Million Lines of Bad Code
#82I 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 shitty at it.
In fact, I'm almost always very impressed with people who are not professional coders but who have taught themselves a few coding skills in order to solve some problem or to actualize some idea -- even if the code itself is horrific from a professional standpoint. That's awesome! And if they want help, I won't mock -- I'll help! It's a rare opportunity to really show someone why I find the act of programming to be so fascinating and satisfying.
Re: A Million Lines of Bad Code
#83This times a million. I love helping people to learn C, for example. And the thing I do most other than basic instruction is helping to keep their spirits up and reminding them that refactoring is the most important part of coding.
Re: A Million Lines of Bad Code
#84Earlier 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 gotta wonder, do you actually have such confidence yourself that you assume that everything other people _does not_ comment was good? If so congratulations! A suggestion though, on how you could improve the confidence in people like me - who aren't sure everything not mentioned is good - would be to actually point out the positive parts even if you don't feel that it is necessary. I have to admit though, it took ma…
I suppose there's a difference between when you're working with someone versus showing off to other people. If I'm doing a Show HN or I email a friend to check something out, sure I love flattery and compliments as anyone. It's within the technical scope of working together that I find it obnoxious.
And it's not really self confidence[1]. It's more of an extension of principles of coding. Anyone can write a system that does X. But doing X when things go well, and doing it in the face of errors, edge cases, and other faults - that's what it's all about. For me, anyways, when I'm writing code "as an engineer". So I don't find it particularly notable that something works. Of course it " works ", or you wouldn't be telling or showing me in the first place! Likewise if I ask for a review and your only comment is " file buffer is too small " I'm gonna guess the rest is alright else you wouldn't bother pointing out smaller things. If I'm unsure about something, I'll ask about it explicitly.
Outside of a feedback system like a code review, it is important to let people know you appreciate their work. And it's to my detriment that I don't let people know, honestly, when I appreciate them. But that's separate from mixing it in with criticism.
1: I've low confidence in my self confidence. On one hand I know I have a fairly good error rate and I'm objectively better than a lot of other developers. Yet, especially here on HN, I can plainly see I'm nothing special. But this doesn't really assure me that any particular piece of my work is good.
Re: A Million Lines of Bad Code
#85Earlier quoted context omitted.
Very well said. It's wrong to be a dick, but it's also the natural response to a lot of stressful situations. Think of trying to give tech support to relatives, for example. It's too easy to get annoyed with other people, and this is especially true when you're under pressure and they're MEANT TO BE HELPING, DAMNIT! FWIW, I suspect that you're much more experienced in this stuff than me, so it's a bit arrogant for me…
That's actually the route I've been trying to follow, but that's where the experience gap becomes a problem. I can give him some ressources on how to use Git or learn Python, but it's been so long that I don't even know where to start for the CLI :|
I found this pretty good for sharing to people, if you're targeting Linux: http://linuxsurvival.com/
Parts of it are a bit dated (no longer typically used features), but it's a pretty good overview of how Linux works for end users.
Re: A Million Lines of Bad Code
#86I recently read the book "How to Win Friends & Influence People", bad title great book. My main take away from this is I've been talking to people really badly for the last 27 years. I wish I had read this book in middle school. But this blog reminded me of some of the concepts from the book, its far more productive to give positive encouragement than to give negative feedback, and just adding a complement isn't enou…
I'm an engineer, and I've gotten so much benefit out of that book. I read it cover to cover several times a year. It's very corny, but it reminds me of several things I often don't conciously think about when interacting with people. Sometimes reading that book is the only way I can get through the day and interact pleasantly with people.
One reason engineers can be unintentionally critical is that their job is often "find what's wrong with this thing and make it better". It's rarely "find what's right with this thing and congratulate someone". It takes me quite a bit of mental effort to switch from nitpick mode to encouragement mode. I've tried to consciously balance my criticisms by leaving a few honest encouraging comments in code reviews like: "thanks for improving test coverage here", or "glad you handled timeouts and retrys, this api has given us grief before".
Re: A Million Lines of Bad Code
#87I recently read the book "How to Win Friends & Influence People", bad title great book. My main take away from this is I've been talking to people really badly for the last 27 years. I wish I had read this book in middle school. But this blog reminded me of some of the concepts from the book, its far more productive to give positive encouragement than to give negative feedback, and just adding a complement isn't enou…
"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.
I think the key is to give an honest compliment on not a bullshit one. So instead of "great job on the thing! but ..." maybe "great job finding and diagnosing the root cause of that problem, that was pretty hairy, but I think there's a better way to fix the root cause".
Re: A Million Lines of Bad Code
#88Earlier quoted context omitted.
I like teaching. I don't think I'm amazing at it, but I like sharing knowledge and experience with my friends and co-workers and see them improve, or just sometimes for the abstract sense of helping. Of course, sometimes I fall flat and come across as arrogant or condescending, but I hope that's rare. I read "How to make friends" a long time ago, and I apply those rules diligently to my interactions with people. Rece…
> Anyhow, this is just my two cents relating an experience to show how a seemingly normal and friendly human being can revert to angry "RTFM"s. The guy is not just a human being, he's also a professional whose job it is to know what he's doing. Shouldn't there be some sense of "duty to do a job well", not just "duty to care about someone's feelings"? If he's not pulling his weight and is failing at his job, then the…
"And forgive us our sins; for we ourselves also forgive every one that is indebted to us."
Re: A Million Lines of Bad Code
#89If 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…
Would it work to say, "Added test coverage, refactored code to increase future maintainability"?
Client: "Send us some screen shots of the new features."
You: "Err..."
Re: A Million Lines of Bad Code
#90Earlier quoted context omitted.
In the martial arts community we call this "praise, correct, praise."
Programmers tend to incline towards efficiency. I think that's why we often skip the bread and deliver only the filling. IMO there's a big difference between a criticism sandwich and tactful criticism.
Delivering constructive criticism in a polite and non-abrasive way is more efficient. If abruptly telling someone their wrong causes them to take offense to the help you're trying to provide, they'll likely disregard what you've just told them out of pride or spite and you'll reduce their willingness to work with you on future problems.
By being polite you're ensuring that the message you're sending gets incorporated into their strategy for tackling that problem and making them feel comfortable discussing other issues with you.
As programmers, we have to learn that 'programming' people is very different from programming computers.