Anthony Panozzo's Blog

I think people should create a formal model of their knowledge portfolio and use this model to actively manage their knowledge and skill acquisition. This applies both to organizations and individuals. I could see this looking similar to the Thoughtworks technology radar. The skill model would have a list of skills and interests and how much knowledge one has in these. Experience could range from:

• hearing about something
• reading a book about it
• knowing a similar technology
• writing a Hello World program
• doing a small project in an area
• having years of experience doing something

I think there could also be a weighting as to how much the person feels like they know a particular area. Maybe they "read" a book but didn't feel like it really sunk in. Perhaps they don't know a particular technology, but have two good friends who are well versed in that technology and can help in a pinch or introduce them to people in that space. In this way, an overall view of what a person has done and may be capable of can be more easily assessed. Take for instance someone has not done much C# but has done a lot of Java development. By understanding that these technologies are similar, someone outside of the development field can understand that this person has a higher capability for C# than in, say, embedded development.

It seems like the most devastating career risk people face is getting stuck doing one thing for too long without branching out. As a result, they become unemployed or underemployed, doing work that is not challenging, poorly paid, or nearing obsolescence. To this end, I have a framework that I currently use to think about the next few years of career development and being proactive about learning. I think about it mostly from the software contracting and business consulting perspectives, although it could be applied to other disciplines. I think the big differentiator is how quickly the field changes and how much one feels a need to hedge their career options.

It's useful to note that all of the following stages are generally in play at any given time. If you focus only on the future, you might starve. If you focus only on the present, you might become short-sighted and hurt long term results. The idea is that one should have:

• a list of skills that have general value today,
• a list of skills that are becoming obsolete, and
• a list of skills that just might become very useful in the near future.

Essentially, it's skill diversification, much like people diversify stock holdings.

The Cash Cow

This is something that you are very good at and is currently in hot demand. It differs from a core competency because this is something that you can make money doing for the near foreseeable future. This is web programming (and others) in the late 1990s. This is probably Ruby (and others) today. It might be something else tomorrow. Hopefully you will have learned enough about tomorrow's cash cow in the second phase (small bets) to be good at it when it changes.

There are different kinds of cows. It could be that COBOL programming is the thing you are best at and can easily find a variety of work for. This would fit the criteria that I laid out. You might have some that are solid, and some that are getting to be less profitable.

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