I’ve always struggled with the noise in typical office environments. It’s conversational noise that’s the problem. If there is any kind of conversation going on within earshot, the part of my brain that deals with language just tunes in to it. I can’t help it, I just have to listen! Of course, that part of my brain is also used for reading and writing documents and code, so it makes it very difficult to get work done. I suspect I suffer from this more than most other people. Every office I have ever worked in was too noisy for me, even the so-called quiet ones. In fact, the quiet ones can be worse. If everyone is talking at once, the individual conversations become part of the general background noise and it’s hard to distinguish each conversation. But in a quiet office where there is one single conversation going on you can hear every word clearly.
I may have a particular problem with this, but I think the problem occurs to some extent for all developers. The effect of noise and interruptions on programmer productivity was covered extensively in the excellent book Peopleware. I’d love it if more companies recognised that developers need quiet time to get their work done, and gave them private offices. But I’ve never seen this in any of the companies I’ve worked for, and I don’t really expect it to start happening any time soon. If anything, the problem’s getting worse, as more and more offices get built or renovated in an open plan style. Continue reading
Your code has bugs in it. Here are some ways you can find them.
Test It Yourself
I do two things to test the code I write before anyone else sees it. First, I tend to write automated unit tests as I go along, in a kind of test-driven development style. These don’t so much find bugs as prevent them from occurring in the first place, as they force me to think about the requirements the code must fulfil before I write it. They are probably at their most useful though when you discover a bug through other types of testing. Then you can use a new unit test to reproduce the bug, fix it, and be confident that it will stay fixed through future versions of the code. Continue reading
Recently I was working on a tricky problem. It was one of those problems that only occurs on a test server but not on a development box. Since the test server was hosted on Azure (the same as our live server), this made it really tricky to debug. Doing a manual deployment to the test server takes about 40 minutes. So my write-test-debug cycle was about an hour! To make things worse, it was an intermittent problem, so I could never be 100% sure when it was going to occur. And to make things even worse, I discovered that the only way to reliably get the problem to occur was to do another deployment. Simply stopping and restarting the server, which would have been much quicker, didn’t have the same effect. Yet another complicating factor was that the error that occurred wasn’t in our own code, but instead it seemed to be in some other code that was executing when a page was loaded, before our code ran. So the call stack in the exception was a load of functions in the .NET framework that I couldn’t get at.
All of this meant that I had to treat this like a science experiment: Get as much info out of the system as possible, with some hacked in debug logging, to try and find out where the problem was occurring. And try various things to see if I could get the problem to occur consistently and (eventually) to make the problem go away consistently. This involved a lot of deploying of slightly different versions of the code! Continue reading