How many times have you said: “Oh yeah, I forgot about that requirement…” or “I think we talked about that a couple of weeks ago, but nobody added it to the project tracker?”

Here are some indicators that there is work that you need to do that is not captured in your current project management system. They should work well with almost any agile project management system. It’s a good way of finding and capturing latent stories for people on the project to see.

Patterns to watch for

“We need to revisit this in October.” or “We should probably do this at some point.”

Create a story for this item. Regardless of when you revisit the item, it’s nice to visualize the work that you believe you should do at some point. This can be effectively prioritized against the other work. You capture that you have something to do and can plan around it. This is useful in capturing work expansion as it happens.

“This isn’t perfect, but it works for now.”

Add a task to refine whatever the item is. I’m a big fan of progressive enhancement for stories. Get the basic thing done, and then you can add polish later.

“Hmm, that’s a bug, but I don’t want to fix it right now since I’m trying to finish something else.”

You can quickly add this. Put a quick description of where you were, what you did, what you saw and what you expected to see instead. If you want, speculate on what might have caused the problem. Then you can move on knowing it will be taken care of soon.

“I have this crazy idea that I haven’t discussed with the team”

Don’t add this as a story, yet. You’re only cluttering up the backlog, making it less valuable. First discuss it with the team, and if it is something that you plan on getting to soon, you can add it.

A long discussion in the group chat room or an important email

If there are things that pertain to the story that you are working on or will be working on, copy and paste the direct text or a public link to the text that is relevant. If there are other documents or relevant images, link these as well. Especially with the chat room, you are already having these conversations and making decisions, so you might as well put these somewhere so that everyone will see the conversation when in the right context. No need to have the same conversation twice or need to hunt through a long series of emails to get to the relevant information.

Other thoughts

I think that this technique should be coupled with good backlog management to ensure that the highest priority items are being done and obsolete stories are being culled. If your backlog is too big, you will waste time and energy just managing it. Consider trimming it aggressively. Any truly important things will keep coming back.

I find that cultivating this practice ensures that the team communicates well and everyone knows about how much important work remains to be done. There’s much less “oh yeah, I forgot to include you on that conversation.” It makes the ephemeral more concrete, and leads to people trusting that what is in the system is very close to what actually needs to be done.

When do you add something to your list of things to do? When do you wait to add something?

I searched for “vim directory structure” many times online and have rarely found something that helps me out. Generally I’m looking for the right place to put some random .vim file that I downloaded or which directory to put indentation or file type recognizer files.

To compile this information, I basically looked through the directories that I had on my machine and read through (and copied portions of) the README files. I looked around at the files when things weren’t clear. This was informal and my understanding less than 100% clear, so if you see errors or where I can be clearer, please leave a comment at the bottom of the post.

This whole process is made significantly easier and potentially obviated by using a vim bundler like pathogen. This is because these tools allow you to work with cloned git repositories and they already have the structure correctly set up.

The install directory

Directories in /usr/share/vim/vim72 (/usr/share/vim/vim73 if you’re on the cutting edge, C:\Program Files\vim72 if you like pain) are the files that are installed by Vim. You generally should not modify these files or add files in here. It’s better to put changes or new files in a separate directory that you can more easily control (maybe even with version control.)

Anyway, here are the folders that are installed by default.

autoload

The autoload directory is for standard Vim autoload scripts.

These are functions used by plugins and for general use. They will be loaded automatically when the function is invoked. See “:help autoload”.

colors

These files are used to get different colors by using the “:colorscheme” command.

compiler

This directory contains Vim scripts to be used with a specific compiler. They are used with the “:compiler” command. These scripts usually set options, for example ‘errorformat’. See “:help write-compiler-plugin”.

ftplugin

The ftplugin directory is for Vim plugin scripts that are only used for a specific filetype.

All files ending in .vim in this directory and subdirectories will be sourced by Vim when it detects the filetype that matches the name of the file or subdirectory.

For example, these are all loaded for the “c” filetype:

    c.vim
    c_extra.vim
    c/settings.vim

Note that the “_” in “c_extra.vim” is required to separate the filetype name from the following arbitrary name.

The filetype plugins are only loaded when the “:filetype plugin” command has been used.

The default filetype plugin files contain settings that 95% of the users will want to use. They do not contain personal preferences, like the value of 'shiftwidth’.

If you want to do additional settings, or overrule the default filetype plugin, you can create your own plugin file. See “:help ftplugin” in Vim.

indent

This directory contains files to automatically compute the indent for a type of file.

If you want to add your own indent file for your personal use, read the docs at “:help indent-expression”.

Note: If you want to make an indent file, it should be named for the filetype that you want, not the extension. For example, if you want to change your Javascript indentation, your file should be named javascript.vim, not js.vim.

keymap

Keymap files for Vim

One of these files is loaded when the 'keymap’ option is set.

The name of the file consists of these parts:

    {language}[-{layout}][_{encoding}].vim

The format of the keymap lines below “loadkeymap” is explained in the Vim help files, see “:help keymap-file-format”.

lang

Language files for Vim

More information in the on-line help:

    :help multilang-menus
    :help :menutrans
    :help 'langmenu'
    :help :language

macros

The macros in the maze, hanoi and urm directories can be used to test Vim for vi compatibility. The life macros can be used for performance comparisons.

hanoi Macros that solve the tower of hanoi problem. life Macros that run Conway’s game of life. maze Macros that solve a maze (amazing!). urm Macros that simulate a simple computer: “Universal Register Machine”

The other files contain some handy utilities. They also serve as examples for how to use Vi and Vim functionality.

dvorak                  for when you use a Dvorak keyboard

justify.vim             user function for justifying text

matchit.vim + matchit.txt  make % match if-fi, HTML tags, and much more

less.sh + less.vim      make Vim work like less (or more)

shellmenu.vim           menus for editing shell scripts in the GUI version

swapmous.vim            swap left and right mouse buttons

editexisting.vim        when editing a file that is already edited with
                        another Vim instance

This one is only for Unix. It can be found in the extra archive:

file_select.vim         macros that make a handy file selector

plugin

The plugin directory is for standard Vim plugin scripts.

All files here ending in .vim will be sourced by Vim when it starts up. Look in the files for hints on how they can be disabled without deleting them.

syntax

This directory contains Vim scripts for syntax highlighting.

tools

Some tools that can be used with Vim:

blink.c:        C program to make the cursor blink in an xterm.
...
vimspell.*:     Shell script for highlighting spelling mistakes.
...

tutor

tutor contains the hands-on tutorial for new users

The custom configuration directory

Next, we have our custom configuration directory, commonly located at ~/.vim. This contains all of our personal modifications so we don’t mess with the default configuration. From what I can tell, you can put any directory that matches the names in the install directory, and the files within will behave as if you had dropped them in the installation directory. Again, you can do this to override the default behavior without messing anything up so you can easily take your changes to other machines. For an example of what my ~/.vim directory looks like, check it out. I’ve generally tried to stick to the conventions that are laid out on this page.

The .vimrc files

They load in a certain order. You can see the approximate order and some guidelines by invoking:

:h startup

Also, if you run vim from the command-line with a verbose flag, you can see what the order of files being loaded is. Generally I would split out the graphical vim-specific configuration into a .gvimrc file, and have the rest of my configuration in a standard .vimrc file. This is so settings that only pertain to graphical vim versions don’t give you a bunch of error messages. In the same way, some color schemes don’t look very good in command-line vim, so this is a way to ensure that you have a good look for these versions.

A new site called ohours has set up a web app that handles appointments for creating office hours. I’m generally interested in catching up with old friends and meeting new people, so figured I’d give it a spin.

Here is my ohours profile. You can subscribe to be alerted when I post a new office hours session. I set up a few hour block of time and a location, and you can schedule a meeting within this time period. I figure that there’s little potential downside (as I could work at the place in the event that no one shows up), but potentially much higher upside. I always learn something new when talking with someone, so this should be a great use of time. When’s the next one? A couple days from now. Sign up now!

If you have any questions about a project that you’re working on, something that you would like to do in the future, or thoughts on life, I’d be glad to talk about it.

Questions for you

What reservations do you have about doing something like this? Do mornings work, or would dinner or late night meetings be better? What side of town would work best for you? Is half an hour good and then extending it if there are openings? Do you want to meet with the other people there too? It would be nice to get in a good cadence so that I could regularly schedule meetings, but I could see switching up times and locations to be conducive to meeting with people. Right now I’m focused around northwest and northside Indy since it is the most convenient for me to go to, but I could see having one downtown as well. Thanks!

Apparently it’s tough to find good technical cofounders and early stage employees for your company, at least based on recent blog posts. I thought I’d post a bunch of those links to discuss some of the main points people have been making. Here’s my summary of the posts below.

My thoughts

The key consideration in my mind is something along the lines of BATNA (best alternative to a negotiated agreement.) This concept applies to many business situations. In order to effectively negotiate with someone, you need to realize your next best alternative to negotiating. Perhaps your company is in good shape, and the deal would only be slightly beneficial. This puts you in a better negotiating position because you know that you can walk away from the deal without worrying. If your best alternative is your company going under, you are more likely to try to make the deal, even if it is at a slight disadvantage to you.

How does this apply to technical cofounders? Simple. They have a lot of alternatives to joining your early-stage company. They could do lucrative consulting or contracting. They could be working for better equity stakes at other companies. They might want to start their own company instead. Hmm, 5% equity at your company or 100% equity at their own company? Why would they work for a split of equity when they could be bringing down cash money for contracting, regardless of the success of the eventual product?

The meaning of this is that the company that an entrepreneurially minded developer joins needs to be pretty darn good. If you’re looking to recruit/enlist others to an idea with no product or no traction, it starts with you. Learn how to do as much as possible, and show that you can hustle. Learn how to code to throw a prototype together, and if you don’t do that, learn how to do some wireframes or at least talk with engineers. There are many tools out there that will get you most of the way, and you should gain experience using them so you can bust them out whenever necessary to get your startup moving along. You should know that people who know how to code Ruby on Rails probably have done some database work–be active in the local entrepreneur circles as well as the local tech circles to start getting your bearings.

Why should business cofounders in the technology industry understand tech well? Well, take it from Paul Graham:

In a technology startup, which most startups are, the founders should include technical people. During the Internet Bubble there were a number of startups founded by business people who then went looking for hackers to create their product for them. This doesn’t work well. Business people are bad at deciding what to do with technology, because they don’t know what the options are, or which kinds of problems are hard and which are easy. And when business people try to hire hackers, they can’t tell which ones are good. Even other hackers have a hard time doing that. For business people it’s roulette.

Paul Graham, in 2005

The other main point is to demonstrate that you have some hustle. Do you have a record of being able to raise money? Do you have contacts in the industry you are interested in working in? Perhaps something else that the tech cofounder doesn’t already have or is not interested in. And so forth.

The posts

Andrew Chen’s post

Seth’s blog post about this

An IndyStartup post about this general topic

A good Hacker News post that a business-minded guy put out there. This is the example of how to do it right (hustle, knowledge, and social proof in the comments to boot.)

Interesting series on becoming your own tech cofounder

What if 1000 entrepreneurs learned to code just a little instead of lamenting the lack of engineers?

An interesting flowchart of tech cofounder equity. Potentially the most suited to the engineering mind. :)

Excellent piece on how to evaluate any company in its early stages, from a developer’s perspective generally. Get in their shoes!

Survey of actual developers. Again, this is pure gold if you want to understand what technical cofounders or early stage employees are thinking about and motivated by. How they look at potential companies and the “biz guys”.

Beating a dead horse by now, but another post about working for free and what developers look for in a business cofounder.

Last one! :)

What are your thoughts on this? Post a comment below, and thanks for reading!

I searched online but found little help on this quickly, so figured I’d post what I found under a good name.

If you want more than one CSS class when using a Rails helper, use the format:

  <%= f.label :method, :class => ['class1', 'class2'] %>

If you only have one CSS class that you want to use, you can use the more basic form as well:

  <%= f.label :method, :class => 'class1' %>