Friday, August 1, 2014

Code is beautiful.

Code. Such a simple word, yet extremely powerful. In this day and age it's everywhere, it powers our cars, phones, computers, power grid, etc. It's the next technological step for mankind; we created technology; code allows us to control that technology. 

The Inklings of an Idea

At the most basic level, code is just text that is either compiled or interpreted to do a certain task, or move some bits around, or blink an LED. Right now, I'm typing into my Firefox Nightly window which sits upon a framework of code, using javascript on Blogger.com to eventually post this text / html to a server and have it hosted for all to see. It's so complex yet it has to work seamlessly. Sure, I could use VIM and write all my blog posts in pure html via SSH, but I choose this method, why? Because it is seamless. Two separate methods of communication with the world, all built on code, same functionality. 

Looking at programming and coding at a functional level is all well and good. For instance if you're just learning a programming language you'll need to get the mechanics of that language down, learn how to build it and run it, debug, etc. However, once past the layer of syntatic symbols, there's something more beautiful... But I'll get to that later.

A bit of background before I dive into this topic any further. I'm going to be a sophomore student studying Computer Engineering, I've programmed for a number of years, and I've had two internships programming in various languages (If that didn't sound like an elevator speech then I don't know what would). I've also been exposed to professional programming schedules and the responsibilities that go long with that. Through my personal and professional experiences with code, I've come to form an idea about code that I can't quite fully grasp as of this post but it's a start.

Imagine you're a programmer at a medium sized company developing code for some platform, now imagine 50 years down the road, how does the code you committed yesterday work and how compatible is it with this imagined future code? Not very well right? It's impossible to know that far in advance what features or frameworks you're going to have to interface with. The thing about your code in 50 years is that (if it's still around in some form or another) it will have evolved and changed, to make use of new features and technologies. This is a glimpse into why code is beautiful, it's metaphysical, it's amorphous, it's an exact reflection of the time the team of programmers put into it. 

 

Code Like an Ocean

Now that I've fleshed out that the "code" I'm talking about is more abstract than concrete characters, I can pull back the curtain a bit more on my thought process. I'll admit it was very hard to focus these thoughts into something as coherent as this blog post, I'll try my best to explain my thoughts. The one path that led me down the rabbit hole was Object Oriented Programming, or designing pieces of software that couple with one another to mimic complex systems. As opposed to functional programming which is linear and is very difficult to scale, OOD is quite literally what you make it, a reflection of sorts of the inner psyche of the programmer writing it. 

Take for instance a program that creates a Car object, makes some Wheel objects and puts them all together, pretty simple right? It reflects a relationship between objects that make sense in our physical world. But what about the instances in which we need to create a more abstract system? Where do these ideas stem from and how is one considered 'better' than the other? In this way code is meta, there's no inherent structure to conform to, only the imagination of the coder's mind, a canvas for the imagination and a world still to be explored. 

Reaching back to the "What will this code look like in 50 years" thought experiment, how will people of the future perceive programming? Will it all be by though without a mouse or keyboard? I believe that our notion of programming today will be much different in the future, perhaps it will all be done by thought, programmers will sit meditating, willing complex systems into being from the singularity of their collective minds. No barriers, no boundaries, no code rebases. 

But "Wait!" you might say "Humans need rules and rigidity!", indeed you are correct, the internet was not build upon the ethereal thoughts of our internet fore-bearers, but was instead engineered and painstakingly designed to allow the explosion of a previously under utilized technology. And here we find ourselves, the humble programmer, amid the Ocean of Code, drifting endlessly across the rigid and rough waters, constantly paddling towards the calmer seas of lucid programming. 

  

All is not without consequence

You might think it's simple to brute force our way to greener pastures, just program like hell and you'll reach nirvana. But it's never that simple. Bringing the conversation back into the relevant world, there is a barrier, who's name is Technical Debt. Wandering back to my high school days I would write programs to fetch and scrape websites using Java. I was naive as to OOD in those days, but I beat my head against the wall until I could scrape RSS feeds for popular websites blocked by my school's IT department. It was crude but hey, I wanted that freedom. No fancy frameworks, no beautiful idiomatic code, no revision control. 

Looking back, I realize the sheer amount of tech debt that I was ranking up. Had that continued into a bigger project, I would have been swamped, and work would have ceased. Project management tools can only do so much to make your code manageable. All programmers walk the line between the time it takes to plan a project and the time it takes to execute said plan. As outlined by this relevant xkcd comic 

http://xkcd.com/1319/

Pulling in some experience from my two previous jobs at Webfilings (now known as Workiva) and Garmin, I've gotten the chance to work on fairly large projects and deal with tech debt first hand. While Workiva was very organized and all code, as far as I could tell, was well written and meaningful, they also ran into issues using two different languages for both the front and back ends, a constant source of upkeep was required to maintain both. Despite this tech dept it was managed and I consider Workiva to be a pretty efficient coding machine. 

On the flip side, the code I had been working on at Garmin was significantly older. The framework documentation was nonexistent and people just went to 'the guy who knows about that module' for any help, I was surprised how this system could function when built upon very old code. While Garmin had a larger technical debt working in a non OOD language with complex but non-decoupled frameworks, they still managed to get all the functionality they wanted for their line of products. They did this by correctly managing software development teams excellently and efficiently.

To compare these internships to games, Workiva is to Civilization V as Garmin is to Dwarf Fortress. Both are games I enjoy very much but DF has a much steeper learning curve. Tying this back to code as a metaphysical instance, your blob of code wont standup unless you trim the fat and focus on making your project or framework modular and easy to navigate. 


Walking the line

I think it's safe to admit that the world will always have issues, always some form of misgivings somewhere. Code is that way, there will never be completely lucid and unified API, period. There might be some pretty darn close APIs out there but under the thin veil of neatly organized function calls and objects, there lurks a labyrinth of programming pitfalls. Now, this post isn't going to actually teach you the exact way to fix your specific problem, but more as a spiritual guide to programming. Feelings your way through the tougher problems presented, that can't be solved with a simple switch case or loop comprehension. 

Our secondary jobs as programmers is to not only write the code we think up but to architect this code in a meaningful way. Even if you're just beginning to program, it's important to start thinking about how your code will function with other pieces that you've written. I'll admit, it's hard to predict whether your one-off script will turn into a framework. It's even harder to begin putting together lines of code, not knowing whether your code is destined to be a glorified POS or a beautiful API. 

It's only going to get harder as the way programs are written will be built on more complex frameworks. There's nothing to fear for you stand on the shoulders of giants. Those who coded before you, meticulously thought out and planned their systems. And in time it becomes harder to keep track of your own project, therefore use commenting and copious amounts of documentation to clear your thoughts. 

Look into yourself dear programmer, find your inner strength and think before you type. Work out all the possible routes and expansions you want to add to your project before you open a new Visual Studio project. Leave room for seconds, and thirds. Know the extent of your project even better than you know yourself, and you too can walk the line. 

 

from Mind import Sanity

This all might seem a bit crazy to you, it's still pretty damn crazy to me. Like I've stumbled upon some secret to the universe. Above all the metaphors and abstract ideas, I've been enlightened as to the true inner workings of programming and organization. I hope that my brief journey with you has been equally eye opening. Thinking abstractly about code and then being able to solidify it into complex systems that are powerful AND work well is an excellent skill to have. As a programmer that skill will basically start you on a path to a great career.  

Now, as a bit of a disclaimer. I don't mean to sound all high and mighty, I'm not suggesting that programming is the only place where planning is important, of course planning is crucial in nearly every aspect of life. I'm simply providing my thoughts on how to be a better programmer. Fortunately these skills of abstraction translate well to the real world, critical thinking is ever more important. 

Programmer or not, I hope you criticize my opinions above, the world is all about improving on the ideas of others and looking for self betterment. Do not shy away from complexity, instead embrace it. Think of your code on a more grand scale. See the big picture. Grab hold of your programming skills and use them as your super power, control and create the technology around you. Make the world a better place. And above all remember that Code is Beautiful.

2 comments:

  1. This is a great post; it was very edifying. I look ahead in reading more of your work. dialling code 01225

    ReplyDelete
  2. Now I can call to my clients much faster than ever before and all the credit goes to telephone area codes. This is really a revolution of communicating! Suggested to all! england area codes list

    ReplyDelete