Wednesday, February 25, 2009

Seth's blog

Seth Godin doesn't talk at all about software development in his blog, so I was surprised it at #3 on Jurgen Appelo's list of top 100 blogs for dev managers. Presumably most of those hits are coming from marketers, not software managers.

Yet, his is one of the first blogs I read everyday, and much of what he says directly relates to having a software career based on excellence and demonstrating importance through daily effort. As he marks his 3,000th blog post, he comments:
The hard part, as you can guess, is the first 2,500 posts. After that, momentum really starts to build.
He started back in 2002, so that works out to aboue 415 posts a year. Yup, he's definitely a guy who believes in daily effort.

Here's a fairly recent post -- a typical example of why I read him. It's aimed at marketers, but highly relevant to anyone building their IT career.
As you consider marketing yourself for your next gig, consider the difference between process and content.... As the world changes ever faster, as industries shrink and others grow, process ability is priceless. Figure out which sort of process you're world-class at and get even better at it. Then, learn the domain...

In IT, it's easy to get obsessed about content. Our resumes overflow with acronyms and languages, versions 3.7 through 8.13. As we work longer, we might pick up some knowledge about the industry we're in, such as financial services, so that goes in the resume too. It's all stuff we "know".

Meanwhile, what's really valuable is the process. Capturing that in your resume or identifying which job applicants understand the process is the challenge and the goal. How do you identify what is important to your user? How do you effectively test your code?

Practices such as Agile help draw focus to the process, but sometimes that just turns into another list of domain knowledge. What's a product backlog? How many weeks do your sprints last? This is all content.

The more important questions lie underneath these details. What's the purpose of a product backlog? Name some other ways to do the same thing, and why are they better or worse? That's process.

I highly recommend Seth's blog for anyone interested in thinking about how to do their job excellently.

No comments:

Post a Comment