As you're building more and more automation scripts you're going to inevitably come across instances where you have to make a choice. Do I take the easy road or do I buckle down and learn something I'm not familiar with to ultimately create better code?

I saw a tweet recently that said "The difference between a junior and a senior developer is knowing which yaks to shave. This rings true in the scenario I'm about to share with you.

I've recently been working on a project that has puts me at odds with Microsoft's Team Foundation Server (TFS). Previous to the current job I'm on, I had never touched TFS before. It was a foreign concept and, frankly, still is, for the most part. To me, it's an unwieldy beast that kicks my ass on a daily basis but, I digress. Knowing my experience with this product is important so pay attention.

There are a couple ways I work with TFS; Team Explorer in Visual Studio, tf.exe and the TFS .NET API. Like most products, the GUI and the command line application (tf.exe) all use the API anyway.

Since tf.exe was easier to work with, I decided to start wrapping PowerShell functions around various tf.exe commands. For example, tf.exe /commit became Save-TfsPendingChange. This worked fine for the most part but I soon began to run into issues figuring out which switches to use and troubleshooting tf.exe itself. It soon turned into a not-so-good situation.

The reason I used tf.exe in the first place was because I thought it'd be easier than learning how to interact with the API directly. After all, Microsoft had given me this tool to abstract away the details I didn't need to know so why learn the API in the first place?

I soon realized that trying to take a shortcut ended up taking much longer than originally anticipated and left me with code that depended on tf.exe being available on the system. I was frustrated.

Why do I tell you this story? It's because through this process I learned a valuable lesson; to code close to the source. I'm defining the "source" as the place that actually makes the change. In this instance, the "source" was the API. This was the place that actually made the change. In the end, every tool that made changes in TFS all relied on the API anyway. These tools were simply abstractions to present the API in a different manner to the user.

By coding close to the source removes any dependencies. In this case, the dependency was tf.exe. I didn't have to rely on this tool being available for my code to work. Also, if this dependency was updated in some way down the road, my code would continue to work. I hate dependencies.

Also, it reduced the complexity. Even though I wasn't familiar with the API I am now. I decided to quit taking shortcuts and just learn it. In the end, it took me longer but I came away with a solid understanding of how the API worked and learned a ton along the way. My code now doesn't depend on two things; the API and tf.exe. It just depends on the API itself.

Coding for the API is a win-win although didn't seem so when I first started!

Buckle down. Don't scrape a web page if you can access an API. Don't depend on another application if you can take action yourself. It may seem better in their short term but somehow it always come back to bite you in the ass!

Join the Jar Tippers on Patreon

It takes a lot of time to write detailed blog posts like this one. In a single-income family, this blog is one way I depend on to keep the lights on. I'd be eternally grateful if you could become a Patreon patron today!

Become a Patron!