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.

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.

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.

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.

It begs the question, how does a company gain a competitive advantage these days? My argument would be that the most effective approach is to recruit and retain creative people, and to free them to do their best work. I think this is the real lesson for any business in the Valve employee handbook. Yes, I’m talking about it again.

Valve’s employee handbook is, as much as anything, a recruiting tool. It’s a promise that if you have good ideas, nobody at at the company is going to stand in your way. That’s a great pitch.

At Etsy, we find that the people who are the easiest to recruit are the ones who read the company’s engineering blog, Code as Craft, tried to apply things they learned at their own company, and eventually gave up and just looked for a job at Etsy instead.

Companies that put obstacles in the way of people solving problems find that the first rate employees look for other jobs, and that second rate employees devote their time to using Facebook rather than looking for ways to make things better.

The most effective way to gain a competitive advantage at a company is to create a culture where employees are free to use as much of their brain as they want to build value for the company.

People are justifiably outraged that the University of Florida is eliminating its computer science department. As Alex Tabarrok notes at Marginal Revolution, this is an example of how the institutional incentives for universities are not well aligned with what society most needs from those universities. This story is complicated. The state government is cutting funding for existing institutions even as it creates an entirely new polytechnic university carved out of the University of South Florida.

Cutting the computer science department will save the University of Florida $1.7 million. Many people have noted the size of university’s athletic budget, and that that budget went up by $2 million this year. The athletic budget, managed by the University Athletic Association (Inc.), is available online. UF’s athletic department is financially independent from the rest of the university and in fact pays the university for general services that it uses. So while it has a huge budget, it’s not as though Florida could cut athletics to save the computer science department.

Obviously we justifiably argue that it’s a shame that people care so much more about sports than they do about sustaining important academic programs. But you can’t say that UF is funding sports over computer science.

Did you read the Valve employee handbook? If not, you should. To catch you up, at Valve, the corporate structure is completely flat. They have no managers, and everyone decides what to work on for themselves. The handbook explains what is expected of Valve employees and how people should adapt to that corporate structure.I’m sure some people find it intriguing and others terrifying.

Succeeding at Valve depends on two things, the application of one’s judgement and influence. Employees use their judgement to decide where they can add the most value for Valve. They use their influence to recruit other people to help them build the things that they have decided are valuable. Find a problem to work on, convince other people to help you solve it. Nobody is empowered to order anybody to do anything.

What occurred to me after reading the Valve handbook is that you or I can work in the Valve style regardless of where we work. If you work anywhere but Valve, you probably have a manager and you may have people who you manage as well. Within the constraints of your job, though, you should be relying on judgement and influence rather than hierarchy in your work, just like a Valve employee does.

If, in your judgement, there’s something more valuable you could be working on, you should be convincing people (like your boss) that your time could be better spent working on that other thing. Just be sure that you’re open-minded enough to accept that your judgement could be mistaken. If you’re right, though, it ought to be easy to convince people that your time could be better spent on a more valuable project.

At the same time, rely on influence rather than authority to get the help you need to get your work done. People generally do better work if they believe in the project they’re working on, and the ability to recruit volunteers is a good sign that whatever you’re working on is worth doing. People sometimes mistake interesting for valuable, but it’s always better to work with enthusiastic volunteers than with people who are doing something just because someone told them to do it.

Obviously if you work on an oil rig or at Burger King, this approach may not work. However, the field I understand best is software development, and if you’re working on software, you should the Valve philosophy to heart. Use your judgement and influence to make sure you’re adding as much value as possible at your job. If that gets you into trouble, maybe it’s time to use your judgement and influence to land a job more suited to your talents.

We’ve heard that other companies have people allocate a percentage of their time to self-directed projects. At Valve, that percentage is 100.

Very much worth reading.

It’s a problem for start-ups as they grow and become a traditional business, because most businesses succeed through repetition, process and routine. But all of those things are designed for rote predictability. So we engineer our businesses to squash the role of serendipity inside their organizations. Even start-ups, when they get big, and they stop listening to your users, fall into a process of repetition.

I was struck by this explanation because today I also read Michael Abrash’s blog post on what it’s like to work at the game company Valve. It sounds like Valve is structured to cultivate serendipity in exactly the way Becker describes:

If most of the value is now in the initial creative act, there’s little benefit to traditional hierarchical organization that’s designed to deliver the same thing over and over, making only incremental changes over time. What matters is being first and bootstrapping your product into a positive feedback spiral with a constant stream of creative innovation. Hierarchical management doesn’t help with that, because it bottlenecks innovation through the people at the top of the hierarchy, and there’s no reason to expect that those people would be particularly creative about coming up with new products that are dramatically different from existing ones – quite the opposite, in fact. So Valve was designed as a company that would attract the sort of people capable of taking the initial creative step, leave them free to do creative work, and make them want to stay. Consequently, Valve has no formal management or hierarchy at all.

It’s brilliant when it works. I think that Becker is wrong, though, when he says that repetition, process, and routine are the enemies of serendipity. Building the wrong kinds of structures and processes have been responsible for crushing serendipity in many organizations, but the right kinds of processes (or if you prefer, habits) are necessary parts of maintaining the possibility for serendipity as a company grows.

For example, from an engineering standpoint, Etsy’s core practice is continuous deployment. Regardless of whatever else is going on, developers are always testing code, checking it in, and pushing it to production, many, many times a day. It’s that process that enables the company to continue to rapidly iterate even though the engineering team is growing. The process for pushing code is rigid and everyone follows it every single time they need to deploy something. It’s that process, though, that liberates people to be creative as individuals.

I’d be willing to bet that Valve has any number of processes or ingrained habits that serve the same purpose. People there obviously understand how to form teams without being told what to do. They have a common understanding of how Valve writes software that enables them to contribute to any project that the company is working on. Valve creates software that ships in big monolithic releases — engineers there clearly understand what’s expected at each phase of the project so that they can ship.

Of course, I’m responding to one short paragraph from the interview — I haven’t read the book. I think, though, that from a distance people look at creative companies like Valve or GitHub (which I plan on writing about some other time) and think mostly about the liberties people are allowed to take. My guess is that in large part, their success derives from the adherence to norms that are deeply embedded in the cultures of those organizations. Because the team members voluntarily adhere to those norms, they don’t stifle individual creativity.

If this sort of thing interests you, check out the book — Get Lucky.