Another organization launched today offering DevOps certifications. We’ll skip the fact that DevOps is supposed to be about culture (something pretty hard to quantify, let alone certify) and focus on the “certification” part.
First, a story…
A few years ago ThoughtWorks (my employer) had a training division. We offered courses from one to five days on various software development topics. One of these courses was called “Introduction to Agile”. This was a two day course that was designed to take peopl with no exposure to Agile and teach them some of the basic concepts. People would learn about iterative development, user stories, and so forth. It was truly a good course for people with no exposure to be able to understand the lingo, if nothing else.
Around the same time, we opened a new inside sales office in Texas. The folks hired for this new position were very smart, but didn’t have much (if any) software development experience. Since they’d be talking to people interesting in project management and continuous delivery tools, we knew we had quite a bit of training to do. It was decided that a good first step would be to take them through the course.
As it turns out, one of our trainers was a Certified Scrum Trainer. He mentioned that the course actually qualified as a Certified Scrum Master course because it had all of the required elements. On a whim, it was decided that the people who took the course would also take the CSM exam at the end.
So, in 2014 all of our inside salespeople were Certified Scrum Masters. Only one had ever been on a software project in any capacity. Would you want them in that role in your company?
Most technical certifications are certifying the fact that a person attended the course, not that they actually know what they are doing.
Am I saying training is bad?
People are not born with a whole bunch of knowledge. They definitely don’t start out knowing about Continuous Delivery and / or DevOps. It’s completely reasonable to attend a training course for a couple days, if for no other reason than to learn the terminology.
There are several very good ways to expand your knowledge on technical subjects:
- Attend conference talks: This is my preferred method, so much so that I’ve become the ‘event person’ for ThoughtWorks Products. You’re able to get bite sized pieces of information from standard conference talks. These talks aren’t generally deep enough to go start implementing something you saw here for the first time, but might be enough to decide if you’d like to learn more.
- Attend conference workshops: A lot of conferences are starting to add workshop days before and after the main event. Instead of several hundred people listening to a prepared talk, this is a few dozen doing hands on work with a technology. This is a great way to get your hands dirty.
- Buy training: I have absolutely nothing against people making money providing training. We left the business mostly because it just didn’t fit the delivery model of our other services and got hard to manage. There are several really good training companies out there, depending on your needs.
What to watch out for.
Any short course with a version of the word “certification” should be looked at with a very critical eye. Much of the time these courses are sold by trying to convince you how great they are going to be for your career. “You’ll make $20,000 more per year if you have this hanging on your wall!”
It just isn’t true.
That’s not to say there’s no value in attending these courses! Many of these are very good training that you may not be able to get anywhere else. This is especially true if it’s a product course. If your goal is the knowledge and the (most likely) high price is worth it to you, go for it.