A started a new job in late 2010. At first, it seemed like something that was too good to be true at the time. It had a lot of awesome perks (to me, in no particular order):

1. Wasn’t consulting
2. Was a product/service owned by the company and slowly built upon
3. Had a software team and manager that believed in a lot of those software principles you read about, but never truly see at your job (confession: we’re not perfect, but we strive to always improve)
4. Was a telecommute job with very little travel
5. Used the technology and practices I wanted to use

I’m not here to recruit (although at the moment we are hiring) you, but to share a set of experiences that had me baffled until recently.

Whenever I start a new job (or project, as it often is in consulting), there is a period of time where I know absolutely nothing about the software you are writing and the business behind it. After a few weeks or months (depending on the size of the project and code base), I’ve always felt very comfortable. If I ever made it to the year mark on a project, I could recite policies and procedures (even to this day for previous projects, in some limited capacity).

But my new job was different. I hit the six month mark, and still knew less than 50%. Now, at a more than a year with the company, I realize that I may lucky to reach the half way point in knowledge, if I am lucky. This bothered me a lot.

Why wasn’t I learning this new code? Was it harder? Was I losing my touch?

Why wasn’t I learning the business? Was I not paying attention? Was it because I was working from home?

I was lost.

Only recently, I realized the answer to why I wasn’t understanding the business behind the job. Put simply, I didn’t fully understand the business. I was no longer on the “front lines”, sitting, talking, planning, prototyping, demoing, testing, and involving the end user in day-to-day project activities.

Instead, I was on a product development team, sheltered from the “why’s”. Instead, I had plenty “what’s” and “how’s”, but never a good explanation why. Sure, there were some user stories, but never did I get the depth of knowledge gained from being there with the end user, watching them work, and truly understanding what the needed.

How have I solved this problem and why am I happier? I’m not sure it is truly solved. I volunteered to work with a client more directly. In two months, I feel I know their business and needs better (but not anywhere close to completely) than what I learned in the first twelve months. I’ll be master of a few things, instead of a jack of all trades.

Sure, there is a larger slope to learning “everything” this time. I’ll eventually get to “the guy who knows a lot”. In the meanwhile, I’ll be happy to know what I know and to know how to find answers to what I don’t.

One of those “fun” activities developers look forward to is merging code from one branch to another. The scenario I personal use most is merging changes from the trunk back to the branch that is about to be released.

For the last few releases I’ve deviated from my normal usage of the built-in merging capabilities of (Tortoise)SVN. Instead, I’ve made a patch of my changes just before I’ve checked them in (to either trunk or the branch, wherever I’m working). I then apply the patch to the other.

The upside is it’s a lot easier and generates less mess. Perhaps I merge to infrequently and forget the “best” way, or run into troubles because SVN is, well, SVN. The downside is I lose the context of the merge. Nothing ties to the commits together (arguably, I could commit at the top-level of the repository, but I’m not currently setup to do that).

Is this good, bad, or just preference? I’m not sure, but I’m a fan of anything that removes development friction.

User reviews saved e-commerce — the power of the Internet buying masses, crowd-sourced into a win-win situation for both retailers and consumers (B2C!).

The above is a lie (and also hard to read, filled with terrible e-buzzwords).

User reviews are difficult to parse, give a false sense of security to the buyer, and are one of the many profit-extraction tools that retailers employ. How many times have you seen a 4 or more star review (out of 5) end up being a complete dud? How about a poorly review app on your phone actually being quite good (Amazon app store, I’m looking at you).

I’ve finally gotten to a point where I feel comfortable parsing the reviews and discerning (potentially) valuable information. I try to end up with one of the following (mind-blowing) generalizations:

1. This product is worth purchasing
2. This product is not worth purchasing
3. Not enough information is available to make a decision

Often the journey is the reward, not the destination. How do I parse all of the reviews, both good (in content, not score) and bad? I want to know what’s genuinely wrong with the product, and if I’ll be okay with it. I’ve come up with a few rules that help me determine this:

1. Score doesn’t matter
2. Read most or all the bad reviews (within reason)
3. Read a random sampling of average and good reviews
4. Discard the overly positive lovefests and the snarky, curmudgeonly negative reviews

So how does this relate to software defects? Defects have a stigma attached to them. They are often an unfair “1 star” review by the person reporting the issue. When prioritizing work, these sour items have the possibility to poison the choice of the work that gets done. Each defect needs to fit into one of the three categories, conspicuously similar to user reviews:

1. This defect is worth pursuing at this time
2. This defect is not worth pursuing at this time
3. Not enough information is known to make a decision; research and reevaluate until #1 or #2.

What technique and tidbits can you learn by reading the list of defects as if it was an anonymous user review?

1. The priority of the defect as determined by the submitter may not represent the true priority within the project
2. Read all the comments, and similar defects, and weigh together
3. Deflect the overly negative opinions of your software; a single defect can change the opinion of the software, but shouldn’t change the team’s motivation
4. Likewise, don’t get trapped only hearing the positive feedback. I’ve yet to meet a project that has zero defects (although I did have a manager once who claimed his last project didn’t have any bugs and that was the standard I was going to be held to)

Often times, a sign of great software are the requests for enhancements by the end users. At a glance, user reviews don’t give an accurate picture of what’s right or wrong with a product. Likewise, defects (and enhancement request) don’t always tell the story of where your project needs to focus its energies.

User review and software defects have their value when evaluated together. Also, if you liked this post, be sure to give it a 5 star rating. ;)

The Getting Things Done methodology encourages behavior such as Inbox Zero, the concept of dealing with all the items in your inbox and keeping a zero count. In previous jobs, I’ve tried to do this, and struggled at times, having as many as 1000 items. Even when triaging my inbox regularly, I’d still end up with 50 items that needed some sort of attention.

Lately, I’ve been using Gmail for personal and work email, and have found a balance that isn’t as stringent as inbox zero, but eliminates most of the mail. I call it Inbox One, as in one page of email. At any given time, I have at most enough email to fit on one page. As soon as it gets larger than a page (or I get a downturn in work), I clean it out as much as I can.

Currently, I have 3 items in my work inbox (up 50% from this morning, oh no!) and 10 items in my personal email inbox. Only 1 of those 13 items need attention today.

I still follow the Inbox Zero teachings, but try to be a little more pragmatic. Not everything needs to be handled immediately, but as much that can be dealt with quickly, or properly scheduled as work to do in the near future, I take care of. What is left are a few items that eventually need to get done. Like Inbox Zero, anything unimportant is archived, deleted, or filtered.

Inbox Zero is near impossible to maintain all the time unless you are very self-disciplined. Inbox One is far more tenable.