Most people would agree that gaining experience is vital to career development, and I’m sure most managers would contend that their hiring decisions are, at least in part, driven by finding people with relevant experience to contribute to their team and their business.
What is Experience?
Many in the IT industry seem to think that experience comes from the breadth and variety of different technologies and industries in which one has worked - giving rise to the helter-skelter nature of the IT jobs market where you’re seen to be “somehow less” if you haven’t moved jobs every 12-18 months.
In conversation, others have brought up the cliché “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 learned from failure - while the debris of a failure is a fertile source of lessons, project success can teach us much as well.
I want to suggest that 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 every 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.
One very simple illustration of this: If a component is written without due consideration for telemetry, monitoring, and diagnostics, working out what’s going on when it stops working in production can be very difficult. If the developer who wrote the code isn’t the one who has to solve the production issues, the next component they write is likely to also lack the required telemetry, monitoring, and diagnostics.
(Aside: I’ve heard of developers installing Visual Studio onto production servers so they can debug the live system in an effort to work out why things fail. Don’t do this!)
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 decisions are bad and which are good. They are therefore free to make the same kinds of 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.
Another example of this is the stereotypical job-hopping software developer who never stays in one organization for more than a year or so. Sure, they experience a lot of different contexts, work with a wide variety of people and do a lot of things with a lot of technology stacks. But they never stay around to experience the consequences of their choices.
Experience is what you get when you learn from the consequences of past decisions. Where you can, stay involved with a project or a product so that the impact of your decisions is revealed.
Also remember that the mistakes of others can be very educational - wherever you are, gain all the experience you can by paying attention to the impact of decisions made by others.