Inspection Detial!

It's been over a month since I finished my Digital Skills Bootcamp on DevOps run by Purple Beard Training Ltd. Here is my review of the course, what I learnt and what I intend to do with it.

Overview of the course:

I've been writing about the course since before I started. I've explained what a Digital Skills Bootcamp is, why it's run and how you can find one near you. I've given some advice about what to do to prepare for it, how to use it and how to revise from it. But now that my course is finished, I need to explain a little more about what the course is for and why I would do another one. First off, the course ran for 19 weeks between November and March with a couple of weeks' break for Christmas. It was run on Wednesday and Thursday nights between 1730-2000 over Microsoft Teams. The class was between 12-15 people with two teachers. Wednesday nights was mostly theory taught by one teacher, and Thursdays was a practical night run by the other teacher. From day one, we were advised that we would have to design, run and complete a project incorporating as much of the DevOps process as we had learnt. We learnt the following topics for DevOps: • DevOps introduction • Software Development Life Cycle (SDLC) • Linux and Terminal basics • Git and GitHub • Introduction to the Cloud • Testing in DevOps • Continuous Integration/Continuous Deployment (CI/CD) • Configuration Management • Containers • Continuous Monitoring • DevSecOps All the topics were approached from a no-knowledge basis, although a straw poll of people’s familiarity with each topic was taken before the class to gauge the level of expertise. The range of knowledge from the learners ranged from complete beginner (much like me) to people who had knowledge of certain topics and used them daily.

What I learnt on the course:

I learnt a lot about myself on this course. I learnt that I'm rubbish at making notes on the go, but that I understand a topic deeper when reviewing the topics in my own time. I also learnt that the Bootcamp format was an excellent way for me to learn, as it had the discipline I needed to not give up on a topic (I had to be there every week if I wanted the course to be covered by the government) and that the quick sessions of the three-thousand-mile view of a topic gave me enough of an understanding of the topic before I dug down deeper in my own time, guided by the slides from the teacher. I also learnt that working in a team on a project is easier than it sounds, although it does have many drawbacks too. For example, with software like teams and the Microsoft Office system, running a team from multiple remote locations is not too hard. You can all chat with one another and agree a time for a call. All the calls can be recorded, so you can come back to them at the end of the day or if you couldn't make it. The most obvious downside with working with a team remotely is that everyone has their own lives and work to fit this course around, so organising a separate time you can all meet to talk about your project outside of class is limited. Our team did struggle with this, but we did eventually manage to get some meetings organised and work on our project. Another major learning point for me was that DevOps (or most technical subjects) cannot be taught or learnt in roughly 100 hours. Sure, the basics can be talked about and you can be guided to further study, but even the core technologies of DevOps cannot be learnt in such a short time. This means it is incumbent on you to go away and develop your knowledge from the seed that the course has planted. With continuous learning and research, you can grow your knowledge into a strong tree of foundation knowledge, with the aim of watering it with additional learning.

What I'd change about the course:

Purple Beard have been running these courses for a relatively short time (a couple of years), so it's fair to say it's still a work in progress. That's not to say it was bad on a waste of time, rather a decent base from which to start and would benefit from some targeted feedback (which I have given the team). For example, on our intake, we were told about the project from day one. This was a change from a previous intake where the project wasn't announced towards the end and people panicked, so already a good improvement. The issue I had with this was that we weren't given much information and were separated into groups early where we all figuratively stood around shrugging our shoulders. It did allow us to think about the things we would include in our project as we learnt, but for the first couple of meetings, we didn't know enough to make a start. Secondly, it would have helped if we had a bit more guidance on the project itself. In our first meeting, we were shown a slide about the project which showed three different examples for the project. One was about setting up a blog and pushing it to the server, one was about two companies wishing to share data, and the third was about someone raising a support ticket and pushing the fix through the DevOps pipeline. My group decided to opt for the two companies trying to share data. We had grand idea of designing two systems in separate programming languages and creating some sample data to transfer, which all seemed quite daunting for people who were not developers but with very basic knowledge of programming. What we ended up creating was a very simple HTML page and pushing it from GitHub to the server, a much simpler prospect altogether. This wasn't necessarily the fault of the teachers; our group should have been more forward in asking questions. But a much simpler example at the beginning would have helped.

What I’d repeat:

The past few months have been one of great upheaval for my family: I’ve lost one job (where I was off sick) but picked up a new job, we’ve been ill, we’re planning a wedding and trying to learn a new skill. I’ve found that I work best when I have a dedicated time to work through. It was easier when I was off sick, as I had nothing better to do than learn, but as soon as I started my new job, my learning time dropped almost exclusively to the class nights and maybe a few hours over the weekend. I have tried to replicate this since the course has finished but find it all so easy to not do some training on one night for a rest, and then the next day I put it off again and so on. With a dedicated time to study, it’s much easier to justify the time and do it. I would happily do another Bootcamp (and I’m thinking about doing one with Purple Beard again) this time in Web Development, but not sure I can be as flexible with shifts at work or other family commitments. It’s still on the table, but at the moment, I am working through the Scrimba Front End Developer Career Path, which I’ve found is an excellent resource to learn WebDev from.

What I'm going to do next:

Now that I've completed the course and have my certificate, I have done some research and decided I want to go back to my first code love: Web Development. This may seem a strange move, considering that I've just done a DevOps course, but I've found that DevOps can also be part of the Web Development process when used in Full Stack Development. So, I am now working towards a qualification in front end development (relearning what I started over ten years ago) with a view to also learn back end in the future (utilising my newly found DevOps skills). I can't really call myself DevOps-DoDo, as DevOps is not the path I want to follow. I will be re-branding myself soon with a view to reflect the new field I wish to follow. I will, however, be keeping this blog open and will use it to chart my path to Full Stack Developer.