Q: How Do You Walk From Portland, OR to Portland, ME?

A: One step at a time.

One of the major challenges I had (and still have, if we’re being honest) is looking at a project I want to do and actually delivering it as a solo dev. As time has gone on, I’ve learned that’s not exactly a problem exclusive to solo devs. One of the things that I have really appreciate at Pillar/Industry X.0 is how we approach this problem…and some of it really translates well to hobby code and side projects.

There are two key points I want to harp on:

  • Know where you’re going (what your desired end result is)
  • Do only the next thing (focus on what makes sense at the time)
Know Where You’re Going

My personal problem with a lot of side projects is I get an idea, and I start writing code for it. I don’t think about what the end result is going to be, usually telling myself “Don’t get too far ahead of yourself, just flesh it out a bit and it will become clear as you go along.” While I think this is a pretty decent way to write a novel, I’ve come to realize it’s a terrible way to write software.

There is a not-so-subtle difference between planning too much and planning too little. There’s no real benefit in planning out every single thing in advance, from the size and color of your standard buttons to how to promote your new app. But the general idea–web app or mobile? Is this going to live in Azure or AWS or Heroku or what? Am I using GitHub or BitBucket? Should I be continuously deploying this?–helps guide the architecture, the tech stack, and helps define the tasks.

Writing the code is important (sort of the point), and is broken up in it’s own way. But when does it make sense to setup a build pipeline? The repository? Do I need a production environment? When can I actually see changes when I deploy them, anyway? By keeping these questions in mind, by seeing a bigger picture than just features in the code, it helps guide the overall workflow.

Do Only the Next Thing

Having those tasks ranked and in rough chronological order helps you stay focused. Now you can say, “Self, we are going to test drive this feature here. And when it’s done? We’ll setup a build pipeline so it’ll merge into master on it’s own.” Once that pipeline is working, “Self, now we’ll add this other feature here, because when it’s done we can add it to a UI project!”

By modularizing the tasks, you’ll avoid the trap I always seemed to fall into–“I have a web app with no logic behind it and deploying it is a nightmare” or “This code library I spent a month on is useless till I get it plugged into something and I am just too tired to figure out what to do now.” Being able to focus on checking things off a list is satisfying and keeps things moving, especially when you’re navigating a full time day job.

You know you need to cross the country to get from one Portland to the other, but if you focus on that you’ll never make it. You need to focus on getting to the next stop, rather than the whole trip.

The Great Pipeline Post Project

I had this great idea to blog about setting up a CI/CD pipeline, both for much-needed practice and to relay some lessons learned. Spoiler alert: this is a much bigger deal than it seems at first glance. I sat down to get started and quickly got overwhelmed by the sheer volume of things to work through, especially as they occurred to me randomly, while I was sitting in front of Visual Studio.

That’s where this post came from. What if, instead of just breaking down how to setup a pipeline and all the steps under that umbrella, I started with how I planned this mini project? If my target audience would benefit from seeing all the pieces of CI/CD tied together it’s likely they’d benefit from seeing the pre-work too.

Over the next few posts we’ll start by exploring the planning that goes into standing up a new project and move on into the actual work needed. My goal, the whole time, will be to keep it on track and demonstrate how the joint efforts of knowing the plan and doing on step at a time keep things moving at a steady pace.

Configuration is the Real Magic

I talk about writing software being like magic. It’s how I view the craft in a lot of ways–using arcane words and phrases combined with strange tools to conjure amazing things out of a series of 1’s and 0’s on a circuit board. But when I describe my ultimate career goal as “being a wizard” I mean something, or someone, very specific.

I’m not talking David Copperfield or Penn and Teller. They are very skilled magicians, not wizards. That sort of magic is based on memorizing an illusion, of doing a thing in a certain way because of the reaction you know you’ll elicit. One does a very specific thing, or specific set of things, in a well organized way, over and over and while it gets more polished with practice, it will always be the same.

The words “programming is magic” conjure up Gandalf for me, from the Lord of the Rings universe. For the majority of those adventures, it wasn’t actually magic that made Gandalf the go-to guy–it was never “Gandalf has a spell for that.” What made Gandalf the truly formidable foe and an invaluable ally was the fact he knew things. He understood the old lore, the behavior of people and animals, how the elements of the world fit together and how they could either help or hinder a particular goal.

Gandalf knew the configuration of Middle Earth. Maybe not the *exact* configuration for every situation, but he knew what was missing, or what was the blocker. His magic was always a tool to divine knowledge or to force something into place, to adjust the configuration of a situation. Never magic for the sake of magic, happening in isolation.

“Gandalf knew the configuration of Middle Earth.”

Just like the veteran programmer on the team who always seems able to spot the problem

Continue reading “Configuration is the Real Magic”

Azure Webjobs, Application Insights, and You: A Vaguely Comprehensive Guide

When I was learning to code, it wasn’t hard to find out what was going on in my applications. Typically, especially in classes, I was sending output to a console–super easy, instant feedback. A few times I didn’t have a console to watch, I was writing things to a text file I could open immediately. Also easy. As things went on, and they had us actually playing with webapps and javascript and HTML, the feedback was again instant. I would know immediately if my program was behaving.

Then I get a few weeks into my internship, and there’s this new idea: a webjob. Essentially, a console app that runs on the cloud for background tasks. They’re awesome…until they start doing weird things while deployed. Azure gives you a couple hundred lines of debug console for free, but that’s just not a sustainable solution. This was the point my boss said some vague words about “App Insights” and pointed at an example the other developer had worked out a while back (modified from a guide neither of us were able to locate).

It took me quite a while to figure out how to even configure Application Insights in the webjob, and even longer to really zero in on how to use it intelligently. So I wanted to combine some of that hard-earned knowledge in a very long walk thru. We put together a toy app inside the webjob template, and configure it to run and send telemetry to an Application Insights resource.

The final code from this project is in a repo you’re more than welcome to.

Continue reading “Azure Webjobs, Application Insights, and You: A Vaguely Comprehensive Guide”

M*A*S*H and Single Responsibility

If you haven’t heard of the TV show M*A*S*H, it’s based on an equally excellent movie by the same name. It has exactly nothing to do with coding, software development, business, or anything else you might think is germane to this blog. Except that I watch a lot of it (may have even gotten a Hulu subscription JUST to take advantage of their recent acquisition of the show). Like most art you consume a boatload of it will eventually worm its way into the rest of your life.

Most recently, I had to use a Charles Winchester quote to remind myself of the Single Responsibility Principle.

“I do one thing at a time. I do it very well. And then I move on.”

— Major Charles Emerson Winchester, III

You see where this is going, right?

Continue reading “M*A*S*H and Single Responsibility”

Blog at WordPress.com.

Up ↑