Week 7/8 - The Programmer's Sandbox

This week felt much quieter with the absence of some previous team members transferring to other agile teams for the new increment. There was not too much to attend beyond daily standups for my role, and all I was tasked with was to implement a Unix file handler. Despite several setbacks already, I was also occupied with a weighty exam for my summer databases class. Would I ever finish what I started? Not to mention I wasn't even the most sure about how I was going to handle a task like this and felt the weight of my naivety on my conscience. Was I out of my depth? Obviously, said my anxiety. As you should be, replied my confidence.

Last week I talked about getting out of my own way. What I felt now was this all familiar tug-o'-war for my motivation as learning something new has always threatened my ego for risk of failing. It's an irrational fear that I don't believe I'm the only one who faces: there's vulnerability in admitting our lack of understanding, and it can be especially complicated by our ideas of what appropriate understanding should look like. Much of these past few weeks was spent reflecting on my purpose as a student and finding the courage to press onward.

He had a point. Though a common meme across several fields of engineering is merely the celebration of forcing a project to work no matter how hasty and hideous the means, realizing the outcome of a project and achieving a desired result is often the first stage in the art of (software) engineering. I'm not used to what felt to me like the bare minimum from a systematic point of view, and it can be arduous convincing the overachieving, detail-oriented self that this was acceptable for the task at hand.

But... it worked.

And that was the point of my project now, as the first step was just getting it to work. The buff and polish and "doing it the right way" could come later, just get it to work. What did that look like?

The Art of Logic

The first part of Oxford Dictionary's definition of art is "the expression or application of human creative skill and imagination." With this broader stroke, I can imagine art having a grander meaning beyond just implements of culture. This implies art as skill. Art is someone asking the right questions, then exploring the depths, and expanding their understanding.

Dad came into my room to talk about his latest project: he is installing an electrical conduit connected to the house that powers a pole barn he is building in the backyard. I merely tell him that I can't wait to pay someone to service my pole barn needs when I eventually own one.

Dad has been an engineer for longer than I've been alive. He started as an engineer with Arcadis before working in water and sewerage with both Henry County and Peachtree City in Georgia, and now Hardin County in Kentucky. He is that classic fixer-upper, do-it-yourselfer type that enjoys finding a project to work on around the house. No matter the task, he just always seems to know how to do it. Perhaps having years of experience has something to do with it. But I think what he enjoys doing is being able to put his art into action not just for work, but for personal use as well.

It's kind of inspiring, and served as a reminder of one reason I had for pursuing a computer science degree: I just wanted to play on my computer some more. I want to create, hack, design, solve, and a whole lot more with the tools that I have. I wanted to perfect an art of logic, and then creatively wield it.

I couldn't be afraid of not having experience, anymore. We were all without it before we immersed ourselves, and we always risk putting ourselves out there learning something new.

Thanks, Dad.

Git Bash

Git as an entity is a set of command line utility programs that execute in a Unix command environment. While Linux and macOS come with built in Unix command terminals, Windows is left without this style of command line. Git Bash bridges this gap, providing Windows users a terminal to work in Unix if desired, and even recommended. There are plenty of mini courses online that teach basic commands to using this terminal, as well as plenty of pages for troubleshooting purposes. Git is also an excellent choice because it integrates well with my VS Code IDE and, of course, offers complete Git Hub functionality. There's nothing I love more than having all of my work and tools collected together in a single place. I had plenty of time to become accustomed to the environment, and now the "scary black box" isn't so scary anymore.

Glob

This one was one of the neater packages to me as it definitely nudged me further into the world of Unix. Pathnames are different across operating systems, and making sure that our scripts are on the same page about that is crucial to functionality. Glob offered me a chance to become more familiar with some of the nuances between different terminals and to start practicing. Glob is a Python module that converts the names of paths into a style Unix shells operate with. The project I contributed to was essentially a module defining File classes simulating Unix file objects in a filesystem. An attribute of a file object is the path to its location. I constructed a method for this class using glob that returned the contents of a directory the file object is contained within as a list, similar to the results returned by executing ls in Git Bash. It was cool using Python to influence Unix's own recursive search functionality with wildcard characters such as asterisk *.

Virtualenv

As I was preparing to teach myself to code during the pandemic, I developed a newfound appreciation for getting and staying organized. Organizing my life is very therapeutic and I'm convinced that one of the best feelings in the world is clearing the head fog that comes from looking at disheveled workspace and assuaging the anxiety of missing something important. Virtualenv is a fantastic workspace module for Python that compartmentalizes entire projects within the scope of what is known as a virtual environment. A primary example of this benefit is the need to install 3rd party packages for specific projects with PIP. Installing with PIP installs packages into Python's primary local namespaces, and this can get cluttered over time with one-off packages you don't use anymore. Keeping these packages within the context/the scope of a project is wise and powerful. I clone my repo into the virtual environment, install any needed dependencies for my setup, and push my changes to repo. Once I'm done, cleanup is as simple as rmdir [proj-name].