There are two twin evils that I see in the programming community. The first is the programmer who knows what he knows and has no desire to learn more. I call these, “coasters”. And then there are the programmers who are so curious that they try to learn every new thing that comes along, with no focus. The interesting thing is, both of these types of people end up at the same place. Out of work. The cure for both is the same. Being Awesome.
To say there are secrets to being a confident programmer may seem a bit over the top. But, you would be surprised at what makes a programmer seem confident, how you can be more confident, why confidence is no real indicator of truth, and why you need to arm yourself against confidence.
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.
And then there is the book I am reading, “Influence: The Psychology of Persuasion” which goes into detail on why we make decisions that seem to go against our better judgment.
And all of this culminates into the following thoughts:
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.