Christopher Warner Studies and thoughts, usually in coherent fashion.

15Dec/110

Cognitive Bias and The Mary Protocol

I have lots of questions

Everything you look for and all that you perceive has a way of proving whatever you believe.

Every now and then I am reminded of cognitive bias as presented by Kruger-Dunning in the paper Unskilled and Unaware of It: How Difficulties in Recognizing One's Own Incompetence Lead to Inflated Self-Assessments. As I have been active in the opensource community for close to 18 years now in some form or fashion the first lesson I learned is that if you have never done it before. You don't know. It's just that simple, and this lesson tends to stick with you with in almost every facet of life. It affects ones approach to problems such that every problem starts with one question. Quickly and summarily followed by a series of questions that need to be answered. My standard trajectory usually begins to branch off in a series of questions leaving me with few answers and even more questions to which I simply don't have the answer. Early on this led to a slight madness as I would start down some rabbit hole and end up working on some esoteric issue that affected a handful of people. In retrospect, I was young and dumb, back then I thought that so long as you plugged away at it. No matter how long it took you, you would be able to answer anything. Now that I'm slightly older, and know how dumb I still am and how valuable it is in choosing the right question, I am able to avoid madness. Of course, sometimes it will sneak up on me and I find myself doing something that makes absolutely no sense at all. This is obviously why we call it madness, but I'm much better at avoiding it or tolerating it depending on my needs or condition. I'm of the mindset that madness can't be cured, only managed.

Usually if I receive an email or a critique of work furnished that needs a sign-off, peer review or some such. I'm wholly open to it because my first assumption is that if I'm treading new or unfamiliar water then I obviously don't know what I am doing. Secondly, the more eyes the better. While treading familiar waters I am much less open to critique or suggestion unless I feel it will beneficial, primarily to avoid rabbit holes but also due to a lack of time. New variables mean risk and if there is no gain by adding the element of risk to something that has been tried and true. I'm unlikely to entertain or even respond to it. This is not necessarily always the case but largely this behavior I feel has strengthened my ability to stay focused on the right question and to avoid rabbit holes.

I think proponents and participants in opensource operate within the same vein and mindset for the most part. It's more of a behavioral mindset or lifestyle, propelled by the some itch, urge, quest to solve a given problem and find the right answer. Whether it be for fortune, fame, enjoyment or some other facet. You work the problem until you are tired and move on to some other problem whether it be in the same domain or somewhere else. Hopefully you were able to answer a question or two and because it's opensource inevitably someone at some point will continue finding answers to questions old or new.

I'd appreciate much more answers however

Lately though with my own interactions I feel as if this isn't the case, partly because I suspect their is a racial and gender tinge to cognitive bias that is ripe for exploration. This brought up in a couple of discussions on gender recently. Specifically in regards to women in opensource and generalizations of women by men in general. Before these discussions a couple of weeks earlier I had recently finished reading a post by Daniel Stenberg titled "Three out of one hundred" (which I recommend you read) so the conversation and ideas were fresh in my head. Also, I had a heated discussion about some work where I can only make the assumption that because of my skin color this person thought that somehow they knew better and would simply do the exact opposite of what I said. To be brutally honest, sometimes this works in my own favor, and to be blunt, I'm a capitalist and love money so cleaning up a mess may work out for me in monetary fashion. I mean, ignorance is costly, but let me be clear. Unlike agile salesmen, I try my best to offer clear and abrupt warning.

On the whole though the idea is that men on average will make the incorrect assumption that they are more capable at a technical subject than their female counterparts no matter how qualified they may be. Women having to deal with this their entire lives tend to see the bigger picture and avoid what they consider to be rabbit holes. As a woman I would ask why? Why even bother going down that route if every time I do someone is going to offer to second guess me? This coalesced quite nicely with another discussion I had on generalizing untrue statements as applied to women. So, let us take for example the statement, "all women are batshit insane" as clearly being a gross generalization. Amongst a group of men shooting the shit  it may be viewed as an off-cuff remark, in a mix of women, it will still be viewed as an off-cuff remark but it will be normally tolerated, at least to your face. However, this one statement in and of itself subtly reaffirms subconsciously that there must be some bit of truth to that statement. Thus, most women are indeed insane, maybe not batshit insane but a mild course of irrational behavior is expected. Of course this statement is simply ridiculous! I don't have the actual data to back any of this up and saying I believe it to be true isn't enough for an idiot, I realize. That aside, I am ashamed to admit that I am guilty of remarks like this myself. I've tried to rationalize the comments with "it's about context" but I can't qualify that as an "african-american" male. Is the statement "black people know jack shit about computers" any different? It's generalistic, and is again ridiculous but do we subconsciously hold onto these ridiculous generalist statements and again subconsciously use them to validate our own cognitive bias? Of course if that is actually the case there will be less women in opensource because all the men seem to think they are superior. Can you really blame someone that can't get a word in edgewise, everything they do is second guessed, or felt to be inferior? Doesn't sound fun to me at all, especially when you are paid less and have to doubly prove yourself answering harder questions. In short, fuck that noise. So of course, there will be less of any group that isn't already in the majority. Which means we have much less answers to our questions. This is unacceptable and we must try harder not just in our professional but personal lives as well.

The Mary Protocol

In response to my own behavior and to help me realize when I may be making a generalist statement that I may not consider hurtful, insulting or a turn-off to someone. I've implemented the Mary protocol. It's a simple procedure that will help me, help myself.

  1. The moment I may have said something and/or heard someone else say something that sounds ridiculous enough to either retract with an immediate apology or to pause the conversation with a "not cool". I will do so.
  2. I will not argue about my position beyond stating that i'm invoking something known as the Mary protocol to help myself from reinforcing my subconscious with nonsense and to allow for open discussion if the offending party would like to hear more.
  3. I will do my best to keep any proceeding conversation succinct and within reason.

The protocol is to be like a bit of a tase to correct my behavior. Not because I want to become some righteous feminist with a penis but because should I have a daughter someday I'm quite sure i'd take high offense to anyone calling her batshit insane, or treating her in inferior manner in anyway shape or form. So much so that I pray to never see it occur in my presence for the safety of the offending party. Off-cuff or not, it's not acceptable behavior and I will not continue it. It is my hope, that you do the same.

14Sep/100

Forget Agile, try Software Engineering.

Here are some tips on my new methodology in no order for software engineers and management. It's not XP/Scrum or any take on Agile because NONE of this is Agile in definition, manner or anything else. I like to call it, "Software Engineering (or SW for short)". I'm gonna make this short and I'm not going to qualify anything because I don't feel like I should have to.

  1. Should you need someone to tell you to chop up your project into smaller units that are more easily digested? You're a bad manager/team lead/leader/whatever you are calling yourself. Needless to say a two or three year old is smarter than you and that MBA money went to waste.
  2. If something is a smaller unit, that doesn't make the problem you are trying to solve through programming or anything else any easier.
  3. If you need someone to tell you that you need to sit down and discuss what you plan to do before you do it? You're a bad manager/team lead/leader/whatever you are calling yourself.
  4. If there are more bad than good things to say about something. It is rotten, throw it out.
  5. No external force can run your company better than you and your employees.
  6. Team building involves no methodology, it's a constant reassessing and making tough decisions. You want to make your weak programmers strong and reward your stronger programmers appropriately. If you need someone to tell you this. You're a bad manager/team lead/leader/whatever you are calling yourself.
  7. If you are a programmer that can't say "I don't know, i've never done it before" or "This will take too long for X reasons" and/or "I don't know anything about X". Grow some backbone, you seriously aren't all knowing either so stop acting like a dick.
  8. If you are a manager practicing Agile in any context. You're a bad manager/team lead/leader/whatever you are calling yourself.
  9. There's nothing Agile about agile; Work is work, someone has to do it no matter how you cut it up. Agile doesn't make your resources work faster, more smoothly or any of that.  Building a comprehensive team does that; not some methodology.
  10. Why can't you all be like Google and have the best programmers/admins working for you? You don't reward or pay a decent salary, and then on top of that you use crappy ass tools. Google is only successful because good programmers decide to work for Google; not because they have some secret sauce. That's how it works for ANYTHING. When the best people want to work for you well then you're gonna corner any market they are in. If all of Google's programmers left tomorrow they'll be a closed shop soon as those programmers go to Doogle.com or whatever.
  11. How can I get the best programmers working for me? Choose the best tools and only the best tools. They will come looking for you; guaranteed. In your next job posting put "We like to use these tools, because they are the fucking best most awesome kickass tools available and we are building great shit." Also, i'd recommend not having HR write up the copy and less the profanities. Keep it simple, short and to the point. See what type of reaction you get.
  12. Software engineering is mentally draining. It's not like filing papers. It isn't rote, so you can't treat your employees like it's some factory line.
  13. The best feedback you get is from your programmer and if he/she gives you a comprehensive reason on why X is horse shit and it makes sense. Heed that warning.
  14. Here's a typical stakeholder request. "I want to go to Mars". Here's a typical agile response "Lets break that story down into tasks and see how best we can do this if possible or break the overall problem into multiple sprints". Here's a typical Christopher Warner SW response "Well, I don't know if i'm in the right room at present but this is not fucking NASA, there would have to be a lot of work to get there. Maybe you should think about getting to Florida first".
  15. Here's a typical Agile question "If you're in space and lost your tether and you had X tools which one would be best to use in aide of saving your life". Here's a typical agile response "The gun would be best". Here's a typical Christopher Warner response "You're fucked". It doesn't matter what tools you have at that point. The idea is to NEVER lose your tether so you never have to make that decision.
  16. How do I know I have a good programmer/admin? He or she is usually busy getting shit done, and pretty much needs little to no management. They tell you what's going on, how things are progressing. What issues problems, concerns they may have etc. Pretty much everything is quiet on the front when they are around.
  17. How do I get a team of good programmers? Good programmers will want to work with good programmers. Primarily because when one gets lost it pays to have a decent wing man or someone who can say "Welllllllsssssstttt this isn't working because you're a fucking idiot and wrote this module wrong, you're a dumbass. We'll work it out over lunch.. you know what?? lets finish this in X's office she's working on some similar shit; we'll order up. Bang this out and then hit the gym, after the beer you buy me. It always taste different when you buy it".
  18. How do I reward my team? Contrary to popular belief, money is on the top of the list but sans that proper recognition. Beers and pizzas and all that shit, save it for highschool. At the very least offer expensive liquor, we are all adults here.
  19. How can I be a better manager/team lead/leader/whatever you are calling yourself? Make sure the road is paved and fill in potholes. When something from the top comes down that is horse shit? Say "This is horse shit". Don't go back to your team with a "This is horse shit but we have no choice."  Say "This is horse shit, I said it's horse shit and I explained the detrimental waste of fucking time. They still want to do it. Of course, you guys are free to do something more awesome and when asked I'll show them more awesome with a, my apologies, I guess this more awesome thing I have right here will have to suffice" or "Sorry we just can't fucking do this stakeholders.. It's just not possible for X reasons, the top one being that I know my job better than you and this request is simply in management lingo, UNpossible". Wrap that in termination free language; unless you happen to be in a mood in which case have another job already lined up and be sure some of your team can come. Don't want to abandon them.
  20. "I don't know anything about computers I just want a measurement of when I can expect things!" When it's done, or accept variable estimates. Unless for some reason you believe the art of writing a program to be a measurable unit of work. In which case, let me explain. Writing a program is much like being an artist. You start with a blank canvas with a couple of constructs and then you have to take whatever came out of the human MIND and create a reality out of it. Think it's easy? Think of anything you have never built before until now.. Now go build it, but before you do. Tell me when it's gonna be done. I'll wait.
  21. Anything successful takes a long time of proper foundation building, team building and regression. If you don't have that or experience it. You will not be successful. It's that simple there is no methodology or luck involved besides hard work and building a good team. FOR ANYTHING.

Ok that's enough. I hope you apply "Software Engineering" as a method to your next project; even if it isn't software.