The Nature of Experience

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.

But, 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 if we care to pay sufficient attention.

Here’s my definition: Experience is gained when we grok (when we truly understand) the full consequences of decisions that have gone before.

Key to this definition is observation of 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 (at best) 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 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 & 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 prone to making the same kinds of bad decisions over and over again. (This also applies to rockstar developers who single-handedly create v1 of a product and then move on to other projects, leaving other developers responsible for their messes.)

The archetypal “non-coding architect” is a source of many of these problems - because they don’t (won’t!) experience any of the day-to-day consequences of their edicts. Thus, the quality of their decisions is limited to their prior history, without much (if any) opportunity for improvement. I suspect this is why some non-coding architects are extremely successful in their early days, and much less so as the years pass.

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, and therefore tend to become dangerous to future projects because of they don’t realize the consequences of their decisions and actions.

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

Where you can, avoid the temptation to jump from project-to-project-to-project, or from company-to-company-to-company. Stay involved with the one project or product and support it in production for several releases so that the impact of past decisions is revealed. Once you’ve learned all you can from that system, then consider a move. This will take several years.

Fortunately, you don’t have to have made those bad decisions yourself, you can learn from other peoples mistakes just as you can learn from your own. Wherever you are, gain all the experience you can by paying attention to the impact of decisions made by others.