The Eric Wroolie Blog

Overpass Experiences

Mobile Developer

by Leave a Comment

The past few weeks have been real bliss.  I’m really enjoying my new contract.

One of my goals in finding a contract this time was to stay out of London.  I’ve had enough of the London commute with its delayed trains and crowded tubes.  So, in my new job I commute three days a week (working from home two days) on my motorbike.  I’m working in two different locations about an hour away—but on country roads.  Each morning, I pack up my laptop, strap it to my back, and ride to one of the client offices.

My work has been all Silverlight so far.  I love getting stuck in a new language.  I’m having flashes of insight as to how to do cool things while I’m out running or taking a shower.  It’s a novelty and heavy on the brain. 

I still wake up early, but my morning time is spent with meditation and running (and surfing around reading up on technology). 

Life is going well.

A change in direction

by 5 Comments

Well, after 16 months of trying to get Overpass up and running as an outsourcing company, I’m going back to contracting.

It’s been fun.  I’ve met a lot of great developers, been to China a few times to meet with software companies, and have worked on projects for small companies here and there.  But my skills as a salesman are terrible—and I hate cold-calling more than anything.  So, it’s time to change direction and get back to doing what I do well.

Even while trying to run my own software business, I’ve continued to code—learning technologies like Silverlight and NHibernate.  The nice thing about taking time off from contracting is that you get to build the skills you want to have, instead of the skills people will hire you for.  I’m my own DIY project and I can never stop learning the new skills.

Getting back to contracting is a big relief to me.  Selling myself (as a developer) has never been difficult, but selling the skills of other developers is tough.

On Monday I start a new contract in Basingstoke.  I’m very excited about it.  My main goal while looking for a contract was to stay out of London.  London’s a great place but I want to get familiar with more of England.  If I can stay away from the crowded trains and tubes, all the better.  I’m starting a four-month contract with a company that looks like it will be a lot of fun.  It also gives me the chance to work from home a few days a week.

It’s a good solid coding job—no offshoring at all.  Also, no mentoring, no team leading, and no budgeting.  It’s going to be great.

Overpass will continue to be a company, but it will be a company of one.

Is this a failure?  Um. . . not yet.

I’m thirty-eight—I probably haven’t even reached this life’s half-way point.  I’m looking forward to the future and am very optimistic about it.  Seven years ago, I was a permanent employee for a tiny company in Reading.  Thirteen years ago, I was a substitute teacher in Missouri and became a qualified to teach high school.  Twenty years ago, I was a soldier learning to speak Chinese.  Who knows what the future will bring?

The lone developer is dangerous.

by Leave a Comment

The lone software developer is the reason for most bad software and most spaghetti code.  A lone developer will sit down and code before making a plan.  Since there is nothing to explain to anyone else, there is absolutely no reason to make a plan or to write any documentation.  There is no reason to comment code.

Any software developer who has worked in a development team knows just how the team dynamic changes compared to an individual coder.  In a team, all your code must be justifiable.  Any areas of ambiguity, inefficiency, or prone to error will be caught by other developers.  Any code comments are written with other developers in mind (instead of simply “Notes to Self”).

A good software team needs a leader.  Software development is very personal work.  A developer sits down and wrestles with code from morning until night.  Even when in a team, he is often alone with functionality or bugs and must do what is necessary to complete them.   Any criticism of this work at the end of the day is a recipe for disaster.  A team leader, with a position of authority (but preferably with a good dollop of tact) needs to be able to step in and clean up the areas ambiguity at the earliest moment (daily, preferably).

I’ve worked in environments where all greenfield projects are given to a Grad student to cut their teeth on before working on the big applications.  Frequently, these small project become critical systems.  When things go wrong, the code is given to more senior developers to fix.  So, senior developers make patch work fixes on systems which began on a shaky foundation already.

But the truth is, not every project is big enough for an entire team.  In those cases, peer review becomes even more important.