Effective Programming

I recently finished Jeff Atwood’s blog-turned-book: Effective Programming: More Than Writing Code. It’s a compilation of blog entries about different ways to improve programming ability outside of the typical “study and follow a code tutorial” method. The whole book is worth a read, but here are some interesting points I took away from the book and the names of their chapters:

1. For an easy way to improve programming ability, read programming blogs.

“When we read a post, or a book, or look at a new language, let’s assume that some or even most of it will not be new. Let’s assume that we’ll positively detest some of it. But let’s also look at it in terms of our own profit: we win if we can find just one thing in there that makes us better programmers.”

  • Sharpening the Saw

Reading code and picking up syntactical candy is an effective way to improve coding ability, but the process can get tedious and boring. The same goes for software textbooks, computer science papers, and online tutorials. Some programming blogs are just as effective as all of the above, and far less boring. They’re much more personal and often stem from real life situations. An abundance of programming articles can be found at aggregate sites like HackerNews. There are thousands of submissions, but every once in awhile I’ll stumble upon a blog entry that I can personally “profit” from. The gains vary, but I think programming blogs provide a fine balance between education and entertainment.

2. The programmer can lie, the documentation can lie, but the code never lies. You must be able to read other people’s code.

“No matter what the documentation says, the source code is the ultimate truth, the best and most definitive and up-to-date documentation you’re likely to find.”

  • Learn to Read the Source, Luke

Programmers are lazy. Sometimes it works in our favor, other times it can work against us. Refusing to dig into source is where it can work against us. I’m sure there are exceptions, but we should be able to open up and step through most of the code we work with. Wikis and docs are great guidelines for understand pieces of software, but the only absolute truth of a program lies in its source! I believe most programmers spend more time reading code than writing it. Anyone can hack together software. It takes special talent to quickly understand how a program works by exploring the code.

3. A software developer’s ability to learn is hundreds of times more valuable than his or her experiences.

“It’s been shown time and time again that there is no correlation between years of experience and skill in programming. After about six to twelve months working in any particular technology stack, you either get it or you don’t.”

  • The Years of Experience Myth

Experience is very valuable, but it should be a direct result of learning. A year of experience means nothing if it was spent mindlessly fixing minor bugs or recycling bad programming habits. After every job or personal project, you should have a set of new tools added to your toolbox. Software developers who are constantly learning also provide a steady stream of valuable information to the teams they work with. Not only do they protect themselves from obsolescence, but their coworkers as well.

4. Don’t be shy, allow other people to read your code.

“When your code is reviewed by another human being - whether that person is sitting right next to you, or thousands of miles away - you will produce better software.”

  • Pair Programming versus Code Review

Whether it’s a young developer or a seasoned veteran, there are times a programmer may feel compelled to keep his or her code from others. A senior developer might feel a stubborn sense of ownership over code, not trusting it to any coworkers. A rookie might be too shy, afraid to look stupid in front of the team. Either way, this can lead to a huge un-maintainable blob of spaghetti code. As a young developer myself, I’ve concluded that feeling a little stupid in the moment someone criticizes your code is better than feeling utterly humiliated when the entire team sees the ugly mess you’ve swept under the rug over time. If you’re lucky enough to work with a rockstar group of developers, take advantage of the opportunity and let them review your work!

5. Great programmers are good for your team. Great programmers who are “bad apples” are absolutely and utterly terrible.

“You should never be afraid to remove - or even fire - people who do not have the best interests of the team at heart. You can develop skill, but you can’t develop a positive attitude.”

  • Dealing With Bad Apples

We all know what “bad apples” are. They have all the qualifications of a great developer, but just don’t fit into the “culture” of the team. While their skills provide value, their effect on everyone else is destructive. I’ve had the great pleasure of working with different types of bad apples. Some were able to hang around, thus slowly killing the team around them. Some left, allowing everyone to breathe a sigh of relief. Without bad apples, communication greatly improves. The team can get work done very effectively and, more importantly, together. Hiring good programmers who “fit in” is better than hiring great programmers who suck as human beings.

6. Spend more money on life experiences than on things.

“Things get old. Things become ordinary. Things stay the same. Things wear out. Things are difficult to share. But experiences are totally unique; they shine like diamonds in your memory, often more brightly every year, and the can be shared forever.”

  • Buying Happiness

This one is a no-brainer, but it’s always nice to see a little reminder of it. It’s a classic lesson in finding happiness. I like to view the “experience vs thing” argument in terms of opportunity cost. I could go out and buy a brand new BMW to replace my aging Nissan. My preferred down payment for one of these bad boys ranges from $5000 to $8000. A brand new car would bring some glamour and a bit of fame among friends, but it would last about a week. Then, it becomes just another car on the road (an expensive one at that). A BMW would be awesome, but with that money, I could fly out to Argentina and hike around Patagonia. I wouldn’t have the luxury of rolling around in the “ultimate driving machine”, but I’d have memories of being in one of the most beautiful places on earth. Again, this is a no-brainer.