Even with the rationale you edited in, I don't really see a point.
DevOps is an intersection of Dev, Ops (and more, like Security and maybe Testing) in a cultural sense. But on a technological sense, you will always have people in a mixed team who are good at one of those but not the others, and that is fine.
For example: you might deploy something like Kubernetes or OpenShift; and then you will for sure have ops-sided people who are expert at running the low-level stuff, tuning your NAS, adapting your orchestration to a cloud provider of your choice, or to on-premise bare-metal servers and so on. You will not, usually, have all of your developers do the same; they may use those things provided by the others. The ops guys might never see a piece of application code at all; and you would still call it "DevOps".
What your devs will be able to do is manage the full lifecycle of their applications, from source code to production, using the tools provided by the ops guys. When one says that devs do jobs that ops used to do in the past, one means that the automation makes it so that the environments (dev, test, int, prod...) are mostly the same; that deploying to them is as automated as humanly possible (without requiring manual ops, and most importantly without requiring a handover of binaries etc. between devs and ops); that there is a complete, unbroken technological chain from source to prod; including things like virtual networks automatically springing into existence and so on. One does not mean that devs troubleshoot hardware or networking on a low layer.
The same goes for your ops guys. They will most certainly not try to change the application code proper after a few seminars on it, unless you are talking about really small companies with 3-person teams who need to do so out of sheer necessity.
Note that I am not saying that it is not possible to be one person who does both development and operations work. Is is an absolute gold mine to have such people available; and some companies foster that by, for example, rotating devs into low-level ops groups occasionally. But those guys are not your target audience. By the topics you listed in your question, you are targeting ops guys who have never in their life coded anything ("hello world").
If you actually want your ops guys to grow into coding instead of just clicking around in GUIs, modifying or creating config files and such, then here are some suggestions:
- If they are writing the occasional
bash script already, point out advances constructs to them (loops, functions, error handling, etc.).
- Try to get them interested in some dynamic language like
perl or ruby for a low-hanging fruit, one step above shell scripts.
- Introduce them to
go, which is really nice for standalone command line applications and especially automation tools. It should satisfy the need to learn something new which should go really well on anyone's resume, and will satisfy the naysayers regarding non-natively compiled languages.
... and so on. But don't try to sell them "Java" as a route into "DevOps".
