Here's the secret: More Problems, More Experience

Here's one thing that I've observed in my time as a career software engineer: There's no shortcut to experience. You have to put in the time. That said, there are things that you can do to ensure that your time is contributing effectively to your well of experience and that's what we're going to talk about here.

Where does experience come from?

Some people seem to think that you can only get experience incrementally over time. That it's just something mysterious that comes to you over the course of working at Company X for Y number of years. These same people mistakenly turn down talented engineers because they lack "experience." But as much as time and experience are correlated, time does not tell you how experienced an engineer is, nor how well they will perform in a specific engineering role.

"Technical Experience" comes from experiencing different situations and then learning from those experiences to improve your own response to the same or similar situations in the future. Another way to say "situations" is "problems." Engineers who make the most of their "experience time investment" are the ones who intentionally expose themselves to various software related problems and then work hard to overcome or find/build solutions to those problems.

So when you're looking to increase your own level of technical experience (and increase the return on your time investment), look for "problems."

Where can you find problems?

It depends on the kind of experience you're looking for, but I can tell you a few places I've found the problems that have given me the experience I have had: Work and Open Source. There is a never-ending, ever-growing list of software problems at most companies (certainly any company I would want to work for), and the open source community is facing software problems that you can pitch in and find solutions to.

And I'm not talking about: "Hey, I'm having trouble triaging my GitHub issues, could you build me an app to solve that problem?" While this is a great kind of problem to solve, and would definitely give you experience, I'm talking about lower-level kinds of problems. Like: "There's some bug in this library" or "this test is flakey" or "when we deploy our app, we get a spike of 500 errors." These kinds of problems are all over the place and require some deep digging into the code to figure out what's going on.

Another thing you can do is be the go-to person for problems of a certain domain that you want to improve on. You want to be the "accessibility expert" at your organization? Do some research, and give a talk internally at your company. Invite people to ping you with questions. The more questions you get about the topic, the more varied problems you'll be exposed to, and the more digging you'll have to do. It's a cycle.

This is kinda what happened to me with testing. I actually never intended on being "the testing guy," but I developed a few experience-based opinions, started talking about it. It wasn't long before I didn't have to look for problems, they just came to me in the form of questions. People brought their problems to me which made me even more experienced, and with that experience, I was able to build TestingJavaScript.com which encompasses all of the knowledge that I've gained over the years of experiencing problems–my own and other people's.

How do you use problems to gain experience?

One of the first libraries that I worked on was angular-formly and I got into it because there was a feature that didn't exist that I needed. I could have passively moved on to another library to retrofit its capabilities to my app (or vice versa 😬). Instead I looked through the code to see that what I wanted was possible, then opened an issue, followed by a pull request. A few months and PRs later, and I found myself a core maintainer, and then later the sole maintainer of the project. That whole project presented a TON of "experience-building problems" for me (as well as opportunities to speak internationally). I learned a TON about how forms work on the web and as a maintainer of the project.

When you find a problem. DIG. If you have problems digging, then awesome! You found another problem to solve! You can work to solve those problems. The whole process will give you more experience. Read "Spelunking in node_modules 👷" for more thoughts on this kind of process.

Another thing: document your findings. You'll learn and remember more by writing down the things that you learned. It's even better if you present your learnings in a form intended for public consumption (blog post, youtube video, etc). This will require you to dig even further to confirm (or debunk) your assumptions, giving you more experience.

Conclusion

To sum this up, you develop more experience as you bump against and solve varied problems. Your brain is a muscle and it gets better at solving similar problems the more it's exercised in a certain way.

I hope this helps you develop into the experienced engineer you'd like to be. Good luck!