I can judge your efficacy as a software developer (or a software team) with a handful of questions:
- Do you release working software?
- ... on a regular schedule?
- ... and does it improve over time?
- ... and delight your customers?
These simple questions assume a lot of planning and delivery. You should have fewer bugs, as time goes on. You should deliver features your customer wants. The quality of the software should improve, as should its maintainability.
I've said nothing about what language you should use, what paradigm you should use, how to organize your team, what libraries or development environments you should use, the one true coding standard, or even your development process. I judge your project by its results.
Does it do what you say it does? Is it reliable? Will it continue to do that next month? Will it do more (or better or faster or with less memory)?
I think of this today after reading Tobias Mayer's The Scrum Compliance, in which he suggests that Certification for Its Own Sake is a problem of the Scrum Alliance. I also think of flipping pages in the original XP book eleven years ago and realizing that there was a life beyond change requests and testing plans and lobbying to get a feature into the next twice-a-year-inevitably-slipping release.
I don't care if you have or don't have a piece of paper and can regurgitate specific facts about the memory model of a specific programming language, because I'll likely have to look up the answer myself or at least write a ten-line test program to satisfy my curiousity. I don't care if you don't spring for your $50 annual membership in a professional society intended to get you past the gatekeepers of HR. I don't care if you know Kent Beck or Ken Schwaber personally (though if Ward Cunningham vouches for you personally, you get bonus points).
I care that you can demonstrate the abilities necessary to be part of a team devoted to delivering great software on a regular, predictable schedule. You can learn Moose (if you're willing) and you can adapt to our coding style (if you're not a primadonna) and you can even discover that pair programming improves our ability to write great software (if you can get over any preconceived notions of "watching someone else type").
That's why I wanted so badly for Perl 5 to get a reliable monthly release cadence and that's why I don't worry about the present or future of Parrot and Perl 6. I'm sure it's possible to write great software without regular releases and iterative development, but I'm certain that only healthy projects can sustain that schedule over a long term.
People who can work in those enviroments—people who help make such projects possible—impress me far more than people who can only brandish a piece of paper certifying that they sat in a chair for three days.
