Dhanji Prasanna sums up the strengths of Java as capably as you’ll ever see.
When I was younger, I was obsessed with the following maxim from George Bernard Shaw’s Maxims for Revolutionists:
The reasonable man adapts himself to the world: the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man.
That quote sprung to mind when I read this post by Sam Stephenson where he explains why he doesn’t invest too much effort in his dot files. Here’s the key bit:
What I discovered is that in many cases, my ability to adapt to a foreign environment without frustration is more important than the benefits of configuring a local environment to suit my whims. And that being able to quickly recreate my environment from scratch is an asset.
I fall more into Stephenson’s camp than I do into Shaw’s at this point, at least when it comes to my own tools. As software developers, we are trying to build things that adapt the world to ourselves, but with experience, I find it more and more important not to bind myself too tightly to any particular tool or process.
Tom Ryder on shell prompts:
You can tell a lot about a shell user by looking at their prompt. Most shell users will use whatever the system’s default prompt is for their entire career.
Should we be asking job candidates for their dot files?
Nelson Minar has a nice, short writeup of the Linux kernel bug that caused servers to spin out of control yesterday. Most initial write-ups blamed Java, but that was incorrect. Interestingly, Java not only accounts for leap seconds, but also mentions them prominently in the documentation for the java.util.Date class:
Although the Date class is intended to reflect coordinated universal time (UTC), it may not do so exactly, depending on the host environment of the Java Virtual Machine. Nearly all modern operating systems assume that 1 day = 24 × 60 × 60 = 86400 seconds in all cases. In UTC, however, about once every year or two there is an extra second, called a “leap second.” The leap second is always added as the last second of the day, and always on December 31 or June 30. For example, the last minute of the year 1995 was 61 seconds long, thanks to an added leap second. Most computer clocks are not accurate enough to be able to reflect the leap-second distinction.
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.
About a year ago, Twitter platform engineer Dan Webb wrote an article rejecting hash-bang as well, which made it pretty clear that Twitter would be moving away from this architecture.
It feels good to see terrible ideas die, even when it takes awhile.
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
- Algorithm & Blues (Rdio)
- Backing & Hacking (Kickstarter)
- Bitly Engineering Blog
- Code as Craft (Etsy)
- code.flickr – One of the original engineering blogs.
- The Corner (Square)
- Coursera Technology
- Facebook Engineering’s Notes
- 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
- Making Pinterest
- The Netflix Tech Blog
- NPR News Apps Blog
- Paperless Post Dev Blog
- SlideShare Engineering Blog
- SoundCloud Backstage
- Spotify Labs
- Tumblr Engineering
- Twitter Engineering
- Viget Extend
- Wayfair Engineering
- Wealthfront Engineering
- Yammer Engineering
- Yelp Product & Engineering Blog
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.
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 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.