Anthony Panozzo's Blog

I've been using Vim for about a year now, and am pretty much addicted. Once I reached a certain level of proficiency, no other editor seems to be even close. The keys are very intuitive to me now, as is modal editing.

Of course, there is a problem when I have to type in other programs. For example, in OpenOffice, I routinely hit j a few times, and am surprised when that letter actually pops into the screen instead of moving the cursor around.

To overcome this, I've been messing around with ways to make Vim more friendly to general writing. Here's what I've done or found:

Autocorrect

This section outlines my major actual contribution. The rest are just tips. Autocorrect is a key feature of almost any word processing program, and it's tough to do by default in vim. When you type 'teh' and then have to go back and fix it, you are much less efficient. Vim has the concept of abbreviations, where you can map one word to another.

Title: Tribes: We Need You to Lead Us Author: Seth Godin Published: October 2008 Length: 160 pages, or 3:40 spoken

"A tribe is a group of people connected to one another, connected to a leader, and connected to an idea."

This book is self-described by Seth as a book that was supposed to be about leadership that happens to have a lot of marketing information, or a book about marketing that happens to have a lot of leadership information. The main point is that with the advent of tools to facilitate interactions between groups of people with common interests, being a leader is easier but even more important than ever. Tribes can be smaller and more precise because geographical limitations are mostly gone now. Apart from others' need for leaders, being a leader increases your happiness because you are in control of your destiny and are constantly challenging yourself. Seth makes an even bigger point: we need YOU to be a leader, and there are huge benefits to be gained from doing this. Sometimes the going can be tough, but if everyone were doing it, then it wouldn't be worth as much when someone provided true leadership. Godin emphasizes creating a movemen and working with it to allow it to thrive.

Most charity events take manual labor, so maybe you had an excuse before. But "IndyGiveCamp Charity Challenge Weekend 2009 is an initiative designed to allow developers, designers, DBAs and web enthusiasts to donate their time and talent to developing applications for charities." Hey, charities need software too!

You list your proficiencies, and are paired up with other developers (optionally of your choosing) and you work on a project for the weekend. With a schedule like this, you can be sure that you will be challenged. Heck, they say that "copious amounts of caffeine will be provided." Don't worry, you don't have to participate the whole weekend. It happens on January 23-25, 2009, which comes sooner than you'd think due to the holidays and whatnot.

Title: Getting to YES: Negotiating Agreement Without Giving In Authors: Roger Fisher, William Ury, Bruce M. Patton Published: 1991 Length: 200 pages

I highly recommend this book to anyone who has to negotiate with others. So basically – everyone. On a daily basis, you probably negotiate with your spouse, coworkers, landlords, potential employers, business owners, labor unions, and foreign governments. This book explains several principles of negotiation that are applicable to all of these relationships.

One of the concepts of lean software engineering is limiting work in progress (WIP). If you have a team of, say, ten developers, it is better to have only three or four scenarios in active development that the team is working on than having each person work on their own scenario. What's more, each developer should have only one active task at any given time. This could be a development task, reviewing a specific set of changes, or recycling review changes. This greatly helps focus the developer and ensure that context switching does not contribute to lost time and lower quality. When you are focused on one thing, you not only work faster, but you actually complete the task instead of leaving certain details for later that you might eventually forget about. Plus, it's nice to get a feeling of finishing the task.

One extremely positive effect that I saw with using this approach is that reviews become a lot easier. Let's say that I take the old approach where everyone works on a huge monolithic task and then checks things in when they feel like it. Three developers might check things in before I get my changes incorporated, and if they changed files that I was working in, the reviewer of my code might see much more than just the changes that I have made. What's more, by overloading the reviewer with the huge amount of code checked in as well as potential other changes, it's more likely that the reviewer will miss something. The review will take longer, so when it comes back to me, it might be fuzzy in my mind.