General Musing

blaze your trail

Posts Tagged ‘change

Today’s Noise, Tomorrow’s Dinosaur #programming #business

leave a comment »

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:

  1. Somebody suggests or codes a feature
  2. Feature is discussed on a mailing list and in chat
  3. Feature is attacked for obvious weaknesses
  4. Feature is tested and updated
  5. Feature is implemented in the alpha
  6. Feature breaks when combined with other updates or breaks other features
  7. Mails/articles are written for and against the change
  8. Patches are exchanged and evaluated
  9. Feature undergoes further testing
  10. Feature reaches the beta
  11. Discussions on the direction of the software
  12. Possibly a branch is created
  13. Feature is updated in next beta
  14. Discussions on the feature
  15. Articles are written about the new features in the next release
  16. Feature is released
  17. Articles are written about the new feature
  18. 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!

Written by Daniël W. Crompton (webhat)

January 16, 2011 at 9:23 am

Follow

Get every new post delivered to your Inbox.

Join 3,126 other followers

%d bloggers like this: