Prepare to Be Lucky
By Jimmy Lindsey
May 7, 2026 | Categories: devops, learning, goalsLuck gets a lot of credit that preparation deserves. In fact, people often treat luck as something that just falls into your lap. Most of the time, you need to be prepared to take advantage of the right opportunity when it comes. I recently landed a job that felt tailor-made for me at Depot, and it was, because I had spent years making myself into the right candidate without knowing it. If I hadn't spent years preparing, then I would have wanted this job and had no shot at it.
Preparation
It has been my goal for some time to become a DevOps engineer. As such, I have spent quite a lot of time learning DevOps technologies, as well as working on projects that utilize them. It is not like in September of 2022 I decided I was going to do DevOps projects and then started working on them. Progress was much slower than that. I started off with a couple of courses on PowerShell, then moved on to Linux, Docker, Azure, Terraform and many other topics.
By mid 2024, I wasn't satisfied with courses anymore. The rate I was learning at was slowing down. Courses often feel safe and productive, but projects are where the real learning happens. This feeling is worth listening to, because it means it is time to become more project-based in your learning. Some classes have a project, and sometimes the teacher purposefully introduces some problems that you can fix, but even then it usually is not the most realistic. In the real world, there won't always be someone there to present you with a carefully crafted solution to your current problem. Instead, you will need to research, chat with someone (or an LLM), and most of all struggle to come up with a solution yourself. Take courses for new skills or knowledge that you think will be easier for you to pick up if they are presented to you in a structured manner. Once you are done, start doing projects with what you learned, no matter how small.
In mid 2024 I started working on my first open source project, openSUSE Cloud. While that project didn't get very far, it did result in me working with other people that had a skill set that I wanted. The project wasn't just about me, or what solution I thought was best. This is what you will see in the real world. I continued to do projects on my own, of course. The big deal was joining Internet-in-a-Box in April of 2025. That's a project I am still working on, and I have learned so much contributing. It is also a great way to network, as working with people in open source will give you a bigger reach than your own small projects.
This very website you are reading this blog post on is a project of mine as well. I built it myself in Django, created a multi-stage Dockerfile, deployed it onto AWS and I wrote about it. In many ways, this website was a culmination of all my hard work and learning up to that point. I did it specifically because so many of my projects had been deployed somewhere for a few days at most, but usually only for a few hours. The whole purpose of this project was to have something that would run indefinitely.
You may find my description overly detailed. My point here is that this preparation has taken years. For someone with similar goals to mine, you will likely have to take a similar path. You may find the tasks in front of you to be overwhelming, but if you take it one topic at a time in the beginning, you will get closer and closer to your goal. Often, the things you have to work hard for are the things that are the most worth doing.
Luck
Earlier this year, I happened to read some blog posts from the people at Depot. I will link to the first one I read here, but the gist is that they all were about Docker builds. As I read the blog posts, I realized how well-written they were. This made me curious enough to look into Depot itself, and found that it is a company that makes tools for software, DevOps and platform engineers to speed up the building and packaging of software. I took a look at their open positions, and they had a position open for a support engineer role that was focused on Docker knowledge. In particular, it called out being good at troubleshooting and experience with multi-stage Dockerfiles. When I applied, I wrote a message that pointed out that my website was running from a container that was built with a multi-stage Dockerfile, with the relevant links to both my website and my project.
To make a long story short, I got the job. I recently asked my boss, Jacob, if they actually looked into my projects before they interviewed me and he confirmed it. So a long journey that started back in the second half of 2022 with me learning how to use PowerShell has ended up with me here. I had to prepare to be lucky, because if I hadn't done projects with Docker and studied it, I wouldn't have been a good candidate for this job, even though I would've wanted it. I also wouldn't have had the troubleshooting experience I built through my personal projects.
Of course, I still haven't reached my goal yet, but there is a lot to like about this new job. The people I am helping are DevOps engineers, and so I get to understand what kind of problems they face and try to resolve them. Also, at a startup, there are pretty much no silos. Even though I haven't been hired as a software engineer, I have already committed some code to fix small problems I have found. There are a lot of opportunities in this new role, and if I pursue them, I will get closer to my goal than I could've at my last job.
Conclusion
The goal I started with back in 2022 is still in front of me, but I am closer than I have ever been. That is how preparation works. You have to keep building until the right door opens, and you are ready to walk through it. Along that journey, seek out new ways to challenge yourself, but don't let yourself feel overwhelmed. What matters is starting now with one thing you think you can do or learn, and using that to build up your skills. Keep in mind, you are not preparing for a specific job yet; you are preparing to recognize the right one when it shows up.