Some of you non-RSS readers might have noticed about a month ago I changed the theme of my blog. I’ve received several complaints about the background and don’t really feel like messing with the getting a new one right, so let’s just change the whole theme.

I was quite partial of the background as it was an abstract shot I took of a local landmark, but I had to yield to the masses…that’s a bit of an overstatement I guess; however, I can’t argue with the success.

Just take a look at the bounce rate of the blog over the past month. I will give you one guess when I changed the theme.

Pretty shocking huh? As a friend pointed out, the lower bounce rate could be because the visitors are lost or don’t know where to find what they are looking for, but as as 80% is coming in off keyword traffic and 19% are coming from my linked articles on StackOverflow, I don’t think that’s a problem.

It might have always been this way, but Flickr is making some odd choices when paging their photos. As you can see in the screenshot, it stacks the photos in three columns, but only completely fills the first two, leaving an empty slot in the last column.

I’ve tried this with several different searches, different ordering, etc, and it appears to be random. Sometimes it completely fills up the grid, sometimes it leaves one space, sometimes it leaves two. The first time I saw it, I thought my search only brought up one page of result, but then saw the pager at the bottom, along with the number of results.

I don’t know what they are thinking, but it’s odd. At least to me.

The week is coming to an end, and I have a few more mental notes to make about training in general. For the first two, see the previous post.

3. Bring your own coffee mug and water bottle.  Not only is it nice to have a little bit of home with you on the road (my favorite coffee mug has special meaning to me), but it beats the tiny styrofoam cups they provided at our training. Ignoring the environmental impacts  of using a lot of toxic cups throughout the week, it is a pain to keep getting up to refill my coffee. Also, as one of my odd observations, the more coffee I drink in these cups, the faster it gets cold, so the faster I have to drink it, etc.

4. Get there early on the first day. As programmers, we might not be the most social kids on the playground. What I’ve found is there are either predefined cliques (e.g. coworkers) or defacto cliques (e.g. those sitting immediately next to you. After the first day, you know those people, your machine is setup just the way you like it, so you’re likely to sit there every day that week. Not just you though, everyone will most likely do the same. So if you arrive late, or even on time as I did, the first day, you’ll most likely be stuck in the back. You might not be able to read the text in the presentations or see over the heads and monitors of those in front of you.

5. Export your settings and tools to the web. This is a great trick for more than even training. I was lucky enough that my post before coming here was about my new IDE colors and I included my settings file. I was able to bring it down and now my IDE here looks exactly like the one at home. If I would have exported a few more settings, all the keystrokes would be the same as well. Beyond just the settings, any tools you might use can come in handy. This also helps if you leave your company, or get a new PC or log in somewhere else. Having those things in a central place is nice. I’ve even seen people store their settings files on Google Code so they can keep a history of them, or just for a central storage location.

6. Bring a storage device. Some of the labs, PDF’s etc are nice to have. They usually give you this as a download, but being able to take what you’ve worked on in class, back to the hotel room is pretty handy.

I should probably get started on the morning lab. Hopefully this weekend, or next week I can provide a quick review of my class.

This is going to be short. This week, my company has sent me half way across the country (everything is half way across the country when you are in the mid-west) to SharePoint MOSS Development training in Tampa, Florida. I’ve been wanting to compile a day-by-day review of the course, in the spirit of Ferverent Coder’s review of the Nothin’ but .Net Developer Boot Camp NBDNDBC (I guess acronyms don’t always work). He has a wonderful review of a training seminar I’ve been wanting to go to for a while now, and his review further solidified my desire to attend. Anyway, I want to do the same thing, but don’t have the energy at the end of the day, and my days aren’t nearly as long as his.

I did want to pass along some travel tips and tricks I’ve learned in the past few days that might make your trip more pleasant than mine.

1. Fly direct. When you have to get from point A to point B, the weather in point C should not be of your concern, unless of course point C is Chicago, Atlanta, Denver, or one of the few other air plane magnets in the country. I didn’t have a choice in booking my travel, which could have been booked direct through Southwest, so instead I had a scheduled itinerary of 10 hours, but after delays because of weather half way across the country, it took 15. Google tells me I could have driven the entire length of the journey in 16 hours and Southwest could have brought me there in two. So lesson one, fly direct…or move to a hub city. Programming lesson: Tight coupling is bad.

2. Bring headphones. When attending a lecture/lab style training session. It would have been nice to have head phones to drown out the chatter of everyone else or question you don’t care to hear answered. Programming lesson: Law of Demeter.

Class is starting, so more later.

We recently pushed a feature into production that had a pretty serious flaw. If gone unfound it could have caused headaches with billing the wrong customer the wrong amount and all kinds of other potentially damning effects. Luckily for us, we also had a second bug. The feature that was to send the notification e-mail that data was ready to be corrupted by our bug was misconfigured when it moved to the production environment. Lucky for us, no one was being told they should go execute our buggy code, so no one did and we found it, fixed it and all those actions items that queued up ran through without a hitch.

Now lucky for us or not, we did fail to find two serious bugs. It highlights the need for thorough acceptance testing. Thorough being the key word there.

The first bug existed if action items queued up and were acted upon in a certain order. Testing was done in this area, but the items never fell in the order where we found the bug. Would acceptance tests go so far to say:

• Act on the first item in the list and verify the actions were taken correctly.
• Act on the second item in the list…
• Act on a list with a single item…
• Act on a list with two items…
• Act on a list with n items…

How detailed do you get? 

The first bug was a pretty lame mistake, although I feel SQL should have been alerted when we attempted to do an udate  a single from a statement that returned multiples. I don’t know how it makes sense to choose the first row and go about your business. 

As for the second, testing the production configuration is hard. We do have some junk data laying around in the production DB that we can manipulate, and probably should have to verify the e-mails were sending. Config changes between the two are difficult to manage. Keeping the e-mail address, servers, roles, etc in sync to the correct environment is made simpler by branches, but verification isn’t.

There has been a lot going on lately that prevented me from posting as often as I should. The good news is I’ve taken a new job which is sure to provide many exciting new challenges to share. The bad news is the new organization isn’t currently using ReSharper. This is something that I hope to remedy, but the ReSharper tips of the day might not return.

So in the hard times of our economy, companies cut back on non-essentials. We’ve recently gone from two coffee pots to one.* We have anther pot with an orange handle, but I can’t see the logic in drinking from that one. Only one pot means all those snaky people who leave 2oz of coffee for the person behind them holding a 6oz cup are twice as effective. You can no longer combine the two 2oz pots and get a somewhat satisfying cup of coffee.

Yesterday I was the unfortunate one who came across an empty pot. So after mentally cussing out whomever left it, I started a new one and went to the next floor where I was able to grab the last full cup. Yes! Being the good boy I that am I started yet another pot. I reached into the drawer where the coffee is kept, made the pot and started to leave. As I was leaving the room the label I tossed in the trash caught my eye. There was a little flash of green on the package. I went and looked closer. This floor kept the regular and decaff coffee in opposite drawers as the superior floor above. Luckily I caught my mistake, trashed the pot that was already started and made a proper pot. The poor souls who would have failed to receive their liquid wake up call would weighed against my karma.

It holds true in life, as well as programming. Consistency matters. We develop routines that are habitual and difficult to break. Just as the coffee was always in the same drawer, the parameters are always in the same order. Taking extra care to follow some de facto convention could save slip ups like this.

* The reduction was most likely not related to cut backs, but rather just ended up being broken; however, not replacing it may be related to cut backs.

I’ve always heard about this mythical keyboard layout that was the apogee of all keyboards, the glowing golden standard to which all others fail to equal, and the other keyboard, designed to be slow and awkward. What might surprise some people is it’s the other, slower keyboard that has sprouted up on desks and laps all over the world and the Secretariat of keyboards never gets its chance to show its true legs.

The Qwerty keyboard was designed to keep the mechanical arms of typewriters from jamming by positioning common successive strokes on either sides of the machine. In contrast the Dvorak keyboard was designed to make the most common letters and
sequences of letters the easiest to type.

While installing Ubuntu this evening I noticed the Dvorak keyboard as an option. Immediately I thought about the several Dell keyboards I have tucked away in drawers gathering dust. Now I love my new slim Apple keyboard, but I’m going to stow it in the drawer for the next few weeks. Tomorrow I plan on laying out a Dvorak and giving it a try. I would like to find a typing speed test and see how it compares to the Qwerty and how it improves over time.

I catch a lot of grief at work, hopefully in jest, about my non-traditional IDE colors. After reading through some links on A Continuous Learner’s Weblog I stumbled upon a link showing people’s dark IDE colors, so I thought I would post mine. I’ve tried a lot of different IDE colors, but still haven’t been persuaded away from my color scheme.

I stole the example text from CodingHorror. The font is Monaco which comes with Mac OS X, but can also be found for the PC.

]]> http://fooberry.com/2008/10/15/join-the-dark-side-of-the-force/feed/ 0 http://fooberry.com/2008/10/14/incentivizing-programmers/ http://fooberry.com/2008/10/14/incentivizing-programmers/#comments Wed, 15 Oct 2008 02:44:09 +0000 mark http://fooberry.com/?p=422 In most factories, especially those that pride themselves on their safety records, you’ll find a sign that says something like “600 days since our last lost time incident”. We should have the same for our automated build qualities, although I doubt they will ever reach 600 days of consecutive green builds. It would hopefully generate [...]]]>

In most factories, especially those that pride themselves on their safety records, you’ll find a sign that says something like “600 days since our last lost time incident”. We should have the same for our automated build qualities, although I doubt they will ever reach 600 days of consecutive green builds. It would hopefully generate a sense of pride in the build. Imagine if you joined a team that had 60 days of green builds and that number was publicized for the entire organization to see. Wouldn’t you take extra care to make sure you don’t do something that flips it over to red, even for one build?

Gaining momentum behind doing automated build is something our organization is struggling with at the moment. For some reason the value isn’t immediately apparent or the schedules and budgets don’t allow for it at the moment. Both of those are topics for another post. Maybe a component to gaining that momentum is illustrating the elevation and longevity of the quality of the builds. I see two metrics being valuable.

1. Days of consecutive green builds
2. Change in the number of unit tests over time

Potentially a third being the number of customer reported defects.

The number of consecutive green builds is important, but if one team is doing nightly builds and another is doing continuous integration, does one team have a significant advantage in quality over another? I would say there is benefit there, but I wouldn’t categorize the advantage as significant. Also, looking at the change in the number of tests provides a better indication of progress than percentage change. Adding a hundred unit tests to a build that already has a thousand is substantially better than adding one unit test to a set of ten. I imagine you’re saying that is still rather subjective because you could have ten quality tests and a thousand horribly simple ones and that’s true, but maybe this isn’t the place to make those determinations. Let’s assume all unit tests are of roughly the same complexity and comprehension.

So here is my question. Would it be valid and beneficial to incentivize teams to improve these metrics or compete against other teams to improve the metrics? In the past we’ve given out $5 gift cards to Starbucks or iTunes when people did good jobs on something, just as a nice “thank you”. Would that work here? Could giving a $5 gift card to the each member of the team that has the longest stretch of green builds or added the most unit tests in the last month help motivate people? Now I don’t expect people to add hundreds unit tests every month to get their free fat free half caf soy carmel white chocolate mocha macchiato (I’m not even sure that drink exists or if would be less than $5 if it did). I’m not saying those are the metrics and the periodicity of the rewards that would work the best, just wondering if the spirit of it would work.

Recent posts by Ayende and Joel Spolsky seem to imply it would fail miserably.

I’m not sure something like $5 will lead teams to work the system just for the reward. Even without the monetary reward the principle behind taking pride in the build quality could established by making an aggregated build report public. Something really public. Maybe a screen when I get off the elevators, or a TV in the lobby that gives some metrics. Let me see who the people are who are writing the most unit test. I’m sure they can answer some of my questions or give me advice. Show me who isn’t building and we can get them the help they need to get it off the ground. There should be something we could do to help.