I will become very proficient at DevOps and Cloud. No doubt! So, I want to proudly look back and see the little wins I started with.
On January 1st, I officially began my Cloud and DevOps learning journey—from absolute scratch.
No prior DevOps background. No shortcuts. Just a deliberate decision to build real engineering skills the right way, starting with environment setup and tooling—the foundation many people underestimate but every serious engineer depends on.
This post documents my first technical win. Not because it was impressive, but because it revealed how I approach problems when I do not yet have the experience to rely on.
Day One: Building a Real Dev Environment From Scratch
My first major task was to set up a complete local development environment on Windows using Chocolatey through Windows PowerShell.
The objective was clear: automate the installation of the core tools required for Cloud and DevOps learning, rather than relying on manual installers.
The tools included:
- VirtualBox
- Vagrant
- Git
- Amazon Corretto 17 (JDK)
- Maven
- AWS CLI
- IntelliJ IDEA Community
- Visual Studio Code
- Sublime Text
This approach was intentional. I wanted early exposure to the command line, package managers, and reproducible setup—skills that matter in real engineering environments.
Caption:_ “Using Chocolatey in PowerShell to install core Cloud and DevOps tools from scratch.”_
The Wall: When Automation Fails
Almost immediately, I encountered my first real obstacle.
PowerShell consistently failed to install VirtualBox and Amazon Corretto 17. The commands executed, output scrolled, and then—failure.
Caption:_ “Installing VirtualBox using Chocolatey command on PowerShell failed.”_
At this point, I lacked the mental models to quickly diagnose low-level installation issues. Error messages referenced components I had never heard of. Being new to command-line installations, I could not immediately tell whether the issue was my syntax, Chocolatey, Windows, or the tools themselves.
I was stuck for nearly two days.
Rather than blindly retrying commands, I paused, stepped away, and focused on other learning tasks. That decision—stepping back instead of forcing progress—proved valuable.
The Breakthrough: Discovering the Missing Dependency
When I returned to the problem, I examined what VirtualBox and Corretto 17 had in common.
Both rely on native system dependencies.
That led me to the real issue: my system did not have Microsoft Visual C++ Redistributable installed.
After confirming this, I downloaded and installed the latest version directly from Microsoft’s official website.
Caption: “Microsoft Visual C++ Redistributable installed — the missing dependency behind earlier installation failures.”
Retesting the Installation (Holding My Breath)
With Visual C++ installed, I returned to PowerShell.
First, I reran the command to install VirtualBox.
This time, there were no errors.
No failures.
No warnings.
Just a clean, successful installation.
VirtualBox is critical to my learning path. It will power the virtual environments I use to learn Linux, networking, and infrastructure fundamentals—core skills for Cloud and DevOps engineering.
Encouraged, I immediately reran the installation for Amazon Corretto 17.
It installed successfully as well.
Caption: “Previously failed Chocolatey installations now completing successfully after resolving system dependencies.”
Why This Win Matters to Me
This experience was not about installing software.
It was about learning how systems fail—and how to approach failure when the answer is not obvious.
I did not have prior expertise. I did not instantly recognize the root cause. But I stayed with the problem, researched dependencies, validated assumptions, and fixed the underlying issue rather than applying random fixes.
That is the work.
This moment gave me confidence that I can grow into this field, because the skill that matters most—problem-solving under uncertainty—is something you develop by experience, not tutorials.
Why I’m Documenting This Publicly
I am documenting this journey intentionally and publicly for three reasons:
First, accountability. Progress compounds when it is visible.
Second, signaling. I want hiring managers to see how I think, not just what I know today.
Third, trajectory. Tools change. Fundamentals, mindset, and learning velocity endure.
This post is not about celebrating a setup task. It is about capturing the earliest evidence of engineering thinking in action.
What Comes Next
With my environment now stable, I am moving into:
- inux fundamentals using virtualized environments
- Infrastructure tooling and automation
- Cloud fundamentals with AWS
- DevOps workflows and systems thinking
I will continue documenting both progress and obstacles—because real growth happens between “it failed” and “it works.”
If you are a recruiter, hiring manager, or engineer who values deliberate learners and long-term growth, feel free to follow along.
This is only the beginning.
Top comments (0)