On Experience

Today I'd like to share some thoughts on experience.

How do I define experience? What are we getting when we get "experience"? In software engineering, I think of it as building up a mental model of problem and its solution(s). It's building a big bank of lots of problems, their details and then what the specific solution was to those. With this bank, approaching new problems feels easier or even intuitive, as the new problem quickly matches (or at least resembles) a previous problem you've had, and the solution to start trying is the one that worked last time.

In the book Slumdog Millionaire, the main character Ram Mohammed Thomas wins 1 million rupees in a game show through answering 15 questions correctly. Whilst not a genius, its just his luck that the 15 questions line up with 15 experiences from his life. He experiences what most would assume is luck. However, an experienced software engineer, or any professional can feel just as lucky as they come to a problem they've seen before, and solve it swiftly.

So, how do we get there? How do we get lucky?

We often think of and talk about experience in terms of time. Typically in terms of paid, relevant work to one's profession. For example, if you graduated in 2010, have been working since and now its 2023, you've got 13 years of experience.

Measuring by time is objective and cannot be argued with. However, it, in my opinion, is the most naive measurement of experience. Comparing two job candidates, employees or colleagues by it is always a fool's errand. We all intuitively know that is a weak comparison at best. So... what other dimensions are there?

The Dimensions

Density

There's an old phrase - "Its not the years in your life, but the life in your years". I like the phrase. It feels right. I'm sure you'd agree. Perhaps you've had the experience of going to a funeral of an elderly person and they say comments like "they lived a full life, never a dull moment" and the implication is that they filled their years. We accept that a full life is a good one. Hence the phrase.

But I'd like to pinch it and modify it a bit. "Its not the years of experience, but the experience in your years". So this talks to the first dimension, density.

Density of experience matters. There is a notable difference between a developer who has had 10 years at a slow moving company vs a developer who has had 10 years at a faster moving company. They would have simply written more code, solved more problems, shipped more products. Their bank of experience will be bigger, because the work was denser.

Variety

The next dimension is variety. Similar to density, variety of experience can bring value in terms of problem solving. Developers might do this by changing tech stack, industries or companies. They might move from Mobile, to Web to Backend and all the way back again. They might move from start up to agency to corporate to small business. All the variety of problems increases your experience and when you come up against a new problem, the variety you have helps. In fact, I would go as to far as to say as changing jobs, tech stacks or industries would be the easiest way to keep your density high. Variety is a path to density, but not the only one.

Depth

The final dimension in my mental model of experience is depth. Going deep on a problem, is arguably a type of variety but it is a type not a whole lot of people get. When I say deep, I mean deep. Contributing to the framework or language you work with for example. It will take you on journeys that the hello world or the basic bread and butter coding tasks just simply won't. For example, a competent Ruby on Rails developer should be able to make a simple CRUD based server side application and be able to add new routes easily. However, have they understood what is Ruby and what is Rails? Have they contributed to either project? Have they ever made and distributed their own "gem" (a code module)? Going beyond the surface when it comes to software development is a great way to gain more experience that others won't have.

Now what?

So those are some dimensions of experience I believe exist: Density, Variety and Depth. However, these dimensions are incredibly hard to measure, so while you can't prove these aspects of your experience as trivially as time, they do show in day to day work, and so are important to work on.

So how do you get more experience in your years? I'm still figuring this one out myself, but here's some things that have worked for me. I would note that I got lucky, I did the following things in my career out of curiosity and passion, not some well devised plan to gain experience quickly, however, that's what's happened, and I'm so glad.

Changing Tech Stacks

My development career started with using Apple iWeb and tinkering with the exported HTML and CSS. From there, I started to tinker with iOS apps. I put a few on the store before leaving high school, and even did a short internship at an app development agency before university. During my university years, I used other languages as well, and during my internships I used C#.net. Leaving university, I went back to iOS again. That quickly turned into full stack. From there, back to iOS, this time, using Swift instead of Objective-C. From there, off to NodeJS land, which also saw me doing a bit of React. From there, contracting in mainly React. Now I'm back to the backend with Node JS. Seeing all these tech stacks, you start to see some patterns. How they do 3rd party module management, how they do debugging, what IDEs they use, etc. You see the similarities and you see the differences. It builds the bank in an interest way because you see what things in some platforms are inspired by others. For example, CocoaPods, an iOS package manager, is clearly very inspired by Ruby's Pods system. The person(s) who started CocoaPods used their variety of experience to make iOS development better or everyone. What an amazing legacy.

Changing Types of Company

My career has seen me at a few different companies. This sort of variety I was deliberate about. Some boxes I wanted to tick when first starting out was: agency, start up, big business. I'm proud and honoured so say I've ticked those boxes. I also included in there a small business and a multinational business. They're all different in the day to day, and there is lot off not-coding differences to them and you might think the company type is irrelevant to programming, however, the way you solve problems at these various companies is quite different. There are simply different constraints which force you to think, act and code differently. Your bank of experience builds up with the quick way to do something, to the good enough way to the rock-solid way. These experiences are all good to have.

Finding work off-backlog

Regardless of company type, most jobs are basically "here's a todo list, do it". Think Jira/agile. However, in some companies, particularly in slow moving ones, you find yourself blocked or simply not challenged or not busy enough. What I've done is always try to find way to add value to the business while getting some extra coding in. This could be almost anything, but some things that have worked for me are creating component systems, doing some refactoring, creating some internal tooling, creating to some internal code packages, creating coding templates, helping others with their work or doing proof of concepts into new technologies. All of these, if you can also do your 'day job' at the same time, can add density in an organisation that can otherwise not organize that density for you. In such organizations, your learning and growth is on you.

Conferences, Meetups, Talks, The Internet

A nice complement to work, if you have time for it (we don't all have such a privilege...), is using the many many resources out there in the world to build your bank of experiences up. You're doing it right now by reading this blog post. There's SO much out there to learn from. Get along to conferences, meetup or watch the talks online. YouTube has plenty of folks teaching, and hacker news and reddit have plenty to stories to share. In most of these resources, the author is trying to help you gain experience without doing the work they had to do. Its basically free experience. Will it be as good as doing it yourself? No. But its better than nothing.

In Summary

Its your job to get as much experience as you can as you proceed through your career. The more experience, the more success you will have. You need to be mindful when its being organised for you, or if you need to be hungry for it yourself. You need to be deliberate in collecting experiences and try to be efficient with the time you spend doing so. Good luck!