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.
A good leader doesn't tell the team what to do. They model the behavior that they want from the team, and learn how to encourage peop...
What People Actually Hear in a Performance Review Many thanks to Mary Poppendieck, who wrote about this topic in 2004 , and proposed a...
In a conversation with Patrick Welsh today, and his take on it was that a craftsman is someone who: Writes small methods. Uses excell...
I've been pulling together a kata based on converting Roman numerals. The idea is that after having people refactor this one to som...