Every so many months I look up “X number of things every programmer should know” and do my best to incorporate one of those principles into my coding. There are some standard concepts: modularity, short methods, avoid “spaghetti code, ” understand what your compiler is actually doing, the four years and tens of thousands of dollars you spent on an education is worth nothing. Nothing.

My most recent gem is here. I actually found this article sometime ago and tl;dr-ed it, throwing it into the “Read This” folder. I’m not proud of shelving an article due to its length, nor that I ended the last sentence with a preposition, but that’s just how things went.

In any case, after rediscovering it, two points caught my eye. First, #5: Beauty is in Simplicity. (I’ll save you the trouble of changing tabs.) This section is about writing simple code that‘s also easy to read. Most of my short code is pretty much impossible to understand (kind of like this). Maybe it’s because all my variable names are in Bantu, but still it would be worth learning how to write simple code that another person could understand. New principle identified! That was until I saw #10: Consider the Hardware. According to this, lots of small functions aren’t necessarily the best for machine efficiency. Oh, good. Do I go with small methods for modularity and readability, or giant methods for more efficient execution?

The two aren’t actually exclusive, but they sure seem that way. I don’t have the time to learn the hardware and improve the code! Where do I strike a balance? So I cried a little, read some Sartre, and let my roommate destroy me in Backgammon (okay, so I didn’t have much say in the matter of who won). This is the most important decision of every three or so months – what am I going to fix? After eschewing the decision with a host of excuses – “The article is on Java Code Geeks. I’m not using Java!”, “I should really learn to comment my code. That’s where the problem is REALLY found,” “Why am I worrying about coding standards? PEOPLE ARE STARVING!” – I realized that I’m scared of hardware. There. I said it. In a more familiar format: My name is Kate, and I’ve been afraid of hardware for years.

Hardware has terrifying machine language, static shock, and shorts caused by soldering…which is *how you build it* in the first place. You can eliminate coding mistakes with a backspace, but physical, immutable hardware…I can’t…I won’t…

But I should. Programming languages all evolved from a point where coders were pretty much expected to know the hardware. Now that there’s more hardware (and languages) than ever, we’ve backed away. How many times, when introduced as “the person I call when my laptop isn’t working,” have you had to explain that you’re more of a software person? Why does that distinction exist?

Well, it’s really simple: there’s too much technology for anyone to learn anything without really narrowing their scope. I think we did it wrong by starting depth-first. A big part of what you decide to focus on is going to be hardware-based. Even designers need to realize that different screens will display their designs differently. There’s also a tendency to sort of “improve up.” By that I mean the idea that one can use higher level tools because they once wrote a machine instruction. Then the further we get away from the hardware, the less likely we are to want to go back. Then there’s education. College doesn’t really teach coders that they need to know their hardware. I took Automata Theory, and it was a fun class, but that’s as far as I got. I code thinking that somewhere under my IDE is an infallible state diagram that will guarantee all of my code is doing what I want. I never have to think about it and it will always be perfect.

This guy says it better than I can. I wouldn’t trust a psychologist who couldn’t locate the brain in a human being. I should probably stop trusting my code, when the truth is that I have nothing more than a cursory knowledge of the hardware.

So I decided to focus on learning the underlying mechanics behind why my code does what it does. I’m not getting a PhD in electrical engineering or anything, but I can at least learn a little about the machine I’m using. Looking at all aspects of the code’s life is a good way to keep those elegant solutions from becoming purely aesthetic — which is, I think, a good goal for what is essentially functional art.

I’m thinking I’ll wait until 2015 to try commenting my code.

Follow

Related posts: