When it comes to coding, names and proper terminology are critical.
When it comes to the names of courses, however, it’s a different kettle of fish.
A quick detour
That phrase, "kettle of fish", inspired a short dive down the internet rabbit hole. It means a muddle. Where does it come from?
Word experts, known as etymologists, think it refers to what fish remains look like in a metal container, or fish kettle. A mess of heads, bones, and innards. That’s an icky (my very technical term) image.
A quick thanks
Many of you know our courses. You know the prerequisites, and who the course is designed for. And if you don’t know, you check or you ask. Thank you for booking the right course. It makes life better for us, and for all the delegates.
Unfortunately, that’s not always true.
A recent problem
Recently we responded (successfully) to an RFQ for training for a government department.
The RFQ used only eleven words to describe the objectives and technical requirements of the training. Nine of the words came from this list: "programming, language, beginner, fundamental, intermediate, advance". The other two words were the names of programming languages.
Maybe you don’t see the problem. But it was a problem for me. I wanted to quote on the right training for the delegates.
What’s easy for you?
What do we mean by beginner or intermediate or advanced? We understand the meaning of the words. But that’s not enough. Which topic belongs in which category? There is no standard.
Here’s an example. And it’s one I deal with often.
Meet Person A. A has no programming experience, even if he is a PC support guru. Meet Person B. B has been programming for years, but has never used Python. Both A and B want to learn Python.
There is a huge difference between what to teach Person A versus Person B. There is a difference in both the volume and depth of information you can cover. And they will have very different views on what they think is an advanced topic.
This is why my first question is always about the background of the delegate.
A name is not enough
We want a course name to be relevant, easy to understand, and easy to market. Like "Java Programming course". It tells you that it has to do with the Java programming language. But that’s only a starting point. It’s not enough.
Two different vendors can (and do) give the same name to very different courses.
Two different vendors can (and do) give different names to courses that are comparable.
Here’s an example. We had a course called "Java Servlets and JSP Programming". That course covered the same topics as an Oracle course. At the time, the Oracle course was called "Web Component Development". See the problem?
The solution
The solution is not for every vendor to give the same course. That might be what the SETAs believe, but it doesn’t work. Different people need different things. Remember Person A and Person B.
The solution is to read the course outline. Who is it for? What are the prerequisites? That’s very important. What does it cover? And if you are not sure? Ask!
Who is responsible for this? I don’t think it is the job of HR or Procurement. I don’t expect Procurement to know, for example, that Java and JavaScript are different languages. Or that web services are not the same as web applications. It’s the job of the person who wants the training, or the manager who wants the person trained.
I could go on – I have 25+ years of examples. But I wanted to give you some insight into how to get the right training. I’d love to hear your views.