Posts Tagged ‘change’
I was inspired by Driving Technical Change to write this. Please read the following for context:
Expertise, even for the very experienced, is a fluid thing. With the exception of abandoned technology, every tool, technique, or product that you are trying to push is changing everyday. The producers are adding more features. The community is posting more commentary. Users discover bugs, and product teams fix them. Nothing is static. Therefore, even the most expert of experts is only as good as the last thing they read. There is no standing still as an expert. And yesterday’s expert is tomorrow’s dinosaur after as little as two years of not keeping up.
I think this is a sweeping generalization which I believe is wrong, and I know is wrong for me. I regularly go on sabbatical for 3-6 months where I don’t or hardy use a computer, with hardly I mean I checked my mail once after 3 months. In this time due to the fact that I’m traveling I don’t read computer books or magazines. Coming back after this time I notice one important thing, nothing has changed except the version numbers. New features have been added to old software, new design patterns have been thought up and new frameworks have been created, whole sections of the linux kernel have been rewritten. And with in a week I am at my expertise level, and a week later I have covered most of the important things I’ve missed.
People who follow changes live are often stuck in the noise of the present, which for an expert a timeline can often look like this:
- Somebody suggests or codes a feature
- Feature is discussed on a mailing list and in chat
- Feature is attacked for obvious weaknesses
- Feature is tested and updated
- Feature is implemented in the alpha
- Feature breaks when combined with other updates or breaks other features
- Mails/articles are written for and against the change
- Patches are exchanged and evaluated
- Feature undergoes further testing
- Feature reaches the beta
- Discussions on the direction of the software
- Possibly a branch is created
- Feature is updated in next beta
- Discussions on the feature
- Articles are written about the new features in the next release
- Feature is released
- Articles are written about the new feature
- Revisions of books on the software or framework are written which include the new feature
This can take anywhere up to 6 months for larger features or changes to large frameworks. Following the noise allows you to adapt to the change over a longer period of time, and allows you to experiment more with the feature. This same result can be reached by reading the articles which are published round the time the feature is live, with the exception of the generated noise. One of the advantages is that this noise can be used for reference material, when the noise is of good quality. And this example covers only one feature for one software package or framework.
Being caught up in the daily noise also has a bigger problem. In some cases I may not be a direct contributor to a software package or framework and this noise can reduce the time that I can spend learning other things from the new books or articles which cover the other areas in which I consider myself an expert.
Something which is also neglected in the statement above is that experts have often been their and seen that. CVS works similar to SVN, which with a context shift works similar to Git. Each solving a different problem, and with the knowledge of the problem being solved it is easy to apply previously learned unrelated knowledge to new software or a new framework.
A great book!