Strong opinions, weakly held

Month: April 2011
(page 1 of 3)

You’ll see a ton of links today to an article at Ars Technica with the headline, Guns at home more likely to be used stupidly than in self-defense. People are interested not because of the content of the article, but because of a trick the author used to see whether people are reading it before posting comments. He inserted this about halfway through:

If you have read this far, please mention Bananas in your comment below. We’re pretty sure 90% of the respondants to this story won’t even read it first.

The sentence was added after the article was published. That’s why the first three pages of comments don’t have any mentions of bananas. I wanted to post about something else, though. Here’s the first paragraph of the article:

This morning, a press release dropped that seemed designed to create controversy, given its title: “Guns in the home provide greater health risk than benefit.” The fact that it came from a relatively obscure journal—the American Journal of Lifestyle Medicine is not indexed by the PubMed system, and has no impact factor—suggests it might be an attempt at getting some publicity. Studies on this topic are also extremely challenging, as it’s difficult to control for cultural and economic differences between nations and US states.

Why does this review, written by a Harvard faculty member who specializes in this area, appear in a marginal journal? The New York Times published the answer to that question back in January:

In the wake of the shootings in Tucson, the familiar questions inevitably resurfaced: Are communities where more people carry guns safer or less safe? Does the availability of high-capacity magazines increase deaths? Do more rigorous background checks make a difference?

The reality is that even these and other basic questions cannot be fully answered, because not enough research has been done. And there is a reason for that. Scientists in the field and former officials with the government agency that used to finance the great bulk of this research say the influence of the National Rifle Association has all but choked off money for such work.

Industry analyst James Governor takes a shot at creating a taxonomy of developers, with, I assume, people who work in developer relations in mind. I started thinking about how I classify developers, and boiled it down to positioning them on two scales.

The first is vocation versus avocation. The second is inward focus versus outward focus.

The first scale has to do with motivation. Does the programmer program because it’s their job, or because they enjoy developing software for its own sake? It’s helpful to know where your colleagues and potential hires lie on this scale, because it matters a great deal in terms of managing them. It can be difficult to motivate developers who are at the vocation end of the spectrum to learn new things or be experimental if you can’t show them in a tangible way how doing so will be better for their career. On the other hand, with developers who are at the avocation end of the spectrum to quit writing code and ship. When they pick an approach to solving problems, it’s often hard to determine whether they’ve chosen the best solution for the business or they’ve chosen the solution that intrigues them the most.

Inward focus versus outward focus has to do with how developers prefer to solve problems. When an outwardly focused developer runs into a problem, they’ll use Google, they’ll ask a coworker, they’ll post a question on Stack Overflow or on the appropriate forum. When they’re assigned a task, they’ll look for open source libraries that satisfy the requirement or they’ll look for blog posts from people who’ve attacked the same problem in the past. They’re not afraid to get other developers on the team to stand in front of the whiteboard and puzzle out the problem with them. On the downside, these are the developers who create Web sites that use jQuery and MooTools and wind up loading 25 jQuery plugins on every page of a site. They copy and paste code they find in blog posts even if they don’t actually know how it works.

Inwardly focused developers generally prefer to rely on their own brainpower as much as possible. They often times exhibit “not invented here” syndrome but on a personal level. When they are working on a tough problem they often seem to disappear completely until they’ve figured it out. It often takes them longer to solve simple problems because they don’t tap into the community to see how other people problems. On the other hand, the further you are toward this end of the scale, the more likely you are to be able to solve deep problems at all. These developers are never stuck when Google doesn’t return any interesting results related to their problem. They’re also often the only developers on the team who actually know how the entire system works. They’re the people who actually invent stuff.

Both of these scales are value neutral. A good team will have developers who fall all over the graph. Teams that are too inwardly focused often fail to incorporate industry progress into their own code and practices. Teams that are too outwardly focused have a hard time gaining a competitive advantage in terms of technology, although they can often deliver very quickly. Teams with too many developers who program for its own sake often frustrate the rest of the company for a variety of reasons. Teams with too many career-focused developers often lack creativity and usually fail to achieve excellence.

The other scale that matters is good versus bad. Falling to one side or another on either of the previously mentioned scales doesn’t make you good or bad at software development, but goodness and badness manifest themselves in different ways based on the type of developer. Identifying good and bad developers is a separate discipline, one I’d like to get better at.

In Apple’s explanation of why they kept a log of locations where your phone had been, they also explain how they use crowd-sourcing to allow iPhones to rapidly ascertain their location:

The iPhone is not logging your location. Rather, it’s maintaining a database of Wi-Fi hotspots and cell towers around your current location, some of which may be located more than one hundred miles away from your iPhone, to help your iPhone rapidly and accurately calculate its location when requested. Calculating a phone’s location using just GPS satellite data can take up to several minutes. iPhone can reduce this time to just a few seconds by using Wi-Fi hotspot and cell tower data to quickly find GPS satellites, and even triangulate its location using just Wi-Fi hotspot and cell tower data when GPS is not available (such as indoors or in basements). These calculations are performed live on the iPhone using a crowd-sourced database of Wi-Fi hotspot and cell tower data that is generated by tens of millions of iPhones sending the geo-tagged locations of nearby Wi-Fi hotspots and cell towers in an anonymous and encrypted form to Apple.

This technology seems really, really cool to me. I knew that Apple had a database of wifi hotspots that they used to determine where an iPhone is located without using GPS, but I didn’t realize that they were building the database using data uploaded from those phones.

As far as the location log goes, some programmer created the log but never bothered to scrub or rotate it. Been there, done that.

EveryBlock’s post-mortem on the Amazon Web Services outage that took down their site sets a standard of accountability and transparency that every engineering team should aspire to. Rather than blaming AWS for their downtime, Paul Smith explains that had they followed the architectural guidelines provided by AWS, they would have been fine. Nearly all potential outage scenarios can be mitigated given sufficient resources, but it rarely makes sense to build the infrastructure to avoid all of the known outage possibilities. It’s just too expensive and time consuming. What I respect is Paul Smith’s acknowledgement that it was those choices that resulted in the site’s downtime, rather than the problems with the AWS data center.

It’s a fun time of year for cable television as there are three shows I’m very interested in airing at the same time.

Let’s start with my television obsession of 2010 — Treme. The second season premiered last night, and Nola.com already has their Treme explained post up, providing all of the local color that I so desperately crave. I also assume that NPR’s jazz blog, A Blog Supreme, will be recapping the show each week, as it did last year. Finally, HBO has launched its own Treme blog, written by the show’s story editor Lolis Eric Elie. Be sure to check out his reading list and viewing list.

I’m also watching HBO’s Game of Thrones. I’m a at a bit of a disadvantage because I haven’t read the books. At the same time I’m trying to avoid spoilers from the books. I’m counting on the recappers at Television Without Pity to fill me in on all the details that I’m not catching. Here’s their long recap of the show’s premiere.

Finally, I’m watching The Killing on AMC. It’s an American remake of a Danish murder mystery serial, deliberately paced with dark atmospherics. TWoP is recapping this show as well. For pithier recaps, your go-to source is Project Rungay.

The Washington Post today dives in to a question that I’ve wondered about almost since President Obama took office — what happened to the effort to close the detention center at Guantanamo Bay? The reasons are as boring as you’d expect. Republicans thought they could gain a political advantage by fear-mongering about it. Congressional Democrats weren’t willing to stick their necks out to defend the President’s plan. The Obama administration started backing away from the issue as soon as it became a political risk. Now we’re at a point where both parties have essentially accepted that adhering to the Constitution is optional when it comes to terrorism, however politicians choose to define it.

Last week I mentioned that the only thing I was struggling with in my transition to Vim for editing code was juggling multiple open files at once. Switching from one file to another is really easy, especially if you’re working on a Rails app and using rails.vim. There are a number of really nice navigation features built in that make it easy to open any file from your project and to switch among related files.

This morning I noticed that these navigation commands all have “open in new tab,” “open in new split window,” and “open in new window” variations. So to open a model called “store.rb”, in command mode you just type:

:Rmodel store

To open that model in a new tab, you type:

:RTmodel store

Navigating among tabs using the keyboard is easy as well:

<tab number>gt

So, to switch to the third tab, you just type “3gt”. In command mode you can also just type “gt” to move to the next tab.

Suddenly, my problems are solved.

I’m also getting the hang of split windows, which I should have mastered years ago. They have two advantages over tabs, the first being that they make it easy to look at multiple files at once. The second is that you can use them in terminal sessions as well. Another nice thing about split windows is that you can split your view of one file so that you can look at one section of the file while you work on another.

I think the real lesson here is that not taking the time to master your tools is false economy.