There's an interesting post over on the Hut 8 Labs blog looking at overconfidence in developers and how it effects their estimations of the time it takes to get things done.

I’m going to talk today about what goes on in inside developers’ heads when they make estimates, why that’s so hard to fix, and how I personally figured out how to live and write software (for very happy business owners) even though my estimates are just as brutally unreliable as ever. But first, a story.

He talks about one of his own experiences about overconfidence and how he found a connection point in a section of a book with it as it talked about overconfidence. He talks about why you (we, as developers) suck at making estimates and how it should be less of a "how long to do it" question and more of a "how confident am I that I can do it" question. He points out that there are some situations where estimations don't suck - 0-12 hour tasks.

So what do we do? Just accept that all our projects are doomed to failure? That we’ll have poisoned relationships with the rest of the business, because we’ll always be failing to meet our promises? The key is that you first accept that making accurate long-term estimates is fundamentally impossible. Once you’ve done that, you can tackle a challenge which, though extremely difficult, can be met: how you can your dev team generate a ton of value, even though you can not make meaningful long-term estimates?

There's an interesting post on Eric Holk's blog talking about how we read code - a look at the results from a psychology experiment that tracked the viewer's eye movement as they scanned through code (complete with video).

The goal is to figure out some way of measuring what features in programming systems help programmers understand wht they are doing, and how this can be used to make systems that lead to higher quality software. Mike is currently running an experiment where he shows people several short Python programs and asks them to tell the output of the program. The test subject is sitting in front of an eye tracker, so afterwards Mike can see where you were looking at various times during the experiment.

The results are pretty interesting and Eric likens it to a sort of "just-in-time compilation" that the mind is doing as it reads through the code, not a straight forward read through. The timing of the read is interesting too, noting that once something is figured out, it's run through faster the following times.

One aspect he’s interested in is how the approach of inexperienced programmers differs from that of experienced programmers. For example, there seems to be some evidence that following variable naming conventions helps experienced programmers understand the code much quicker, while breaking these conventions leads to a severe penalty. On the other hand, inexperienced programmers seem to take about as long regardless of how the variables are named.

This study is still going on and, if you're in the Bloomington, Indiana area and would like to lend your eyes to the cause, send an email over to Mike Hansen (more on the subject on his blog here).

Felix Geisendorfer is taking an interesting approach to defining programming in this new post to the Debuggable blog - he's coming at it more from the level of the perception the programmer has about writing good code.

I believe understanding the patterns in your own thinking will by far make the biggest impact on how good you will get as a programmer. Forget design patterns, forget unit testing, forget all those functions you know. Important is to question why they exist and how they could be improved.

He illustrates through a few examples what he means. He describes one such thought method, the "return home early" process - basically, if something looks too complex for its own good, it probably is. He offers a different way of thinking about it too, a more visual way that can help simplify things even more by laying out the pieces and seeing where they all fit.