Red Flags in Programming Slides are UP!

xsawyerx on 2009-07-05T09:44:40

The slides are available HERE

I should be calling this entry

Why Slideshare.net 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).

</rant>


Thanks

azawawi on 2009-07-05T12:20:23

I really appreciate your slideshow. Really fun to read. Thanks!

Hell is other people.

petdance on 2009-07-05T14:13:58

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 part of life in general, and in saying something to the crowd in particular. Not everyone will agree with you. No matter how brilliant your message is, someone's going to not like it. And that's OK.

It's OK for two reasons. First, it's just statistically the way it is. There is no chance that everyone will agree with you, so you'll have to accept that as the way it is. Second, and more importantly, maybe their disagreement with you can teach you something. It's possible that you're wrong about part of your message, for one. It's also possible that you didn't tell your message as well as you could have. Instead of thinking "Boy, is that guy stupid, he didn't get what I was saying," you may want to look at what his response is and think "Maybe I didn't explain this part so well, and I'll fix it next time I give this talk."

I haven't seen the blog post you're referring to, and I'm not at all condoning rude, cruel or insulting comments. However, if your detractor's comments were effectively "I disagree with what he said," then learn from them if you can, and carry on your work. I'm glad you put your slides up, the message in them is good, and I'd hate for you to give up on that. The Perl community is improved by work such as yours.

Re:Hell is other people.

xsawyerx on 2009-07-07T12:18:15

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.

xsawyerx let me comment please :)

ik_5 on 2009-07-06T06:14:00

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 implement needs as someone asks me to. I do it with programming languages (or by using already existed programs, that I customize for them). When your profession is to know one (usually 2-4) languages, then generalize things are might be accepted, but not when the programming language is less important then the bottom line (a solution to a problem).

Most developers in the world are stupid people that known as code monkeys. They use tools such as .NET and lack of basic knowledge in actual programming. While they are your real audience, they are incapable in understanding when and how to apply such methodologies to their own technology when you take Perl as an example. That's was my rent in my blog btw. You said that do not do it, but only if you can avoid it, but you did not gave the tools for each technology to find how to do it, you gave perl examples only.

I know that you disagree with me, and that's ok, but please do not take it personally, it's just a different point of view then your own.

Re:xsawyerx let me comment please :)

xsawyerx on 2009-07-07T12:33:28

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 specifically Perl, Ruby, PHP and Python), and during the lecture I noted that some languages don't belong in it. I also noted again that I'm talking mainly about dynamic languages. Beyond that, at least two slides say that sometimes you can't do something because of the language you're working in and specifically told one nice person there (whose name I don't remember, sorry) that I can understand if in C he would do differently.

However, your constant claim is that "some languages don't allow you to do that". No shit. That's why I kept saying, in every possible way, that those language are excluded. I actually went over my way to express which languages are included. But this is your problem: you cannot understand that.

Quit trying to make me the "personally-offended friend". I'm not personally offended. Quit telling me not to take it personally, I didn't. It annoys me more and more that you try to defend my feelings when my feelings aren't even hurt. I appreciate it, but please stop it. I am, however, professionally offended. I wasted a good amount of effort into doing something that passed right by you. I spent then a good amount of effort to show you how it passed by you and why red flags (and adapting certain programming habits like not writing everything in a single line) are generally a good idea. Instead, it passed right by you again. I'm offended personally that as a brilliant programmer, you're still very petty at times, much like the ego-centric forum writers that you hate.