rc3.org

Strong opinions, weakly held

Month: May 2012 (page 1 of 2)

The debate over share buttons on blogs

In March, Jason Kottke launched a redesign that included something that I had long looked down on — sharing buttons. He explained:

I’ve always thought of kottke.org as a place where people come to find interesting things to read and look at, and design has always been crafted with that as the priority. A few months ago, I read an interview with Jonah Peretti about what BuzzFeed is up to and he said something that stuck with me: people don’t just come to BuzzFeed to look at things, they come to find stuff to share with their friends. As I thought about it, I realized that’s true of kottke.org as well…and I haven’t been doing a good enough job of making it easy for people to do.

After thinking about it, I agreed with that argument and added some sharing buttons to my post as well — only to services that I actually care about. Lots of people who I know use Facebook. I am a big fan of people sharing things on Twitter and Tumblr, and I find Hacker News to be useful at times as well, so I included those buttons.

Jason found that people are using those buttons. He has seen great results from mirroring his blog on Tumblr. I find that some people are using the buttons on my site as well.

Today, inspired by a post by Oliver Reichenstein provocatively entitled, Sweep the Sleaze, I learned that including those buttons made me look a bit desperate. Lots of smart people who I read agree with that assessment, and I more or less agreed with it myself until Jason Kottke changed my mind.

What Reichenstein’s post immediately made me think of was Nick Bradbury’s post from yesterday, Screw the Power Users. Here’s his advice:

But if you’re building a mainstream consumer product, then from day one you need to tell yourself, “screw the power users.”

That’s hard to do – after all, you’re a developer, so you’re one of the power users. You want to make people like yourself happy.

But I’d argue that’s one of the biggest problems that has plagued the software industry. We’ve all built stuff for ourselves, even though the vast majority of software users aren’t like us.

This is essentially the point of view that I came around to when I added the buttons. Am I a user of these share buttons? No. They’re a waste of space as far as I’m concerned. But other people do use them. They’re not slowing down the page load to any meaningful extent, and they’re pretty unobtrusive. I reserve the right to remove them the second they start to annoy me, but for now, I see including them as a worthwhile experiment.

In the meantime, writing a strident post entitled “Sweep the Sleaze” that takes dead aim at fish swimming around in a barrel is a much more obvious cry for attention than any number of sharing buttons on a blog post.

Twitter finally rejects their all-JavaScript approach

When Twitter launched “new Twitter” in 2010, a lot of people decried it as a bad idea. The big change was sending every request to the site to one URL, which hosted a JavaScript application that requested the appropriate data and then converted it to HTML within the browser. Here’s Tim Bray explaining exactly why Twitter’s approach was wrongheaded.

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.

Today, Dan Webb has posted an official announcement that Twitter is dumping the “render everything in JavaScript” approach for performance reasons:

Looking at the components that make up this measurement, we discovered that the raw parsing and execution of JavaScript caused massive outliers in perceived rendering speed. In our fully client-side architecture, you don’t see anything until our JavaScript is downloaded and executed. The problem is further exacerbated if you do not have a high-specification machine or if you’re running an older browser. The bottom line is that a client-side architecture leads to slower performance because most of the code is being executed on our user’s machines rather than our own.

It feels good to see terrible ideas die, even when it takes awhile.

The tools I use when I get to choose

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.

A list of engineering blogs

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:

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:

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.

Here’s what happened to the Nortel patent portfolio

Remember when Apple and Microsoft (along with some other companies) bought Nortel’s patent portfolio? Now they’ve formed a new company that’s in the business of extorting license fees from companies infringing on the patents that they now own. Who’s infringing? Everyone, according to the CEO of the new company formed to turn the patents into cash:

Pretty much anybody out there is infringing. It would be hard for me to envision that there are high-tech companies out there that don’t use some of the patents in our portfolio.

It’s an election year, this is a huge problem that exists entirely within legal realm, and yet there is no coalition working effectively to create change in this system. In the meantime, people are unwittingly working to destroy the technology industry entirely through litigation. In the meantime, nearly all developers go about building things as if patents don’t exist at all.

More on why you should learn to program

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.

Why you might want to learn to program

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.

The bubble pattern applies to venture capital

Back in 2007, I wrote about “the bubble pattern,” which was a sort of not particularly insightful observation that assets that perform well generate demand that outstrips supply, which in turn leads to a massive reduction in the quality of assets in that class.

Last week, Felix Salmon turned up a report from the Kauffman Foundation that documented the failings of the venture capital industry. Here’s his conclusion:

The big picture, here, is that an enormous number of institutional investors are still chasing VC returns which haven’t really existed in the industry since the mid-90s. So long as all that money is chasing a relatively small number of opportunities, and especially now that valuations for early-stage tech companies are going through the roof, the chances that the average LP will make any money at all in VC are slim indeed.

This is exactly what I was talking about back in 2007. I’ve worked at a number of venture-backed companies over the years, and I’m very glad for the opportunities that venture capital has provided, but that doesn’t mean investing in a venture capital fund is a great investment.

The grammar of Vim

Like a lot of people, I have gone retro when it comes to editors, using Vim for most of my day to day work. I’ve been doing most of my development these days in a terminal window, logged directly into a VM where I test my code. For more, see this article.

I have been a somewhat casual vi user for at least 15 years, but using it for all my development work has made it more important to vastly improve my Vim skills in a short time. The best article on Vim I read was Yan Pritzker’s Learn to speak vim – verbs, nouns, and modifiers! It totally revolutionized the way I thought about Vim.

For my first 15 years with Vim I tried to learn it the same way you might learn a foreign language from a phrasebook. I had learned everything in a disconnected way. Use j to move down a line. Use cw to change a word. Use yy to copy the current line into a buffer. You can get by this way, but it’s a very simplistic approach.

Advanced Vim users understand that Vim commands are a language unto themselves, and that the key to being productive is understanding Vim’s grammar. Pritzker accurately identifies that grammar as consisting of the following parts of speech: verbs, nouns, and modifiers.

The nouns usually represent positions within the document. For example, 0 represents the beginning of the current line. $ represents the end of the current line. j represents the next line in the file. When you use most nouns by themselves in command mode, the implied verb is “go to”. So if you just type j you move to the next line. There are some exceptions. For example, in command mode, s means substitute a character. In other contexts, it’s a noun representing a sentence.

You can usually supply a quantity along with a noun. So 5j refers to the five following lines, and typing it will move your cursor down 5 lines if you don’t supply a verb. Likewise, the w noun represents a word, and moves to the next word to the right if you use it by itself. 3w moves three words to the right. The biggest problem with the way most people learn Vim is that people learn these things as “movement commands” rather than as nouns.

There are a couple of special nouns that I don’t see a lot of people using — f and t. f means “find the next occurrence” and t means “til the next occurrence” and both of them are applied to the next character you type. So typing f_ means “find the next underscore” (on the current line). t_ means “til the next underscore,” the cursor will stop on the character before the next underscore. (You can use F and T to search backward rather than forward.)

These are helpful for navigation, but they’re even more helpful when you’re constructing editing commands, because they can be used as a noun.

Now let’s talk verbs. The big three are y, d, and c. y is yank (copy). d is delete. c is change. Combining a noun and a verb applies the verb to the noun. That’s the essential grammar of a Vim command. cw changes the current word. c0 changes the text between the cursor and the beginning of the line. d$ deletes to the end of the line.

Let’s look at f a bit more deeply. Say you have a variable named my_integer_value and you want to change the name to my_string_value. If you move to the beginning of the name and type cw you’ll change the entire variable name. Instead you can type fi to move to the “i” in “integer”. Then type ct_ (change up to the next underscore) and the word “integer” will be deleted. You can then type in “string” instead.

Lastly there are modifiers. Modifiers change how nouns are understood. The two big ones are i (inside) and a (around). Here’s a simple example. If your cursor is in the middle of a word and you use the command cw it will change all the characters from the cursor position to the end of the word. If you type ciw it will change the entire word. You can also use paired characters as nouns with i. So to change the contents of quotation marks, you can type ci". Or to copy whatever is inside a pair of parentheses, you can type yi(. If you want to yank the parentheses themselves, you can use a instead — ya(.

This is just the tip of the iceberg, there’s a lot more. But once you know how to put these commands together, you’ll have a much easier time understanding the Vim tips you see online. Suddenly you’re expanding your vocabulary rather than learning a new language.

For example, once you understand the Vim as a language, you can get a lot out of Andrei Zmievski’s Vim for Programmers presentation, which is a whirlwind tour through PHP commands.

Vim is weird enough that it can seem like learning it is probably not worth the effort, but it’s an incredibly powerful tool in the right hands. The problem is that to even get started, you have to learn the difference between the various modes and how to switch between them. You also need to learn the basic methods for navigating through a document. If you’re used to a normal GUI editor, that can be really frustrating. Once you’ve mastered the basics, though, learning Vim’s grammar will really accelerate your efforts to make the most of it.

Thinking about resistance to learning new tools

The Washington Post’s Wonkblog has a depressing story about the inability to solve a seemingly straightforward problem with technology that will resonate with anyone who works in information technology. In this case, aid agencies are trying to get people in developing nations to stop using indoor cooking fires and use stoves that are safer and more energy efficient instead. Indoor cooking fires kill around two million people a year and are horribly inefficient. They produce emissions that cause global warming. Unfortunately, despite the best efforts of agencies that give away stoves and provide training to replace them, the long term effectiveness of their efforts is very low.

In software, I see this all the time. Many users are incredibly resistant to changing tools, even if mastering the new tool would greatly increase their quality of life. What I have also observed is that people compartmentalize their interest in trying new tools. Someone might resist upgrading Microsoft Office but constantly seek out the newest fishing tackle available. Or a designer might eagerly upgrade to the latest version of Photoshop but refuse to learn a few Unix shell commands that would make their life much easier.

I’d love to see a study that measures the correlation between a willingness pick up new tools and career growth. My belief is that a willingness to adapt to new tools is a key to remaining economically productive over the long term, unless you have a very highly specialized set of skills that remains in demand.

Older posts

© 2024 rc3.org

Theme by Anders NorenUp ↑