How I grew an amazing neckbeard

(i.e. 5 1/2 things that made me a better programmer)

tl;dr

Learning programming philosophies gave me a huge lift in my ability to produce quality software fast and enjoy doing it. Here are some of the principles that made all the difference:

1. Code like glue- just a little to hold things together

2. Understand every component’s opinion before you use it.

3. Ask yourself, would someone else understand this?

4. Know when to not repeat yourself.

5. Get your stack right, early.

5 1/2. Don’t be overly obsessive about any of the above.

Who says I’m a good programmer?

I’m basing the statement that I’m a good programmer entirely on a feeling. That is, how it feels to write code when you’re good at it. Programming is amazing work when you have this feeling. I also know how it feels when you’re a bad programmer.

I spent many years as a terrible, hack of a programmer. With every project, I felt like I was in over my head. It took a long time to get anything working and not for lack of writing code. It took many lines of code to make even minor things happen. Everything I created felt like a house of cards that would come crashing down at the slightest nudge. The only thing I dreaded more than digging through someone else’s code was digging through my own. Writing code felt bad and I wasn’t getting any better.

So how does it feel now? It feels good, really good. It’s effortless, like solving a crossword puzzle for which you know the answer to every clue. Yet, still challenging and fun. Reviewing past code feels instantly familiar like a favorite pair of well-worn jeans. Not only is the code easy for me to understand again, but colleagues rarely have to ask questions, because it just makes sense. No part of any project feels overwhelming and everything is finished in less time than I expect.

Flipping the Switch

There was a definite switch that flipped in my head that allowed me to improve drastically in a short time. I may have been teetering for a while, but there was a definite flip that happened around the time I started learning Django.

I’ve used quite a few languages and frameworks and have probably run the tutorials for at least a couple dozen. I wanted to learn either Ruby on Rails or Django and spent an entire weekend reading everything I could on both frameworks to help me decide. The single document that really bowled me over was Django’s Design Philosophies. After reading, I felt like I already knew Django. Not because it was such a good description of the framework, but because it gave me a look inside the heads’ of the authors. I didn’t even know Django, yet, I knew how the authors intended me to use it. This was my first glimpse into the power of programming philosophies.

In parallel to learning Django, I dove into programming philosophies. It became easy to see how most good software follows a few simple, but powerful principles. There are many principles such as “loose coupling” and “don’t repeat yourself” and they all have merits. Over the past couple of years I’ve tried to learn as many programming philosophies and principles that I could, and have incorporated many into my daily programming. The following list is my own distillation of the programming design philosophies that have had the biggest impact on my ability to not only write effortless code, but enjoy programming immensely.

Think of code as glue

I used to build radio-controlled airplanes when I was a kid. The trick to a great finished model is to fit parts together well and use as little glue as possible. Big glue joints are weak and result in a heavy, unbalanced plane that doesn’t fly well. I approach programming the same way I would build a model airplane. I find a well-maintained framework, library, module or other component that does something really close to what I need and write as little code as possible to incorporate it into my project. My code is the glue and less is more.

Respect the opinion

Everyone has an opinion and all code is opinionated. Besides well-maintained, I always look for code that shares similar opinions with my own project. An easy example opinion with web front-end code is browser support. Some libraries support every browser back to IE6 and others just focus on the latest and greatest. If your project is ultimately for a corporation that still uses IE7, you’re going to run into trouble if you use components that support only the latest browsers. Understand and respect the opinion of any code you incorporate into your own.

Write understandable code

Anytime I’m faced with multiple options for how to do something I always take the route that would be more easily understood by someone else. That also means it should be more easily understood by me. If I’m not sure which way would be more understandable, I make the “someone else” a real person. I image the “someone else” is the author of a library or framework I’m using. Would I have to explain how I am using her library? When easy understandability is just impossible, leave good comments.

Don’t repeat yourself, or prefactor

Probably everyone has heard of “Don’t Repeat Yourself”. There is much written on the greatness of the DRY principle and I am a believer. Though, I have a slightly more practical approach which avoids wasted effort that I call prefactoring. When I am in the middle of writing a snippet of code that I think *might* be useful elsewhere, I don’t immediately stop and make it reusable. That’s what I call prefactoring. Unless I’m 100% sure I need it again, I might be doing work I don’t need to do. I also don’t know exactly what the other use is, so won’t be completely sure how to best make it reusable. Instead, I wait until I find the need to reuse it and then refactor. I now have multiple places to use the snippet so I am certain it will be worthwhile and readily reusable. I throw away a small bit of code, but I save even more by eliminating wasted prefactoring.

Invest in component architecture early

Good architectural decisions early in the development process always pay off *big* later. Designing a scalable model to store your user accounts is important, but so is selecting the right database. I elevate component architecture to my first concern because I can’t even set up a framework until I have a working database. And, changing databases later is painful. So is changing just about any core component. I sketch out the components before I start building anything so that I can identify shortcomings early. There are many great blog posts about winning stacks like this one for Django.

Finally, don’t sweat it

I don’t get obsessive about any of the above rules. I follow them about 90% of the time. For me that feels like the sweet spot. You should do whatever feels good, after all, programming should feel good.