Oct 11 2011

Keep Code Statements Simple

I don’t count my progress by the line of codes but at the same time I don’t take pride by over engineering a solution. Writing code is like writing for a publication, you have to know at what reading level you are writing for. That said, the one type of code statement that gets under my skin is what I call the run-on code statement. A Run-on code statement is one that has multiple method calls in one statement. Here is a made up example of a run-on code statement.

DataManager.getInstance().refreshData(obj.getAsInteger().toString());

In the above run-on code statement there are four method calls. I’ve seen worse. The reason whey run-on code statements are a pet peeve or mine is that if anyone method call fails because of a NullPointerException or some other error it’s difficult to quickly know what segment of the code statement failed. This is also annoying to debug if you want to step into one method out of the four.


Oct 1 2011

Team We

Even when I have been the sole developer in a class, interface, module, library, or feature I try to always report progress as “We.” For defects and issues it’s always easy to point out the fault and personalize the problem when it was caused by someone else. Avoid naming names or singling out an individual. Saying “Your broke this” doesn’t make you look better or solve the issue. Restate it as “This was broken by this change list you committed on this date while trying to resolve this other issue.” Don’t personalize blame or fault, and provide as much information as you can gather to better solve the issue. Don’t stop when you find something is broken, or when you find who broke it, find out why it was broken in the first place, and if at all possible suggest viable solutions.

A few days ago, a engineer called me over for some help. He immediately started making using accusatory language as if I had committed some crime. “There is a bug and you wrote this so you did it and you didn’t do it well because there is a bug.” He was pointing to 20 lines of code that I had written over a year ago in a much larger feature whose requirements had changed over time and because of his tone and desperation in his voice I could tell he was lost just dropped the anchor of blame wherever he could. I tried to get focus to the task at hand an not my code and asked a series of questions, what does the system do now? What should the system do? Does this always happen? What is unique when there is an error? Using this approach we found the issue in 10 minutes without staring down the code or focusing who wrote what method.