Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

xsawyerx (8978)

  (email not shown publicly)

Journal of xsawyerx (8978)

Sunday July 05, 2009
04:44 AM

Red Flags in Programming Slides are UP!

[ #39230 ]

The slides are available HERE

I should be calling this entry Why is stupid and I hate it but I'm going to leave that to another time. Instead, I would like to rant a bit on the purpose of Red Flags. You don't have to read this, and you probably won't find this enlightening or even slightly interesting. I just have to vent.

A fellow programmer who attended the lecture wrote in his blog about it, and I couldn't find the energy to reply verbally, so I'll do it here.

The purpose of Red Flags is not to generalize on who is evil and stupid and vile and who is correct and pure and fluffy. The point is to understand practices that usually don't benefit us but rather derive from practices employed in previous jobs, prior experience with different (usually older or drastically different) languages.

This is something that can and should be done in all areas of life, and not just programming. We should always search for what we do because of prior pretenses and reevaluate it and see if there's room for improvement or change. This does not mean that what I would consider a "bad practice" necessarily applies to you and some of the slides do indicate that sometimes you have no other choice but to chose something that.. if you did have another choice, you wouldn't choose.

That person also denounced the lecture as generalization, which "is always bad". I'm sorry, but generalization is not always bad. I generalize people who hit other people when they're drunk as people I do not want to be around when they are drunk. Strict generalization. I also generalize coders who write a 400 line program in one single line as people who don't really want their code to be read, that's a generalization. I also generalize that as a bad coding practice. Yes, I do. There is nothing really wrong with generalization as a way to try and avoid (or at least be cautious around) things that from our experience (or basic understand) might (might) not be good for us. People see generalization as a problem because people generalize the wrong things, but this does not mean we should avoid the quality of generalization. "You shouldn't talk to strangers" is... a generalization, my friend, and it's the first thing you would tell your child.

I have to say I'm deeply disappointed that instead of saying "well, maybe I really should consider avoiding these practices unless I absolutely find the need for it" or saying "this doesn't apply to me, I'm too good of a programmer to listen to this kid", the saying was "he generalizes try and catch for workflow (unless necessary) as a bad practice, and I remember from school that generalizations are bad [I won't stress the point that this is... yet another generalization], so I'm going to say this sucks". Deeply disappointed.

This is exactly the point I don't write in forums, communities, do lectures on programming to a large crowd or engage in conversation with fellow programmers outside my work or social circle (which has about 2 programmers).


The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • I really appreciate your slideshow. Really fun to read. Thanks!
  • This is exactly the point I don't write in forums, communities, do lectures on programming to a large crowd or engage in conversation with fellow programmers outside my work or social circle (which has about 2 programmers).

    It sounds like your frustration here is that other people disagree with you about what you have to say and why you did what you did. I understand exactly how you feel. It can be frustrating to feel misunderstood or be told "That's not the right thing to do."

    That sort of pushback is



    • Thank you for the kind words, and as usual, you're right, and I intend to try and let comments enrich and improve me next time than raise my frustration. Again, thank you.

  • On your entire lecture you are talking about at one hand that there are do and dont's in programming, you constantly mentioning that it does not apply for everything, but only for capable things that allow it, but you constantly create a very big reference "do not do it". Every language require you to program in it's own state of mind. While your lecture is very important and you raise a lot of subjects that are very important to know, you can not generalize things. My profession is to bring solutions and
    • I don't want to continue this argument, but I still want to make a certain point clear so I'm responding more towards other people reading this than you (since I already spoke to you personally about it).

      A problem that you have is that you can be petty when it comes to exclusions. If something has to be excluded, it's hard for you to see that. You need that element completely out of the picture. For example, Shlomi Fish and I both published the lecture to be about mostly dynamic languages (and mentioned spe