Skip to main content

The Beginning

Detroit. A city filled with good restaurants, violent crime, and felonious politicians. The city I grew up in and that I still live near.

This is not a blog about Detroit.

It's a blog about something far, far more important. Me.

More specifically, it's about my journey from employee to independent. It's about returning to my roots as an ΓΌber-nerd software developer. It's also about Java's place in the world, and the independent consulting market in Detroit and Ann Arbor. I don't think I'll run out of topics any time soon.

I resigned my job as Program Manager in a struggling software company last week. There were a lot of reasons behind that, but the most important one was that I couldn't stand my job.

I didn't hate the people. I didn't hate my boss. I hated the actual work I was doing from day to day.

I'm getting ahead of myself, though. Before I tell you where I'm going to, let me tell you a little bit about where I'm coming from.


The Salad Days
Very early in my career, I worked as a contract software developer. I was directly employed by a couple of different shops until I met a fellow developer at a software company in Ann Arbor who also yearned to go into business for himself. Starting in 1994 we set up shop under the inspired name of "Damon, Przekop & Associates, LLC".

Those were heady days. Anyone with the ability to register a domain name could put up a website and bill themselves as a solution provider. A few really sharp people did so, as did a large number of clueless ones. It was a time when work just fell into our laps, and customers were grateful when we managed to deliver a working system, regardless of the quality.

We took whatever came our way. Need a client-server database app? "Sure, we can do that. Erik knows Visual Basic and Dave can handle the SQL work." Need some realtime work done? 'We know C++, and we can learn realtime in a hurry. " Want to piss away a couple of million on an voice-recognition-based CRM that will never see the light of day? "Java is the platform you want! (I guess we had better learn how to code in it.)"

Companies got wise after the bubble burst in 2001. They wanted their contractors to have some idea about how to ensure software quality. They wanted us to write systems that actually did what they needed. The approach of ignoring the customer's needs in favor of working with the flavor-of-the-month technology was no longer acceptable.

Our skillsets simply weren't up to that challenge. We both had a really good grasp of the basics of writing code, and we could do it in 10 different programming languages. The problem was that neither of us had true expertise on a specific development or delivery platform. We hadn't specialized, and we didn't know jack about QA, requirements or agile development.

A couple of companies came to the rescue. Dave was hired by a software company in Monroe, and I moved to a data company in Southfield. Both of us were tired of the grind and were ecstatic that someone actually recruited us away from what we perceived as a failed way of doing business.

I became an employee again, and learned quite a lot in two years as a technical lead. I specialized in Java development, with a focus on the process of software development. I learned how to get a team to deliver on time, how to gather requirements, and (after having my head handed to me a couple of times) how to see testing as my friend instead of as a pointless waste of time.

Then, something very bad happened.


Drawn to the Dark Side
That's right, I did such a good job as a tech lead/architect that my bosses foolishly thought I would make a great manager. It turned out that they were at least partially right - I did a pretty good job of managing software & support people, and I turned into a process-Nazi in a big hurry, which was just what the organization needed. I was rewarded financially and became the go-to guy for evaluating the capabilities of smaller companies we might want to buy. It was challenging, and usually fun.

Things went downhill after a couple of years though. My success was rewarded by giving me a job doing pure infrastructure management because that's where they needed the most help. For those who do that job well, hats off to you. I was mediocre at it at best, but I stuck it out for most of a year.

When the time came for cutbacks, my name was one of those that came up. I found myself on the street (with a severance package that took some of the sting away), wondering what to do next. On pure inertia, I put my name out there as an "IT Manager", which brings me back to my current job.

Jokes aside, I learned quite a bit as a manager that I wouldn't have otherwise understood. You simply can't get this stuff from books. How seemingly non-technical" people can add a lot more value than some of the rocket scientists. Why it's important to pay attention to office politics if you want to get anything done. How to plan for success, but still guard against failure. How to build and balance a team.

I also learned how much I hated doing it.

I really have nothing against management as a profession. Quite the opposite. I will now appreciate a good manager much more than I did before, and the management skills that I gained should serve me well in a technical job.

I did find that most management jobs (particularly infrastructure) require a very thick skin. Mine may not be quite thick enough, but I think the real problem for me is that it isn't what I "should" be doing. I just don't have any passion for it.


The Lightbulb Goes Off
I've been kicking this idea around for a year. While doing infrastructure work, while hunting for another job, and a lot while handling my latest job, I asked myself, "Why not go back to consulting?"

What held me back was the perception that I had failed at it before. I just didn't have enough customers, or enough expertise... or something. So I took a long look at what I did back in the 90's, and what it would take to make it work now. I came up with some answers.

That brings me back to what this blog is really all about: How to build and sustain a consulting practice based on my own expertise. How to build that expertise, find the right projects and clients, and sustain a small business for the long haul. My initial thoughts on what I did wrong then, and what I will do right going forward, will be the subject of another post.

If anyone who reads this is in the same boat, I would really like to hear your thoughts and opinions. If anyone has built a one-man (or one-woman) business out of writing code and/or architecting software systems, I'd really like to hear your thoughts.

I don't expect much feedback right away (though I'm prepared to be pleasantly surprised - I didn't come across anything else that really focused on this topic). I will add some useful links and observations from my own experience in future posts. I will also post snippets from projects I have worked on over the years, the steps I took to get things on track, and mistakes made that I learned from.

I look forward to hearing from you.
Post a Comment

Popular posts from this blog

Agile Performance Management: Why Performance Reviews Suck

Many thanks to Mary Poppendieck, who wrote about this topic in 2004, and proposed a comprehensive solution.  She is the inspiration for much of my thinking on this subject.  She is also a better writer than I am a cartoonist.


Performance reviews suck.  I don't know of anyone who goes into their appraisal without some trepidation.  Your boss is guaranteed spring some surprise criticism on you that is ill-informed or misses the point as you see it.  It's a real challenge not to get defensive about that.

The only thing that makes your own performance review suck less is having to give them.  As a manager, I have dished out quite a few, and some of them went pretty badly.  (To the people at my first management job: Thanks for helping me learn how to get better at them.  Your sacrifice was not in vain.)  Since then, receiving one isn't nearly as gut-wrenching, if only because I try to make it easier for the guy on the other side of the desk.  I've been there, and I know how …

Do. Not. Optimize.

You've probably heard this quote before:
Premature optimization is the root of all evil.
 - Tony Hoare
Speculative optimization is always wasted time.  In the absence of an actual performance problem, you're just burning time that could be better spent on refactoring your code to make it clearer.  This is exacerbated because performance-optimized code is usually harder to read than code which hasn't received such treatment.

Here is what you're doing when you optimize:
Adding code that now must be maintained.Obfuscating the existing code.Spending time writing code that doesn't add value. But what's that you say?  You have the experience and know-how to decide when optimization is needed?  Maybe, but probably not.   The people at Sun and Oracle may or may not be smarter than  you or me, but they certainly know more about optimizing Java bytecode than we do.

For example, some people think that having a large number of classes is slower than the alternative.  This …

Showing Off: How to Do a User Demo

Rather than repeating what has been said elsewhere, here is a nice short post on agile-for-all that covers the basics.

Here are a few things for my own future reference and teams that I'm working with...

Try to keep each demo to 5 minutes or less.   If it's longer than that, it's possible that you should be demoing more than one story.  More likely, you're just being too wordy.

TALK LOUDLY.   No, louder than that.  Louder.  Do you feel like you're yelling?  OK, that's about right.  You need to put your voice in public-address mode for 5 minutes.

Focus on why your audience should care about the story  This is particularly important for back-end work.  For example: Your story generates a feed of XML that will be consumed by another application. Show the output, and point to a couple of salient features in it.  Then be done.

The important part of the above is "show the output."  Showing the end users how to interact with your service is a separate sit-d…