Over the past week, I’ve listened to and read several articles that have started me thinking more about the Psychology of Programming.
Not that I haven’t been thinking about this for a while. I’ve been quite intrigued by human behavior for a while now. But more recently, there was this podcast over on dotNetRocks about “Punishment Driven Development”. And this comment:
The happiest people in my experience are those that have options. They have transferable skills, see their employment as a personal choice, have self confidence that they are providing value to the company and are in a position professionally and personally where they could change job if they needed. The feeling of being trapped in a position from which you can’t escape (either a dissatisfying job, bad manager or whatever) will lead to negativity.
Which I almost agree with, except I think it is the negativity that leads to feeling trapped.
I’ve been studying topics related to social science recently and one item that keeps popping up in various places is the idea of luck. It turns out that lucky people aren’t really all that lucky. There life has been arranged either by them directly or indirectly by their environment so they end up having more chances of good things happening to them.
So, how can we apply this to programming? How can you be a lucky programmer?
Over the last week, I’ve been helping other programmers estimate the task they’ve been assigned and this has caused me to reflect on how I estimate software. What works. What doesn’t. What mistakes I see people make.
There has also been a move to avoid estimates entirely. The argument goes something along the lines of, “we know the least about a project at the beginning of the project, so we can’t really give an accurate estimate.” Which is mostly true. And yet, there are people who need to know “how much is this going to cost?” What do we do for them? How do we balance the two realities?
And then all of this lead me to think of all the ways we sabotage our estimates, or our estimates are sabotaged for us.
You might think that estimating projects only applies to project managers. But the truth is, most places I have worked rely on programmers to give them estimates, and frankly, most of us screw this up.
Today I saw a GREEN traffic light for the first time.
OK, that’s not entirely true. What I mean to say is that I saw that it was green.
You see, I was born color blind. This never really bothered me because, like most people who are handicapped from birth, I didn’t know what I was missing.
But then, I found out that there is this company that sells glasses that help color blind people see color. They are pretty expensive, at least they seem pretty expensive when you believe you don’t really have a big problem. But then I took the standard color blind test on their site and found out
I’m color blind (duh!)
there is an 80% chance that the glasses would help and
I only see 2% of the available color spectrum.
Wow! Only 2%? I knew I had issues. But I’ve been able to function. But only 2%. What am I missing?
Well, my wife got me a pair of glasses for Christmas. Unfortunately, I ordered indoor/computer glasses and what they sent are sunglasses. I’m still trying to get that resolved. But just for kicks, I wore the sunglasses out while I was running errands today. This is the first sunny day that I haven’t been stuck inside since Christmas. The reds are redder, the yellows are yellower and, hey! Guess what?! The green light is actually green!
So, what’s this got to do with programming? You did know this was going to eventually relate to programming right?