Anthony Panozzo's Blog

If you have worked on Agile teams, I was wondering if I could get your help on a small project I am starting.

I am working with Jason Yip to better understand how people think about solving problems. Specifically we are interested in the differences between “experts” and less expert people in a methodology.

For this first step, we are looking to collect challenging Agile scenarios. These should be the hairiest, most difficult, most challenging Agile situations you’ve found yourself in. The preference is for scenarios that you have directly experienced yourself rather than hearsay or hypothetical scenarios. It’s not important whether you were successful in meeting the challenge; it might even be better if the scenario is one where you failed. We’ll then pose these scenarios to different people and see how they think about solving the problem.

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.

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”.

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!

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?