Software Engineer
The Essence of Programming
April 03, 2019

At the time of writing this,I live in Concord, NH. It's a fairly windy place, and when the wind takes out the neighborhood power lines, I make my way to the local watering hole. Somehow they have five dollar teas, but have excellent dark beers for the same price, so it evens out. While I work, I one of those beers and kick my proverbial feet up as I work and think. This blog series is a result of those internal monologues which have somehow made it out to the page.

The Essence of Programming

When I first got started, I thought programming was about the code. The lines you could put out, what you could do, and all the clever little tricks that you could put together. Why make a block of code when you can do it in a line, I thought. I was wrong. I've come to realize as time goes on, that programming is about a flow of logic. That's all it is. It's about expressing an idea, and then figuring out how to bring that chain of logic to reality. Have you ever taken the spaces out of a sentence just because you can fit more into the same space? Itdoesn'tworkverywellusuallyunlesswhatyouaretryingtoexpressisveryveryshort.

Logic is easier to follow when it's spaced out. It's easier to read when you come back to a project a few months later, and it's easier for the soul that has to follow in your footsteps. I firmly believe that it is harder to read someone else's code than it is to write your own from scratch. Be kind to yourself and others. Keeping the clever lines to a minimum helps spin the world just a little smoother.

And while we are on the idea of programming as an expression of logic, I would like to say that copy-pasting is the inverse of this idea. Just as programming should be ideas into code, the confluence of easy, not quite-fitting answers is the antithesis. You take a chunk of clever, or sometimes not so clever, code from an online source, and you throw a chainsaw at it until it can limp into place into the rest of the frankenstein monstrosity you have assembled. I am almost certain that every dev on the planet has done this at least once at some point. In fact, it is very rare that I build something where I don't have stack overflow open at least five times during the process on any given day. I am not saying don't utilize outside help. However, if the knee-jerk reaction for any project, assignment, or work is to instantly copy-paste, you are doing yourself a disservice. Programming is about building blocks. There exist so many layers of abstraction in any given task that it actually beggars the imagination.

I build my blog using Gatsby. Gatsby is built on top of Facebook's React and GraphQL. GraphQL is based on mathematics and graph node-edge structure, and React does some very impressive interactions with the shadow-dom to prevent excessive re-rendering. These are built on top of JavaScript, but when it's server-side rendered, Node is built with C/C++. Which then... you get the idea.

Something as easy as HTML and a splash of JS has exploded into a multi-library/framework conglomeration, and knowing the basics of how it actually works is very important. If you skip the basics, then you're liable to skip the medium level, and by the time everything has been abstracted away, you have no flipping idea how any of it works except for black magic.

It's OK to use tools and frameworks. I learned that after a long stint of trying to be a 'purist' and write everything vanilla. We have these tools for a reason! But at some level, you should know how they work.

I suppose this brings me to my next rambling point. Unrealistic deadlines are the origin of anti-pattern. I've had projects that I've been hired Monday, and they wanted a working prototype by Friday. Who does this serve? By it's very nature, any item that you try to encapsulate in programming tends to be more complex than the original item. After some time in the world of software and web development, I feel that the planning stage is the absolutely most important part of any project. Having the time to think through how you are going to build something, try and get a feel for the pitfalls and dead-ends a strategy might bring you to, that is what being an engineer or developer is all about.

All deadlines do is dumb down this process for an incomplete product. There must be somewhere, a musty old tome from the very first engineers of computers that states that any rushed job is an incomplete job. Any chain of logic that is rushed will have holes and be flawed. If you give two weeks to an individual to come through and sprint a project, and then hire two developers to maintain and add onto the project later, you have not saved any money. In most cases, coming into a codebase and understanding its quirks is harder than writing it in the first place. So now a project is incomplete, it's costing more to maintain than it ever would have taken to write, and it's a black spot on the programmer's conscience. Who can enjoy a flawed argument? What painter wants to mark half the canvas and then hand it off to be finished? No one I can imagine.