zobie's blog I create software, I like music, and I'm mildly(?) OCD.


My New Job (Title)

It has been quite a long time since I last posted anything to my blog. It's not that I haven't thought about it or that I haven't had time (though life has been busy). I've struggled topically with what to write.

This blog was started with the intent that I would share things about my work: creating software. But, over the last year my job has been in a fairly constant state of flux with my responsibilities shifting radically from what I was doing previously.

I love being a software developer. I love the problem solving that the work entails. I love being in "the zone" while writing code. I love creating something that others find useful and I like to think that I am fairly good at it. Wishful thinking? Perhaps. But, at least one other person has thought me passable, so I choose to believe. 🙂

At present my job title is VP of Software Architecture. In my new responsibilities I still get to solve incredibly complex problems and derive a lot of satisfaction from it. In many ways the things I work on now are more intricate and stimulating than what I did previously. The only downside is that I rarely get to ride "the zone" via coding anymore.

Two years ago, if someone had described my current job to me and asked if I wanted the position, I would have turned them down outright. I derive so much pleasure and satisfaction from writing code that I could not have imagined wanting something else. I was firm (and vocal) in my commitment to avoiding "the management track." How then did I end up here?

I joined Mobile Productivity, Inc. (MPI) in January 2004. The people were great and the work was both challenging and interesting. But, after a few years I started to grow bored. Nothing had really changed, except that I wasn't creating new software anymore. I was responsible for a significant portion of our flagship product, ARGIS (since rebranded MPI Edge), but I had rewritten most of the code several times and just wasn't being stimulated the way I once was. I decided to leave MPI to go work for another startup named Podango.

Podango was a good company in many respects, but like many startups it wasn't able to thrive and closed at the end of 2008. Friends at MPI heard that I was in the job market and offered me a position. I was a bit hesitant, but a lot of new things were happening and I felt good about returning.

Internally at SRS, this period of my career is jokingly referred to as my "sabbatical."

Somewhere in all of this, MPI acquired several companies and was renamed Service Repair Solutions (SRS). We've grown from 25 people in a single office to just under 600 total (including offshore teams). The Engineering department alone has over 200 people spread across offices in Utah, Minnesota, Uruguay, Vietnam, Las Vegas and Russia.

I'm not worried about growing bored again any time soon. My job is awesome!

Tagged as: , , 1 Comment

Thoughts on Doing Contract Work as a Software Developer

As I was recently looking for new employment I spent quite a bit of time deciding wether I might enjoy doing contract work full-time. I enjoy working on different projects and learning new things but there is one major roadblock to becoming a full-time contract developer. My personality doesn't let me write software that is anything less than my best.

WARNING: Gross generalizations and simplifications below. I'm not trying to offend anyone, just describe my experiences.

Most of the contract work I've done has been for people who are not technically savvy. They come to me with a very vague idea of the software they want. They expect me to tell them how much it will cost before we've discussed specific requirements. When the requirements are incomplete or incorrect they expect that I'll just fix it without additional cost to them.

Not all of my contract experience has been negative. In fact, most of it has worked out quite well. Usually both my client and myself are pleased with the software and the cost of building it. But I've had enough negative experiences to be careful when considering a new job.

Part of the problem is that it is nearly impossible for anyone to completely define the scope of a project. There is always some miscommunication or misunderstanding, there is always some unforseen problem.

"You want me to setup a blog for your company? No problem, I can get WordPress setup for you in an hour."

"Wait, I didn't realize that by 'blog' you meant store front application that can accept payments, handle accounts payable, accounts receivable and inventory tracking. That will take slightly more than an hour."

That kind of situation actually isn't bothersome to me. As a contractor it is part of my job to understand what you want before making a bid. If a potential client obviously doesn't know what they want, I can either decline to bid on that job or I can adjust my bid to account for a large amount of unknown. I don't love it, but that type of risk is manageable.

The part of contract work that I dislike is being forced to compromise quality. When I'm working on a fixed cost contract, it is in my best interest to deliver exactly what is specified, as quickly as possible. As long as my client is reasonably happy with the deliverable, I am going to get paid $20k regardless of whether it took two days, two weeks or two months to create. I don't get additional money for clean code. I don't get extra for having good test coverage.

When I complete a project more quickly than I had anticipated there is no problem. I can spend time verifying that the code is tight and that everything is working as expected. But if I am running behind schedule, it becomes more difficult to care about testing the code or fixing "little" bugs.

There may be a bug in the code where order totals aren't calculated correctly, but what are the odds that my client will notice the bug before he signs off on the project? If he does find the problem and I correct it, will he think to test for that same bug in every release?

This is the dilemma that makes contract work difficult for me. If I see a bug in my code, I'm going to fix it. If I'm writing a tricky or important calculation (like calculating totals), I'm going to write a test. I need to have confidence that my code is doing what I expect. I've never shipped any software that didn't have a list of known bugs but I have also never shipped any software in which I didn't have a high level of confidence that it was working correctly.

For me, doing the bare minimum isn't an option for two reasons:

  1. Quality is extremely important to me. I can't just hack something together that meets the contract requirements. When I write software, I want to deliver my personal best.
  2. Most of the time, the fast/crappy way of implementing something simply doesn't occur to me.

I understand a company's need to understand cost before approving custom softare. But if you want me to do contract work, pay me on an hourly basis. I'll give you a projected timeline for project completion.

With an hourly rate, you only pay me for the time I actually spend working. With an hourly rate I know that I won't lose money just because I insist on high-quality code. We'll both be happier in the long run.


So, you want to work for a startup?

I recently came across an interesting quote:

The first thing that one needs to know when joining a startup is to understand how they work... make sure you understand what you are getting into. Here are some things to consider

  • startups are not for the faint hearted
  • startups are not a "get rich quick" scheme
  • startups require sacrifices from everyone including you the candidate (pay/effort/etc)
  • if you put your heart & soul and are part of the right team there is good chance you will succeed
  • success is not guaranteed, it has to be achieved!
  • remember its a journey, so if you are thinking about jumping ship often - dont even bother!
  • startups are a small community and if you play dirty the word WILL get around

Taazza newsroom, January 6, 2009

Some time ago I made an important discovery about myself: I love startups. I thrive in these fast paced environments. To me, participating in the design of a new product and creating the first iterations of the software is like a fix to a junkie. Working with new, cutting-edge technologies is exciting to me. It is exhilarating to interact with other intelligent people when we are all passionately fixated on achieving our mutual goal. It's awesome!

All that said, working at a startup company is definitely not for everyone. Be prepared for a few ups and a whole lot of downs. Be prepared to bet against the odds. It's fun to dream about a huge IPO but if that's your sole focus...

I'm not going to deny that a large payout would be great. But in the meantime, I'm content to enjoy the adventure. You should checkout the full article.


High Morale Makes Creativity Cheap

Lesson Five: High Morale Makes Creativity Cheap

The Quarterly: It sounds like you spend a fair amount of time thinking about the morale of your teams.

Brad Bird: In my experience, the thing that has the most significant impact on a movie’s budget—but never shows up in a budget—is morale. [what’s true for a movie is true for a startup!] If you have low morale, for every $1 you spend, you get about 25 cents of value. If you have high morale, for every $1 you spend, you get about $3 of value. Companies should pay much more attention to morale.



Coworking seems like a great idea.

I hadn't heard of it before but I really like this idea of coworking:

For the last several months I have been working from home (which I love) but have frequently missed some of the niceties of an out-of-home office.

Tagged as: Comments Off