Most people would agree that gaining experience is vital to career development, and I’m sure most managers would content that their hiring decisions are, at least in part, driven by finding people with relevant experience to contribute to their team and their business.

But what is Experience?

Many in the IT industry seem to think that experience comes from the breadth of different technologies and industries in which one has worked - giving rise to the helter skelter nature of the IT jobs marked where you’re seen to be “somehow less” if you haven’t moved jobs every 18-24 months.

In conversation, others have brought up the cliche “Experience is what you get when you don’t get what you want”, focussing particularly on the idea that the greatest experience is gained from project failure.

I’m not convinced that the number of technologies or industry sectors is itself a worthwhile metric, though a breadth of engagements does have a certain value. Nor am I convinced that the only worthwhile lessons are learnt from failure - while the debris of a failure is a fertile source of lessons, project success can teach us much as well.

Experience is

Experience is gained when we grok (truly understand) the consequences of the decisions that have gone before.

They key of this definition is to observe the feedback loop. If the consequences of a decision are thoroughly understood, future decision making will be influenced for the better. If not, future decision making will be no better. It doesn’t matter whether the consequences are good or bad, if the reasons for the outcomes are understood, the quality of future decisions will be improved.

It’s in the minutiae of the day to day that the real consequences of a decision can be seen - and if the decision maker doesn’t experience these details, their knowledge cannot grow and their decision making cannot improve.

If you’re involved with a project or product from the very earliest days, through development and testing, past release and go live and into day to day operation, then you have a golden opportunity to learn the lessons from decisions past. Whether you made the original decisions or not, pay attention to what works and what doesn’t, for these are valuable experiences you can carry forward.

Conversely, fly-by-night consultants who dictate architecture without any involvement in actual development are dangerous simply because they remain ignorant of which of their decisions are bad and which are good. They are therefore free to repeat their bad decisions over and over again.

This is why the archetypal “non-coding architect” can be such a problem - because they don’t (won’t!) experience day to day consequences, the quality of their decisions is limited to their prior history, without much (if any) opportunity for improvement.


Experience is what you get when you learn from the consequences of past decisions.

Where you can, stay involved with a project so that the impact of your own decisions is revealed. Wherever you are, gain all the experience you can by paying attention to the impact of decisions made by others.


blog comments powered by Disqus
Next Post
NAntGraph Source on GitHub  26 Feb 2015
Prior Post
Slides for FSIS, The Authorised Biography  18 Oct 2014
Related Posts
Using Constructors  27 Feb 2023
An Inconvenient API  18 Feb 2023
Method Archetypes  11 Sep 2022
A bash puzzle, solved  02 Jul 2022
A bash puzzle  25 Jun 2022
Improve your troubleshooting by aggregating errors  11 Jun 2022
Improve your troubleshooting by wrapping errors  28 May 2022
Keep your promises  14 May 2022
When are you done?  18 Apr 2022
Fixing GitHub Authentication  28 Nov 2021
November 2014