weblog.masukomi.org

(written back in 2007)

This morning I received a rather unexpected invite to a Meetup over at the Middlesex Lounge from the people at Bug Labs. They were getting people together to discuss their new product, a modular and open source hardware platform. I figure since they were nice enough to buy us drinks I could return the favor by giving them my thoughts.

For me the idea keeps coming back to Gumstix. Gumstix has been making these tiny tiny computers that are essentially stripped down motherboards that you could run really stripped down versions of linux on. They’re pretty cool, but you really have to be willing to code with minimal support from existing …. anything, which makes them way too much of a time investment for me to want to bother with. So, while the idea of a mini computer that I could hack to do whatever I wanted is tempting, I’ve got too many other projects to screw around with a Gumstix.

Seriously. What makes you so special? It’s not that you’re brilliant, because, statistically speaking, you’re not. Sure there may be one or… maaaybe two brilliant people reading this. But, the odds are that you aren’t them. So what makes you so special? The way I see it there are three types of people:

• The people who are brilliant.
• The people you look up to.
• Everyone else.

And, since it’s safe to say that you’re not brilliant, you’re either someone people look up to or… someone else. So, what makes you so special? Are you actively pursuing your dream? Are you fighting for a cause you believe in? Are you actively trying to be the best you could be at whatever it is you do? Or, are you like everyone else?

I just received my Kinesis Contoured keyboard and thought that those of you who actually care about the ergonomics of your work environment might appreciate my first impressions of it. I also needed an excuse to type something so as to get used to it. ;)

Now, before I get started I should mention, as many of you already know, that I take my ergonomics seriously. I endured two weeks of painfully slow typing while I retrained myself to use the Dvorak keyboard layout because doing so involves provably less contorting and reaching, and is thus less wear on your hands. Being a programmer, and wanting to continue to be a programmer for the foreseeable future, and having the tendency to come home and either write or code after a long day of writing or coding I believe it to be in my best interest to take preventative measures to not end up in wrist braces unable to type for more than a few hours at a time. I use a trackball that involves minimal thumb movement, and nothing else, and now I, finally, have a keyboard that’s actually ergonomically designed. Let me explain…

Six years ago Akamai lostone of it’s founders in 9/11. It’s still quite evident what a blow it was to the people here as he was apparently a man who lived life to the fullest and really touched a lot of lives. How Akamai has chosen to deal with this loss has really impressed me. The made a little park next to the office building (at least i don’t think it was here before then) and planted a tree for him. Instead of making some disconnected financial contribution to some random charity they encourage employees to go help out at the food bank or spend time at a children’s center. They give an award every year in his name to employees who show the same kind of drive and passion that Danny had. This morning there was a small service in the park.Paul and Tom said a few words about Danny why trying not to cry. Then we had a moment of silence and those who were close to him each laid a rose next to his tree. Danny is never mentioned in the abstract here. He’s not some random guy who a bad thing happened to. His spirit very much lives on in Akamai, and that’s quite possibly the greatest tribute they could give him. This morning emphasized one thing to me. That Akamai is one of the few companies that really is a family. I may be on the outside edge of that but I feel proud to be included at all.

The best thing about Distributed Source Control Managers ( IMNSHO ) is how quick and easy it is to branch and merge. The problem is that most of us cut our teeth on centralized systems that couldn’t even hope to take advantage of cherry picking, which is, in short the ability to take a single patch out of the middle of a sequence of patches, or every patch but one from a sequence. Just imagine knowing that there was a bug introduced in a specific patch and being able to prune it from your repository but not any of the patches around it. Or, plucking one little feature out of a mass of others that should wait until the next release. You can, but if you don’t make the effort to keep your patches as atomic as possible you’ll find that that patch you want to remove or extract is dependant upon another one, or more, that you may not want to involve.

Dear Perforce:

Fuck you.
Fuck you, you miserable, untrustworthy, misleading, overpriced bastard. I hope your office goes up in flames along with all your off-site backups. I pray that some open source product that actually works is embraced by all the major companies and drives you out of business. I hope that no other company is duped by your salespeople into thinking you have something even remotely close in quality to the ancient and craptastic product known as CVS. Never before have I experienced so much pain in the most simplistic of version control tasks as I have since starting to work at a company that made the mistake of considering you.

Code Underwriters

Lloyds of London is able to do what they do thanks to the concept of underwriters. The simplistic version is that a risk is spread amongst a group of underwriters. If nothing goes wrong they get a cut of the profits relative the the percentage of the risk they took on. If things go wrong they take pay for whatever portion of the risk they agreed to take on.

Defensive Programming 101

For any given programmer the following statement should always be treated as truth:
My code sucks, but your code sucks more - Dave Astels [deleted post]

Good version control habits and test coverage will get you out of most jams related to your own code but we rarely write apps that are comprised of just our code. There are almost always libraries from other people code that you’ll include to save yourself from having to re-invent the wheel. Obviously you don’t want to start writing unit tests for code from other projects (you’d never finish) but there are some basic steps you can take to minimize your chances of failure.\

99 lines of code on the wall.
99 lines of code.
You look around, refactor it down…
98 lines of code on the wall.

98 lines of code on the wall.
98 lines of code.
You look around, refactor it down…
97 lines of code on the wall.

Or, alternately

    function singVerse(numLines){
    
        if (numLines \> 0){
            document.write("" + numLines + " lines of code on the wall.\\n");
            document.write("" + numLines + " lines of code.\\n");
            document.write("You look around, refactor it down...\\n");
            numLines -= 1;
            document.write("" + numLines + " lines of code on the wall.\\n");
            singVerse(numLines);
        } else if (numLines == 0) {
            document.write("Totally bug free code on the wall\\n");
        } else {
            document.write("Need more tests for the code on the wall.\\n");
        }
    }
    singVerse(99);

I keep thinking back to a short comment at BarCamp Manchester in the Unit Testing talk. When asked if anyone had written an app with 100% code coverage the guy beside me raised his hand. Now I’ve been advocating for a while now that it’s essentially wasted time to bother testing your getters and setters, and when I mentioned something to this effect he said, “How do you know you haven’t made a typo in a variable name?”