When you’re stuck…

August 11, 2007

As a programmer adding features to someone else’s code you are likely to run into problems. This happened to me this week when I was tasked with a feature request for a mobile device application. The idea seemed simple enough and had I written the program the data I needed would most likely have been readily available. That was not the case, every time I made an assumption on how the code was written I ended up being wrong.  After learning how the code worked I began working on my solution, adding properties and functions as I felt necessary. Finally I thought I had it finished so I started testing it. To my dismay, but not surprise, my new feature didn’t work right. It started by displaying the correct data but during a use-case test it didn’t update properly. Turns out that even more assumptions I had made were wrong. I know… what a shock! At this point I was frustrated so I tool a break and emailed a friend. When I got back to the code a much simpler and actually functional solution dawned on me. What’s worse it only took me 10 minutes to make the necessary changes instead of the 2 days my first solution took.

So what am I trying to convey here you ask? Take breaks–get your mind out of the problem and let your sub-conscience grind on it for a while. Everyone has something else they can be working on if they can’t take an actual break. Don’t get attached to your first idea, at least for me it’s usually wrong. Leave yourself open to other possibilities and try to follow the KISS (keep it simple, stupid) method. This will help make the job of future coders easier. Also, try not to blame the previous programmers who worked on the code. Complaining about the old code doesn’t solve the problem just wastes time that could be used fixing it. We all write bad code at some point in our career and be assured that someone will be cursing your handiwork maybe even be you.