When starting in a new DevOps position, things always seem overwhelming.
You probably know that feeling that you get in the first few days when you receive the laptop and try to kill some time until it’s ok to go home.
You are sitting there idle, no one really has the time for you, but it would look bad if you leave before 18:00 on your first day of work.
Most advice out there will tell you to:
- Lean Jenkins
- Learn Git
- Learn Github
- Learn docker
- Learn Kubernetes
- Learn AWS
The problem is that there are too many topics, all very specific, and you have no idea which to pick first.
Then, in most companies, there is no real onboarding process for new employees. The team leader will usually dump those “JIRA tickets no one touched for ages” on you to get the load off of the other team members.
But there is one thing that you can do that doesn’t take up time and focus from others, and in my opinion, has the most impact on your new role.
Learn which language and framework the developers are using, and create your own mini-project.
This includes writing the code and deploying it using the same tools.
If the company is using Java with Spring Boot and deploying it using docker-compose - Great, think of a small web app that you can quickly create. Code it, build it (Maven, Gradle), then package and deploy it using docker-compose.
Are you joining a NodeJs shop? Again, write a small web app, build deploy, etc.
Why is this the first thing you should do?
- It will give you a good idea of how the process works.
- You will have a better understanding of how a process should be working. Sometimes, there is an existing CI/CD process that evolved over the years without people stopping to think why it is the way it is.
People tend to avoid asking questions and assume that what is currently working is optimal. There is always room for improvement.
- You will have a better understanding of the decisions that lead the system to be the way it is today. Maybe on your last project, you did things differently. Without getting to know the Whys, you may have a hard time adjusting.
- More empathy towards the developers - By going through the process that developers have to go through every day, you get to see their side of the story, and understand where they struggle.
- Better communication with your development team - Ever had to deal with developers who try to brush you off with meaningless buzzwords and the “I’m the developer” attitude? This time it’s not going to work. You know precisely how they are working.
If you are doing the hiring
Starting a mini-project is also a good onboarding process for new DevOps hires on your team:
- It’s a chance to assess the new engineer in a greenfield environment.
- It will gradually introduce the person to your stack.
- The person will have more confidence when talking with other teams.
- It will pay dividends later down the road.
- Face it, you don’t have a real onboarding process right now, so why not give it a chance?
“What if I’m a consultant/freelancer/contractor?”
Doing a mini project to lear the stack the company is using makes sense even if you’re an outside expert (like a DevOps or DevSecOps Consultant).
It helps you overcome the Imposter Syndrome, which is common when moving from one client to another.
Want a few ideas for a mini project you can start right away?
I know that the hardest part of doing such anexercise is coming up with project ideas.
So if you want a quick start, I wrote a few project ideas that you can pick from and start right away:
Latest XKCD Comic
Fetch the latest XKCD comic and display it on the page. Use the https://xkcd.com/info.0.json API.
- Your choice of programming language.
- A Web framework.
- API call to XKCD (on the backend)
- Run the application on an AWS EC2 Linux based instance.