Below is an article originally written by Patrick Shields, Principal Software Engineer at PowerToFly Partner CircleCI, and published on March 3, 2020. Go to CircleCI's page on PowerToFly to see their open positions and learn more.

There's not a right or wrong career path for software engineers. Some find a natural niche as leaders and work into management positions where they end up leading teams and designing career paths for others. Conversely, some thrive and become leaders by developing their own paths as an individual contributor (IC). Pat Shields, CircleCI's chief architect, recently wrote about his experience growing as an individual contributor, including advice about how engineers on the IC route can succeed in their careers. We're reposting it here.

My first real job in programming started on July 5th, 2007, which means I have just over twelve years of experience as I write this. It's a lot more than nothing, but probably not much more than something. Ten years seems to be about the right amount of time to get good at something, though some amount of natural talent or sheer drive can make it go faster. But growth is not as simple as waiting it out and talent does not supersede the need for experience.

"Players get to that intermediate level where they can already play pretty good, and that's kind of a dangerous period because they tend to start playing only the things that they can play, rather than the things they can't." - Pat Metheny

In fifth grade, I went to a school where I was required to take a French class. I showed no particular aptitude or interest in the language, but was happy to pass through the lessons. After two years, my family moved and I started at a new school where I was able to choose Introductory French or Spanish. I chose French, effectively repeating the previous two years. I have little to no memory of these classes, but I believe I passed through them with ease. After those two years, we moved again and I started at a High School. I was offered a choice of languages to study and I elected for … a year of Introductory French. I was the star pupil of the class, having repeated "Je m'appelle Pat" and "Où est la discothèque" as required for the previous four years.

The following year I entered Intermediate French and the skill gap between myself and my peers immediately dwindled. Despite my five years of experience, I didn't advance much beyond a few simple phrases and a halfway decent accent. I muddled my way through the next two years, but squandered my experience and gave up learning the language after high school. Many of us make this same mistake in our careers. We optimize for a skillset that is easy to gain or stay within the confines of limited expertise. Quite a few folks just don't get the opportunities they need to grow. I have found a few strategies that have helped me grow, and I'd like to share them along with some ideas about how you might apply them.

Assume you are smart enough to understand

In my first job out of school, I worked with some of the most brilliant folks I've ever met. Most were affiliated with Yale via either its computer science department or its high performance computing lab. During my job interview, Nick Carriero asked me if I was familiar with Junit and I tried to pretend I knew what it was beyond a window in Eclipse. I was surrounded by very experienced, very educated, and very accomplished folks. The one benefit of this was learning that in those walls I would never, ever, be the smartest person in the room. To follow along alone was an accomplishment.

Those folks were much more than smart. They were mostly twice my age or more, had studied rigorously in academia or cut their teeth on hard industry problems, and all had a tremendous work ethic. I didn't have their innate talents or that experience, and I was in no danger of being able to do what they did. But that didn't mean I couldn't follow along and learn. So I tried to ask dumb questions and to restate things until I got them right. Being wrong or not knowing something hurt still, but it hurt a little less every time the light bulb finally went off.

Most of what you need to follow the work of those around you is just patience and curiosity. When you encounter things in your work that you don't understand, ask someone to help you figure it out. It could be a piece of code, a system design, or even a business concept like margin. You won't become a quick expert but you will gain a breadth of knowledge. More importantly, you'll learn how to ask questions and learn from those around you. Give yourself space to do good work

Real talk: everywhere you go there will be haunted forests, tech debt, and organizational challenges. Every opportunity comes with constraints. Often, those constraints lead us to choose the lesser of two evils or the best of a bad set of options. In my experience, it's easy to over-dramatize the evil or inherent bad-ness, but the point is that it feels bad. When you consistently do work that you don't take pride in, it's challenging to invest yourself in growth. Engineers in this situation often begin to imagine some panacea that would fix things. If only things were functionally pure or fully asynchronous or crash-only or written in Idris or Rust or actually Go would be preferable, then we could do things the right way. Or so the thinking goes. We convince ourselves that we are talented and great, if only we weren't limited by the things we cannot change.

Don't get stuck thinking that you can't do good work unless something you can't control changes. Find opportunities large or small to try to do something in a way that you are proud of. This can be as small as writing a few methods or functions that you think are great or running a larger project in an exemplary way. When I've done this, I've found that some of my great ideas were great and some were pretty sketchy. If I hadn't put them into action, I'd have missed the opportunity to figure out which ideas had merit.

Focus on the outcomes

As programmers, we spend most of our time living deep in the "how?" Programming is quite literally the process of filling in all the details. Many of us experience frustration in our jobs because we are forced to reckon with ambiguity that our coworkers and peers can shrug off. Earlier in my career, I used to say that there was nothing more terrifying than a meeting that ended in agreement because that just meant you hadn't figured out the details yet. That's a pessimistic extreme, but it's also a fear born out of experience.

By and large, the conferences we go to, the blog posts we read, and the conversations we have focus on the "how?" We talk about programming languages, databases, agile methodology, distributed systems papers, or GraphQL. But for most of us, those are tools to help us do something else. Our stakeholders don't care about the tools, they care about the outcomes. The earlier you are able to focus on outcomes, the more you'll be able to connect with your stakeholders, learn from them, and then help them succeed.

This is a huge topic and a never-ending quest, but you can start by always knowing the answer to the following three questions:

• What problems am I trying to solve for my stakeholders?
• How do I know when I'm done?
• How do I know if it solved the problem?

No matter what process you use, or don't, and no matter who your stakeholders are or how big your organization is, if you know the answers to those questions, they will guide towards a path that is focused on generating outcomes rather than just generating more details.

Do whatever you want, but do it loudly

I was a year or two out of school when I first heard the phrase "It is better to beg for forgiveness than ask for permission." It's an old phrase, sometimes attributed to Grace Hopper, but variations have circulated for many years. There are some organizations where creative thinking and empowerment are still frowned upon, but I think this quote misses the mark nowadays. It's still true that asking for permission will likely get you stuck in the mud. The receiver of your request will likely feel the need to do due diligence on the request before passing judgement and, well, it's not likely their top priority or they would've been asking you for the ideas. It's the request that slows things down, not the knowledge of the approach.

I've taken to using a variation of this phrase: "do whatever you want, but do it loudly." If you feel confident that you have a great idea and know how to complete it, go ahead, but first announce it to anyone who will listen. You want to avoid surprise and rumor. By keeping everyone abreast of your actions, you are giving them the knowledge they need to provide you with feedback and a mechanism to do it. I often provide a little space for feedback even, by saying "Unless I hear from you by the end of your day tomorrow, I'll be proceeding." I'm not asking you to vet the approach for me, but if you know I'm headed towards dragons, let me know.

Stay focused on growth

No matter what strategy you choose, as soon as you have the security to do so you should start thinking about your growth. "Where do you want to be in 5 years" is a great question, but sometimes it's impossibly difficult to answer. These strategies won't help you pick a direction, but they'll help you get the most out of wherever you are right now. If you find you can't use these strategies, either because you don't have enough support from your peers and management chain, or because the work model is so inherently broken, it's probably time to look for another opportunity when you are able. Along the way, be proud of your growth and what you've achieved, but don't give up on challenging yourself.