From the Classroom to the Command Line: How Curiosity Led Me into DevOps

If someone had told me a few years ago that I would be learning Linux, writing Bash scripts, publishing projects on GitHub, and working toward a career in DevOps, I probably would have smiled and said, "That's not my path."

At the time, I was an Agricultural Science teacher.

Teaching wasn't just about helping students pass examinations. I wanted them to see agriculture differently—not simply as planting crops, but as a field where science, engineering, and technology could solve real-world problems.

As technology continued to transform modern farming, I became increasingly fascinated by innovations such as drones, sensors, and precision agriculture. I wanted my students to see those possibilities too.

One year, I encouraged my students to take on STEM-based projects. One of the projects that excited us the most was building a simple drone using popsicle sticks and small motors.

It looked promising.

But we quickly realized we were missing something much more important than materials.

We were missing the technical knowledge that makes these systems work.

That moment changed the way I thought about technology.

I realized that behind every smart farming solution—whether it's a drone monitoring crops, sensors detecting soil conditions, or systems identifying pests and diseases—is software.

That realization sparked a curiosity I couldn't ignore.

I reached out to professionals working in drone technology to better understand what we were missing, and I made a decision that would completely change the direction of my learning.

I enrolled in Harvard University's CS50 Introduction to Computer Science course.

Coming from a non-computer science background wasn't easy.

Programming concepts like variables, functions, loops, databases, SQL, Flask, HTML, and Python were completely new to me. There were moments when the learning curve felt overwhelming, and I questioned whether I belonged in this space.

But curiosity kept pushing me forward.

For my final CS50 project, I built a web application designed to help farmers access information about herbicides. It was my first experience building a complete application, and seeing it come together gave me confidence that I could learn technologies that once felt completely unfamiliar.

I even shared a demonstration of the application on my YouTube channel because I wanted to document what I was learning and encourage others who might be starting from a non-technical background.

Completing that project didn't satisfy my curiosity.

It expanded it.

I started asking different questions.

How are applications deployed?

How do they stay available?

How are servers monitored?

What keeps systems running reliably behind the scenes?

Those questions introduced me to cloud computing and, eventually, DevOps.

Today, my learning looks very different from where it began.

I'm building Linux automation projects, learning Bash scripting, working with Git and GitHub, and developing the skills required to automate operational tasks.

One of my recent projects was a Bash-based Linux Server Audit Tool that collects key system metrics, evaluates disk health against configurable thresholds, generates timestamped health reports, and provides an at-a-glance view of a system's health.

While building it, I realized something important.

Writing a script is only part of the job.

Making it usable is just as important.

Rather than navigating to the project directory every time I wanted to execute the script, I placed it in a custom bin directory, exported it to my PATH, and updated my .bashrc configuration so it could be executed globally from anywhere in the terminal using a single command.

It was a small design decision, but it changed the way I think about building tools.

Automation isn't simply about making something work.

It's about making it practical, reusable, and efficient for everyday use.

Throughout this journey, one lesson has stayed with me.

Watching my students become excited about building solutions was incredibly rewarding, but it also challenged me personally. I realized I couldn't continue encouraging innovation in the classroom without being willing to learn the technologies behind that innovation myself.

That decision to remain a learner changed my career.

Today, I'm still building.

I'm still learning.

I haven't built every CI/CD pipeline I hope to build.

I haven't deployed every cloud architecture I aspire to design.

But every Linux command I learn, every Bash script I write, and every project I publish moves me one step closer to the engineer I'm becoming.

Looking back, it's amazing to think that what started as a classroom STEM project eventually led me into programming, cloud computing, Linux, and DevOps.

And perhaps that's the biggest lesson I've learned.

Sometimes the most meaningful career journeys don't begin with a plan.

They begin with curiosity.

Mine certainly did.