Confessions of a Software Developer

If there's an upside to being involuntarily unemployed twice within seven months, it's that it incites introspection: Am I the common denominator? Do I have some fundamental flaw that leads my employers to conclude that I'm not worth my salary? Might I simply be choosing employment that's poorly suited to my personality and abilities?

I've read a few things over the past several months that have resonated with me:

Alan Cooper, in his piece, "The Software Practitioner Triad," wrote:

Programming — constructing release code — isn't the same as engineering.... Production programming['s] primary goal is producing a shippable product, not solving its technical problems....On the other hand, technical problem solving demands experimentation, which is naturally repetitive and empirical....Clearly — for the sake of the schedule, the budget, and the customer — programmers should never be tasked with engineering duties, and engineers should never be directly responsible for programming release code.

Reading that was a lightbulb moment: Engineering — problem-solving — is what motivates and inspires me; I find writing production code tedious and repetitive. Cooper also nailed the reason I've always had difficulty accurately estimating how long my projects will take: Engineering is inherently unpredictable, especially when dealing with unfamiliar technology, and should be done before the schedule is set and production coding begins.

Craig Andera, pleased that one of his side projects had achieved "1.0" status, wrote:

This is really a milestone for me. Like many people in my line of work, I have a fairly short attention span - I tend to focus on something intently for a while, figure out about 80% of it, and then move on to the next thing. That's an asset when you're teaching a class or researching a new technology, but I've long been aware that "real" developers don't have the luxury of moving on once the interesting bits are finished.

Amen! If I could, I'd hire a ghost programmer to do the grunt work, so I could concentrate on the juicy bits. (Hmm, maybe that's a good case for offshoring?)

Finally, Gretchen Ledgard discussed the book Now, Discover Your Strengths:

The authors write:

"Most organizations are built on two flawed assumptions about people:

1. Each person can learn to be competent in almost anything.
2. Each person's greatest room for growth is in his or her areas of greatest weakness"

And likewise:

"These are the two assumptions that guide the world's best managers:

1. Each person's talents are enduring and unique.
2. Each person's greatest room for growth is in the areas of his or her greatest strengths."

Reading that, I wondered: What are my strengths, and how can I capitalize on them while managing my weaknesses? I bought the book this week and took the online assessment; my results are here.

Last week, I received two job offers. One of them was similar to what I've been doing for the past five years: Working from home, self-managed, developing ASP.NET applications from start to finish. I love the flexibility and independence of working from home, but it's a two-edged sword: It's too easy not to work when I don't feel like it. And I've learned that I often don't feel like it if I'm not doing something new and challenging.

The other, the one I accepted, is unlike any job I've had before. I'll have to get up every day and commute to an office, just like real adults do, and I'll have co-workers and a manager. But rather than writing production code, I'll be supporting other developers, debugging their code, solving the problems that have them stumped. It will be interesting to see if I've correctly identified my strengths. Stay tuned!

 26 Jun 04 1:58 AM · Comments (2) · Tags: Career