The Outdoor Development

I wasn't sure if I'd be able to publish an article this week. I'm taking some Designated Time Off for my anniversary with my beautiful wife. We're in North Georgia minutes from both North/South Carolina and close to Tennessee in the US.

I really love (TO LOOK) at the great outdoors. That's why I have a subscription to Discovery+ with all those well narrated Attenborough documentaries. BEING outdoors is a whole other matter. Although it's about 90+ degrees in Florida (where we're from), it's in the mid 70s here, so that's a plus. However, all the other things I dislike about being outside abound...mainly the bugs. As I'm writing this outside on a park bench, I'm surrounded by billions of small insects attempting to grab a rare, but easy snack from a species not normally seen in these parts...an indoor developer.

Dealing with the bugs, however, got me thinking that I'm fairly familiar with bugs of another type. I found some useful ways to think of what I'm doing this week from a developer's point of view.

Pair Coding

One of my favorite activities here, has been taking a walk in the early morning with Mojo, the coding dog. He's a great companion and it's like we're working together on the same project. My wife doesn't get up early, but me and Mojo are up when it's bright outside.

Each day, we've been embarking on a new pair coding (walking) adventure. It reminded me of how developers enjoy their work. First, we don't like to repeat ourselves since we are stout proponents of the DRY or Don't Repeat Yourself principle of programming. Therefore, we look for a new path (literally) to follow each day.

Along the way, having a pair buddy pushes me (It's more like a pull, which Mojo does on his leash). He causes me to explore places I wouldn't normally go and at the same time, I help him avoid pitfalls (literally. Here in the mountains, if you step too far, you can fall off a cliff). He's also good at catching bugs (also literally).

Reading the Docs

Another thing it reminded me of is how important it is to read the documentation. Sure, there's a ton of Don't Feed the Bear signs and great instructions about where everything is. But I'm talking about the hiking documentation.

While hiking, it's difficult to gauge distances. Since the road is on a mountain, it winds left and right with pretty tight turns, so it's hard to tell if the next area is just around the corner, or another 10 miles. We've been trying to make it to the larger visitor's center a bit up the hill. Being 'seasoned' developers, we just start coding (I mean walking) up a hill without any regard for the distance. There are lots of benches, lookouts and other places of interest, but having decades of experience screwing up (more if we're doing dog years), we didn't bother to look at a map. Maps are for newbies...right?

Reading that documentation could have told us how long from the current spot to the visitor's center. Today, I drove there to get a pass for my visiting daughter and discovered that we weren't that far from our ultimate destination, it was just around the corner we couldn't see.

Even worse, every hiking trail here has a sign that tells you how far it is to the end of the trail. We saw one that said it was .25 miles. Now, the coding dog and I routinely walk one to two miles each day, so we felt a quarter mile would be like programming a small utility function.

However, if we had taken the time to read the docs we would have noticed that particular trail had high difficulty level, so it was more like trying to code a large Github Action using Alpine Bash Scripting and the vi editor...quite a bit more challenging and hard definitely harder to get out of.

Resource Allocation

This is only our second time taking out the RV, so we've been learning so much about how it works, the setup and tear down procedure, cooking without setting off the fire alarms and starting a real fire outside in the fire pit. I joined the Boy Scouts for a total of one and a half months, so all I learned is to tie a single knot (albeit a fairly useful nautical knot). so, I feel like I've been catching up learning a new programming language.

I told my wife that we should look at any problems we encounter like a developer would. Testing, iterating and re-launching over and over to fine-tune and improve processes. I'm not sure she's buying it, but I have a lot of fun thinking of problems this way.

One thing that's specially giving us a hard time is the water tanks. Traveling with the kids and cooking in the van means a lot of cleanup and lots of water filling up our tanks. That means lots of trips to the dump station, but that involves tearing down the whole setup like we were leaving. So we've had to practice a bit of resource allocation and establish something like a performance budget while learning to conserve water. It's even teaching the kids to watch their water usage while brushing their teeth. Not a bad thing at all.

We are barely getting an internet signal, so we had to check the local web search engine (the network of other campers) and Stack Overflow the problem by asking them what they were doing. People suggested a portable tank so you can transfer the water to the dump station without having to reset the van.

Back to Civilization

I can't wait to get back to Civilization next week. I'm going to miss the cool weather and my pair coding sessions in the mountains with Mojo. I'm looking forward to the flatter distances and the fast internet. In the meantime keep iterating, watch out for those bugs and get yourself a great pair-coding buddy. Mojo is a great partner. Although I end up doing most of the coding, at least he gets me outside each day for some good walks and some well needed vitamin D. I'll talk to you next week.