The journey of a thousand miles begins with a single step

The above quote is how everything in our tech journey begins. We all got here with a single step, that slowly became multiple steps. Before we knew it, we were a thousand miles in.

When I first started my career, I was in helpdesk. Now, I’m a developer advocate. The way that happened was with thousands of steps.

It All Started with PowerShell

I started out in my development phase using PowerShell. I was very into the Microsoft space when I started out in tech. It was later on in my career when I started playing around with Linux.

When I started out in PowerShell, it definitely wasn’t as popular as it is now. In fact, PowerShell Core wasn’t even out yet, so you could only use it on Windows.

I pretty much used PowerShell for automating small tasks. Retrieving a list of virtual machines, iterating through a set of values in excel, things like that. I pretty much thought at that point it’s all I wanted to use code for. I just wanted stuff because I thought it was really fun. I didn’t think I’d ever see myself truly embarrassing development practices.

PowerShell Became Python

I got a job that was very AWS and Python heavy, so naturally, I moved out of PowerShell and started learning about Python. Python through me for a loop (pun intended) because it was very different. I mean, the thought of not using brackets and using white spaces confused the living bejesus out of me.

When I started using Python, it was very much from an automation and a cloud engineering perspective. I was using Python to create values in Hashicorp Vault, manage AWS resources, things like that.

However, it was pretty quick after that when I started working with APIs. I knew what APIs were and what they were used for, but I never actually built one.

I started creating a backend API that would be used to interact with certain AWS resources. For example, let’s say the Sales Engineers only needed to see EC2 instances. Because they don’t need to see all of the other resources, the API was to only interact with the EC2 SDK.

It was a pretty cool internal application and even though it doesn’t have much use outside of the organization I was in, it was still a really great and fun way to learn about building an actual application.

Back to Powershell

Woohoo, a complete 360! I was back to writing in PowerShell. Because it was a .NET shop, using PowerShell to automate was natural. However, I learned a ton of proper development practices from working with Python, so I started incorporating those into the PowerShell game.

At this time, I was also learning about C#. Since the application I was deploying and managing was written in C#, I wanted to learn a little bit about C# as well. I definitely wasn’t becoming an expert in any way, but I could read the code and understand what was happening.

HCL Time

HCL is typically known as the language that you write Terraform in. HCL is a fully functional based programming language, although many people don’t think of it like that.

I started using Terraform a ton to define my infrastructure as code, primary in:

• Azure
• AWS

This was really cool because I could use development practices for my software-defined infrastructure. Things like unit testing, source control, code reviews, etc.. It was definitely worth learning because now I can automate everything from creating my services to deploying my applications.

Multiple other languages

At this point, I was working solely as a technical trainer. Because of that, I had a unique opportunity to pretty much learn and create content on anything that I wanted. This turned into me learning:

• C#
• JavaScript

I was still writing in:

• Python
• PowerShell
• HCL

With that, I was up to roughly 5 languages. I wanted to start narrowing that down, so I went back to just writing in HCL, Python, and PowerShell.

Go

When I got the job as a Developer Advocate at Octopus Deploy, one of the first tasks I wanted to jump into was getting the Octopus Deploy Terraform provider up and running. There were portions of it that were created previously, but it wasn’t actively being worked on. Because of that, I took it as an opportunity to take on that challenge of getting the provider back up and active.

The thing about this is, Terraform providers are written in Golang (Go). I’ve never used Go before. Actually, no, scratch that. I think I tried looking at Go prior and it looked like some sort of hyroglifics “/shrug”.

Since I wanted to learn more about Go so I could work on the Terraform provider, I set out on a mission to find a good course. I ended up at Pluralsight watching Nigel Poulton’s course that’s called “Go Fundamentals”. This was the best decision I made to jump into Go. Nigel explains the concepts very well and he’s an awesome instructor in general.

After Nigel’s course, I was hooked. I started jumping into a few other courses and after that, I started creating functions myself and creating my own Go content.

Now I’m focused on the cloud development and quality code aspect of Go, AKA, how to interact with SDKs for the cloud (Azure and AWS) with a spin on how to not only write Go code but how to write quality Go code.

One of the bigger things I’ve been focused on as of late is testing with Go.

Go, as of right now and out of all of the other languages I’ve used, is my favorite. I love how lightweight it is and how easy it is to actually build the code, both from a “writing it” perspective and literally turning the code into a package. I also like how it takes certain “low level” concepts (like pointers) and allows you to implement them in from an automation and scripting perspective.

What’s Next?

What content and work will be next on this journey? It’s going to be how to write quality code with Go AND how to ship quality code. Let’s get started.