Scott Hanselman thinks signing your name with a bunch of certifications is gauche:
This is a companion discussion topic for the original blog entry at: http://www.codinghorror.com/blog/2006/05/fail-early-fail-often.html
This is a companion discussion topic for the original blog entry at: http://www.codinghorror.com/blog/2006/05/fail-early-fail-often.html
Having a cert means you have a capacity to hold lots of technical stuff in your head.
I think it often also means “I had money to spend on courses and didn’t realise I could learn more spending less money just by buying the software and teaching myself” or “my workplace had some leftover budget this year, so I sat through a few courses which I’ll never use.”
my workplace had some leftover budget this year, so I sat through a few courses which I’ll never use.
Someone being victim from a budget cut? 
well I am big failure, I have no cert, but I never really felt I needed one, except I could get paid more and I would probably get more chicks with some form of MCS.*. /sarcasm
But anyway, why not focus on “did you do the job?” and not so much on success/failure?
If I code 24/7 on a project and I accomplish my development goal, but the project is never used, I would of cause be sad. But if I did a good job, I would still be proud of what I did. Yes, you can’t live from bits and bytes, but money and success is not everything. Developers are becoming marketing minded, and in a lot of ways that is a good thing. Call me old fashioned, but I still think developers should focus more on DWords then BuzzWords…
Jeff… have you been into the sauce?— if I failed in spectacular new ways on each subsequent project, I wouldn’t have a job for long.
Normally, I love your blog… a billion times more than my own. Keep up the good work.
Famous quotations don’t teach much but they can remind you of something you’ve learned and are sometimes good to help point a discussion in a direction. One of my favorite quotes is:
Good judgment comes from experience, and experience comes from bad judgment. — Barry LePatner
Perhaps more in your theme, it could be modified to end, “…comes from LEARNING from bad judgement.” Just having bad judgement doesn’t help if you don’t study the failure and learn from it.
This reminds me of my first big mistake as a professional developer: I released an electronic trading application I wrote without thoroughly testing it. A few minutes before the close, we hit a bug, couldn’t cancel the orders and it cost us about $45k. My stomach hit the floor and I thought I would be fired on the spot. (I didn’t).
The experience got me obsessed with testing. I wrote test scripts for the application, adding a feature that allowed it to record and playback UI events. I learned how to use a test coverage tool to help me design test cases, and most importantly, I learned how to say “no” to the traders when they pressured my to release before I was ready.
The application turned out to be a big success and helped us make a lot of money (with the $45k loss little more than a rounding error). Years later I was not only able to see the value of the stressful lesson, but also to use it as a great story in interviews.
I only wish I’d made more mistakes that had such a positive effect on the way I work.
There’s a big difference between personal failure and project failure. And of course, success and failure can be very subjective.
A recent blog post declares VS 2005 a failure: http://nothing-more.blogspot.com/2006/04/visualstudio-oh-my.html. I disagree. So is it a failure or not?
Consider the scenario where developer is assigned to work on a section of functionality that will not have an impact on the overall success or failure of the overall project because it was over or under architected. Is that project a failure for that developer?
How about project managers who under-bid the amount of time it will take to complete a project? Will they report “1 colossal failure” on their resumes?
But mistakes aren’t failures. For example, in the application that I’m currently working on, we made a number of bad decisions (as in, “God I wish I could do this over”) involving requirements gathering, the database schema, and parts of the user interface.
But I’d still count the application as a success. Our users are able to use it to do stuff that they’d given up doing because it had gotten too difficult.
So, I’d ask what was your worst failure, and what was your worst mistake.
And I’ve also found certifications to be worthless when hiring. Very rarely have I had a person with a certificate be able to answer an interesting technical question. Worse, they often won’t even guess.
Don’t under estimate the power of bullshit on a resume. And Certs are just that. Fluff that impresses managers and gets your resume read. As for failure, its all about risk. I think in general if you (or an orginazation) take big risks you will fail more often. But, your successes will be more spectacular.
if I failed in spectacular new ways on each subsequent project, I wouldn’t have a job for long.
Statistically speaking, most IT projects are failures, though.
http://www.it-cortex.com/Stat_Failure_Rate.htm
But as Mike points out, we have to distinguish between mistakes and failures.
There’s a quite old adage on the subject: “Failures that don’t kill us make us stronger.”
There’s a response to that that’s about 10 seconds younger “Yes, but failures that do kill us make us dead”
cruel, but fair:
(tech certification) means you had to take a course to learn something you could have read in a book. — Steve Yegge
“If I code 24/7 on a project and I accomplish my development goal, but the project is never used, I would of cause be sad. But if I did a good job, I would still be proud of what I did.”
I’m sorry, but a project which is never used is a failure. Usually these kind of projects are failures even before they started. Developers start coding even before the user knows what he wants or needs, marketing tries guessing what the user needs without actually asking, or just tries to mimic what the shop on the other side of the street did… projects that cover 20% of the user’s needs and have to be hacked or circumvented for the remaining 80% of the task, because specs covered what the user should do and not what he actually was doing… but, hey… i get paid by how much time i spend on a project, not by it’s efficiency…
“I’m sorry, but a project which is never used is a failure.”
Read more carefully what you quoted:
“But if I did a good job, I would still be proud of what I did.”
Anyone ignoring their customer’s requirements is definitely NOT doing a good job. But, what if you wrote software that fulfills all of the customer’s needs, was on time and within budget, but then the customer says “I don’t need that anymore”. You did a good job, so the project is still a success. This scenario plays out ALL THE TIME where I work.