I enjoyed this coding manual prepared by University of Chicago economics professors Matthew Gentzkow and Jesse M. Shapiro for their research assistants. It’s a great short manual on how to code for clarity and performance. Considering the vast amount of really bad code that is produced in academia, it’s nice to see a focus on this sort of thing from professors. I especially enjoyed the parts where they give professional software developers too much credit. For example, here’s an assertion:

Real programmers write “unit tests” for every piece of code they write.

Would that that were true.

Last week Noah Sussman gave a talk and said that developers should ideally program in an environment that resembles as closely as possible the environment they’d use if they were programming just for themselves, because that’s most likely to be the most productive approach.

Usually, I start with something at least a little bit new every time I build a new application, because there’s something I want to learn. So I’ll try a new framework, or a new language, or a new something, just so that I can pick up some new skills in the process of building something.

Noah referred to this approach as naturalistic programming (I think). It made me think of what naturalistic programming is for me. Right now if I’m building an application from scratch, I use Ruby, Sinatra, Bootstrap, and jQuery. For the view layer, I use plain old ERB. For the database, I use SQLite as long as I can, migrating to MySQL if necessary to scale. If using an ORM will save time, my choice is DataMapper.

Any or all of those choices may change next week, but that’s what hits the sweet spot between getting up and running fast and having the flexibility to scale up for me right now.

And interestingly, I think I would make the same choices even if I were starting a new company tomorrow. When you build an application that is going to scale to a large number of users, you’re going to wind up rewriting all of it in phases no matter what. You might as well start out focusing on maximizing productivity and replacing components as they break down.

One of my favorite technology trends of the past few years has been the emergence of engineering blogs. They are, mostly, a recruiting tool, but that doesn’t mean that you can’t learn a lot about how companies operating at varying levels of maturity and scale go about their business. Here are the engineering blogs I’m following right now:

• Airbnb Nerd Blog
• Backing & Hacking (Kickstarter)
• Bitly Engineering Blog
• CloudFlare
• Code as Craft (Etsy)
• code.flickr – One of the original engineering blogs.
• The Corner (Square)
• Coursera Technology
• DocuSign Dev Blog
• Dropbox Tech Blog
• Facebook Engineering Blog (older stuff)
• Foursquare Engineering
• Google Engineering Tools
• IMVU Engineering Blog – One of earliest companies to publicize its continuous deployment process.
• Instagram Engineering
• Last.HQ (Last.fm)
• LinkedIn Engineering
• Lyft
• Making Pinterest
• Medium
• The Netflix Tech Blog
• NPR News Apps Blog
• Paperless Post Dev Blog
• Pinterest
• Several People Are Coding (Slack Engineering)
• SlideShare Engineering Blog
• SoundCloud Backstage
• Spotify Labs
• Tumblr Engineering
• Twitter Engineering
• Uber Engineering Blog
• Viget Extend
• Vine
• Wayfair Engineering
• Wealthfront Engineering
• Yahoo
• Yammer Engineering
• Yelp Product & Engineering Blog
• Zenefits

What sorts of things are companies publishing on engineering blogs? Here are a few examples of particularly good engineering blog posts I’ve read over the years:

• Lessons Netflix Learned from the AWS Outage is a great post-mortem on how Netflix dealt with a major outage that affected them in surprising ways.
• Building a recommendation engine, foursquare style explains the computational shortcuts you can take when you’re dealing with a lot of data.
• The Etsy Way rounds up a number of posts that explain how Etsy created its engineering culture.
• Creating an interface for geofences is a look at how Flickr built an interesting feature.
• Twitter explained how they moved to a new datacenter.
• LinkedIn’s three part series on building their iPad app was epic.

This is just a small sample of the great stuff that companies are posting to their engineering blogs these days.

If you know of any good engineering blogs that I’m missing, please post links in the comments.

Update: Added a few additional blogs suggested by @mrtazz.

Update (March 6, 2013): Added the NPR News Apps Blog.

Update (May 10, 2013): Added Kickstarter’s Backing & Hacking blog.

Update (February, 22, 2014): Added Coursera Technology.

Update (March 24, 2014): Added Algorithm & Blues, Rdio’s engineering blog.

Update (August 29, 2014): Added Yahoo.

Update (December 13, 2015): Added Medium and Vine.

Update (August 20, 2016): Removed Rdio and Prismatic (RIP), updated Facebook, Yammer. Added Uber, Pinterest, Dropbox, Lyft, Zenefits, CloudFlare, Slack.

The most awesome story I read yesterday was trial coverage from Oracle’s lawsuit against Google over Java and Google’s reimplementation of Java for Android. Here’s the judge explaining to Oracle’s attorney (famed litigator David Boies) why Google had no incentive to copy the code they were alleged to have copied:

I have done, and still do, a significant amount of programming in other languages. I’ve written blocks of code like rangeCheck a hundred times before. I could do it, you could do it. The idea that someone would copy that when they could do it themselves just as fast, it was an accident. There’s no way you could say that was speeding them along to the marketplace. You’re one of the best lawyers in America, how could you even make that kind of argument?

As folks like Ray Cromwell and Mike Loukides point out, this is the best refutation I’ve seen for the argument that people shouldn’t learn to code.

As a software developer, I’m thrilled that Judge William Alsup learned to code at some point, and that he’s doing some programming to help evaluate the evidence being presented in court. It’s common to see people making policy decisions, legal decisions, and business decisions that wind up being terrible because the decision makers lack the technical knowledge to even solicit good advice.

As I said yesterday, I welcome anyone who wants to dive into programming.

Jeff Atwood wrote a provocative blog post entitled Please Don’t Learn to Code that I wasn’t going to respond to because it looked a lot like trolling to me. What I think, though, is that Jeff is conflating the suggestion that people learn to program with the suggestion that everyone should be a software developer. In the end, though, the post is just a mess.

I’m not for falsely equating programming with essential life skills like reading, writing, and math, or with the things Jeff suggests people spend time on instead — learning how things work at a “basic level” or becoming better communicators. That said, I would encourage people to learn to program for a number of reasons.

The first is that much of the world is run by computers. Learning to program involves learning how computers work at a more basic level. Even just knowing how the Web works at a technical level is helpful, if only to know if something is broken on a site you’re using or on your local computer.

In some ways, the relevant analogy is to auto repair. Knowing how your car works and how to fix some things doesn’t make you a mechanic, but it does make it less likely that you’ll be stuck on the side of the road with no recourse other than roadside service, and also helps to ensure that you won’t be exploited when you have to deal with a mechanic.

There are many people out there who work with software developers who are not themselves software developers. Understanding how to program makes it easier to communicate with them.

The second thing is that learning a little programming can make you better at your job if your work involves using a computer at all. Here’s my favorite programming story of all time. I used to work with a software developer who started her career at a chicken processing plant in Arkansas. She started not as a programmer but as an administrative assistant. Back then, they didn’t do word processing, they typed on typewriters.

Even though she had no formal training as a programmer, she figured out that the electric typewriters they used were programmable, and learned how to program them to complete various forms rather than typing them in by hand. Her boss noticed her good work and had her learn how to program another computer they had in the office. Eventually, he encouraged her to quit and go back to school to become a professional software developer.

Had she not been a smart and curious person who figured out that programming would make her job easier, she may still be working in that chicken plant. Today programming is now a more fundamental tool of automation than it has ever been. How many people could eliminate redundant work if they knew how to write scripts to collect data for them and schedule them to run nightly? How many people struggle with terrible Web applications that could be improved with user-created style sheets or Greasemonkey scripts? Programming empowers you to remove annoyances from your daily life.

The third reason is that learning to program teaches you a different method of problem solving than most people are familiar with. Learning to program teaches you how to break down problems into familiar components and then meld those components together to create a solution. Programming is not the only way to learn those skills, but it’s a good way to learn them, and that skill is widely applicable to every day life.

I wouldn’t make the argument that we make programming courses mandatory in school, or that everyone should learn to program, but I would encourage anyone who has the slightest interest in programming to pursue that interest.