Posted on Feb 7, 2010

Superbowl Program

My company did the digital edition of the Superbowl program this year. Check it out:

Look inside >
C4 Cover
Super Bowl XLIV 2010

Posted on Jan 28, 2010

Posted on Jan 17, 2010

CES 2010

I had the pleasure of going to CES this year. It was an amazing experience. Learned a lot and got to see a small slice of Vegas. Here’s the proof.

CES 2010

Posted on Dec 25, 2009

The grandfathers

baldinoos posted a photo:

The grandfathers

Grandfathers doing what grandfathers do

Posted on Dec 25, 2009

Liam and Timmy

baldinoos posted a photo:

Liam and Timmy

Posted on Dec 25, 2009

Liam on Xmas

baldinoos posted a photo:

Liam on Xmas

Posted on Dec 12, 2009

Zenbe Lists

Since moving to management I’ve had trouble staying organized and keeping track of TODO items. I recently downloaded the Zenbe Lists app and it’s been awesome. Really simple, syncs with web, quick to add and prioritize items. I’ve found it particularly useful for jotting down random ideas in meetings and discussions in the hallway. Highly recommend.

Posted on Dec 9, 2009

Engineers Union

Now that I’ve worked for a couple years in a drastically different environment I feel I’ve gained some perspective. I spent the first 7 years of my career at a large company (~80k employees) and moved to a small company (~50 employees). The things that drove me insane about the first 7 years are wildly different at the smaller firm. When you’re trying to decide to make a change you wonder if your observations are correct and concerns are warranted. The large company (at least the one I was at) will attempt to tell you that this is the way things are EVERYWHERE and you’ll just run into the same problems if you go elsewhere.

The Primary Concern

No matter how hard or efficiently I work, everyone’s salary and promotional schedule move at the same rate. After 7 years of “exceeds expectations” reviews I found myself no further ahead (in engineering level) of those who were getting “meets requirements” or even “needs improvement”. Since salary is tied to engineering level, I assume I was only slightly ahead of the curve if at all. It basically worked like an engineers union; everything is based on seniority and not quality of work. The higher on the engineering scale you climb, the more pronounced it becomes.

I’m operating under the assumption that most people want to advance their career in some way. I’ll call these people Group A. I know many people who don’t, and this union-like environment is not a problem for them. These people are content with having a decent job and the challenges it provides – I’ll call these people Group B. I’m not knocking the Group Bs, it’s a fine way to live – I’m just not one of them. For those of us interested in having a meaningful career filled with different challenges and opportunities, this paradigm is not acceptable.

I can’t function effectively in these environments. Invariably, what I’ve seen with people from Group A that do not move away from the large company is one of two things:

  1. They put it in neutral and coast through their career OR
  2. They move around within incessantly, looking for spots to move up and grind out an extra one or two engineering levels before calling it quits

My decision to leave was based on this observation. I could never be happy putting it in neutral. I enjoy and take pride in my work and if it ever gets to the point where I feel like I’m not challenged or don’t care I will change roles/careers. I’m also a firm believer that working hard, being efficient and innovating should be rewarded. Too often I found that raises and promotions are based on things that don’t have anything to do with the quality of your work. Things like filling out your timecard every day, completing the mandatory number of hours of training courses, etc were valued at the same level as your actual output.

The union mentality does not sufficiently reward the knowledge worker

The Result

After spending a couple years at a small company I can say that despite having my doubts about making this change, these problems have been addressed. In a small company it’s easy to tell who is productive and who isn’t. The health of the company depends on employees being productive, efficient and innovative. It is therefore in the company’s best interest to reward this behavior to stay healthy. There are far fewer rules about who receives what rating and raise during reviews, no quotas, no caps. The only question asked is whether investing in this employee is going to help the company. Smaller companies do have downsides that should be noted, the largest being that they are prone to instability, but having some effect on the bottom line is incredibly motivating and exciting.

A Word on Software Measurement

Every company wants to be efficient and having measurable output is incredibly valuable in determining how efficient an organization is. The challenge is to figure out how to measure output. In larger organizations, top-down one-size-fits-all initiatives to make it easy to measure output make logical sense. I seriously doubt the company I worked for had very many software developers making decisions about these initiatives. The largest measurable output we dealt with was the SLOC, or Standard Lines Of Code. After all, the more code being written, the more productive you are.

This is of course laughable to any software engineer. It was incredibly discouraging to see how many hours were wasted finding ways to count the lines of code being produced. Formulas did not account for the language the code was written in, or the quality of the code, just the lines. If a top-down initiative resulted in more lines of code, it was a success. Software is incredibly difficult to measure as an output. In a widget factory, it’s easy to measure the number of widgets produced and determine efficiency. This is a horrific mistake in software. Even if it were possible to measure software output, the field is constantly changing; new frameworks and libraries are constantly being introduced, more efficient languages and compilers, etc. Even if a way to measure software efficiently was invented for the current state of the world, it would immediately become obsolete. Please stop trying.

I also believe that the amount of possible innovation is inversely related to the amount of formal process required. We saw this happen at 3M. For some large companies, including the one I worked for, innovation is not important. It’s also incredibly boring from an engineering standpoint. Engineers like to innovate and solve problems, it’s what drives them. Engineers should not be tied down with formal process.

If you want to run efficiently, spend lots of time choosing your leadership and management teams all the way down the ladder and trust them to handle it. Using an agile development process helps tremendously. You see daily output and quickly get a grasp of who is performing. Constant communication of goals and priorities also ensures everyone is working on the right things.

Posted on Nov 28, 2009

Posted on Nov 27, 2009

WordPress: Fatal error: Allowed memory size of xxx bytes exhausted

This took me several hours of my time so I’m posting it for posterity. Like many people, I began getting these errors when loading my blog. In most cases, this indicates a memory leak in a plugin. I upped the memory limit in my wp-settings.php for a while but my blog became incredibly slow. I tried disabling plugins one by one, changing my theme, etc. I installed the wp-memory-usage plugin which led my nowhere. Finally, I figured I’d optimize my database and I found the wp-dbmanager plugin and noticed my wp_options table was 463 MB in size (compared to 900k for my wp_posts table).

It turns out I had over 1000 rows of cached rss lookups (select count(*) from wp_options where option_name like ‘rss%’). It is safe to delete these rows and it fixed the problem. I now have a working blog again.