The Old School Manifesto
Mon, 10/11/08 – 22:08 | 2 Comments

As we saw in the last essay, the 80:20 rule seemingly appears in many circumstances. When I was attending college and working as a programmer during the 80’s, there were some commonly accepted tenets that guided our software development processes and behaviors.

Read the full story »
Management

Methodology

Metrics

Quality

Requirements

Home » Management

Certifications, Who Needs Them?

Submitted by Bill Miller on Monday, 25 February 2008 No Comment

certficates 

What happened to the software industry?  I hate professional certifications.  It didn’t used to be this way.  Many employers are looking for the certificate du jour on your resume as a filter for an interview.  Having a certification means nothing.  I remember as a child it was a big thing if someone had their black belt in Karate.  It meant they were tough until they picked a fight with the real tough guy who knew nothing about Karate.  Everyone was awed.  “Did you know Johnny beat up Tommy who has black belt in Karate, and Johnny can’t even spell Karate?”

There is a huge difference between what you know and what you can do, and a certificate signifies neither.  It only means you met the requirements for being awarded a certificate.  I went to High School with friends who cheated their entire way through High School.  One was even able to receive a college diploma by cheating his way through.  He neither knew anything nor could he do anything related to that certificate.  However, that’s the extreme. 

In some cases, the certificate could have been well earned, but it still says nothing about what you can do.  The only way to demonstrate that you’re good at what you do is to have some accomplishments.  The emphasis on certificates for some is detracting them from being really proud for having done something.  You’ve probably worked with some of these people.  They’re constantly worrying about getting the next new certificate or learning some new technology to apparently build a resume.  They normally have a lot of paper to show for all their work but very little in the way of work accomplishments. 

On the other hand, there’s the engineer in the adjacent cube.  He never concerns himself with certificates.  He’s the most reliable person on the team.  You can count on him to fix the most difficult problems.  He’s got no time to worry about certificates as he’s too busy getting experience, solving real problems, and adding value to his employer.  When it comes to finding that next job, though, his cube partner has an advantage.  Is there no justice in this world?

As a manager of software engineers, I’ve witnessed these phenomena.  I recall one time not too long ago I was looking to hire some C++ programmers for a critical project.  After informing the recruiting associate of the job requirements, I began receiving resumes and interviewing candidates.  It was a disaster.  The resumes were littered with an alphabet soup of acronyms, technologies, and certificates.  They would have gotten a hit in any Monster search.  After interviewing a few of them, I called the recruiter and said, “I don’t care what language they programmed or what industry experience they have just send me someone who had some on the job accomplishments.”

When I look back at whom my best programmers were they had the following characteristics:

  1. They are all highly intelligent.
  2. They are self learners preferring to read a book than go to a training class.
  3. They are persistent; they do not give up on a solving a problem easily.
  4. They are accountable.  They don’t look to blame others for the problems in the product.  They take ownership of the mistakes they make.
  5. They are can do.  You’d never hear from these guys that a problem is technologically impossible to solve.  It isn’t in their volcabulary.
  6. They are responsible.  They take responsibility for the entire release not just the functionality that they deliver.  They never ask, “Why are you giving me that bug to solve? I didn’t write that code.”
  7. They are problem solvers.  There isn’t a problem that they believe that they cannot solve.
  8. They are creative.  They often suggest novel ways of solving ordinary problems.
  9. They are proactive.  They often suggest ways to improve the product. In fact, they often push the team to be better.
  10. They are cooperative.  If they are needed for testing, they test.  If they are needed for writing some documentation, they write it.  They pitch in wherever the need arises.
  11. They are superb in everything they do even with the things they don’t really want to do.  No matter what assignment they are given, they always deliver an excellent work product whether it was documentation, code, testing, or administrative.   This is rare to find - even for the really good people.
  12. They are supportive of process.  In fact, they often recommend ways to improve the process.  They view good process as a necessary manifestation of good teamwork.
  13. They are fast learners.  They quickly acquire the knowledge to solve problems in assignments where they are inexperienced with the technology.

If you have someone like this on your team, they are your most valuable employee.  While there are many people with these traits in the industry, they are difficult to find.  There is no certificate for these traits.  These traits are demonstrated by a collection of accomplishments to their good name.   These are the people you give difficult assignments to over more experienced members of the team even if they have no background in the assignment while others on the team do.  They are better problem solvers.  You can’t teach problem solving, but it does improve with experience, persistence, and knowledge.  The ability to solve problems is essentially the most critical skill of a programmer.  After all, that is what programming is all about: solving business problems. 

If hiring managers emphasized problem solving skills over easily learnable skills, they’d be recruiting more prized employees and building better teams.  When the programmers on my team would lament about using old technology, I would counter that the most important skill of a programmer is your ability to solve problems, and while it may be more difficult to get in the door, you will have a decisive advantage over the other employees once you are in the door if your problem solving skills are superior. 

I believe the skills gap in software that is so often talked about in the press as the reason for the liberal work visa program is a consequence of poor hiring practices that overly favors specific experiences over accomplishments, talent, and readily transferable skills.  While many hiring managers still make specific language experience a requirement for their programmer openings, I’ve worked with so many talented programmers over the years that could easily learn a new programming language in a week and be more productive than most with months of experience in the desired language.   Think about it, the algorithms for the most part are independent of the chosen implementation language. 

If you’re the type that likes having certificates, it’s fine, but don’t acquire the certificates at the expense of acquiring real world accomplishments that demonstrate your talents. If you’re a hiring manager, you can continue to make the certificate a requirement, but know that if you do, you are losing out on hiring the real gem employees as they are too concerned with contributing to be concerned about acquiring the interview token.   The organizations that I’ve worked in that emphasized accomplishements and talent over certificates were all higher performing teams.

Email This Post Email This Post Print This Post Print This Post
Vote This Post DownVote This Post Up (No Ratings Yet)
Loading ... Loading ...

Leave a comment!

Add your comment below, or trackback from your own site. You can also subscribe to these comments via RSS.

Be nice. Keep it clean. Stay on topic. No spam.

You can use these tags:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

This is a Gravatar-enabled weblog. To get your own globally-recognized-avatar, please register at Gravatar.