I remember being just a few years into my software engineering career. I could build and figure out a lot of stuff. I had no trouble diving into an unfamiliar codebase or unfamiliar programming language and quickly ramping up enough to get what I needed to do done. By all accounts of the people I worked with, I was a fast learner and excellent at figuring things out and getting things done.
But for the life of me, I couldn’t figure out how I would get from where I was to the type of work I saw the most seasoned engineers on my team doing. They were designing systems from scratch, rolling out massive system-wide changes, and building standalone libraries and open-sourcing them.
It felt like I was on the other side of a chasm, with no bridge to the other side, and no guidance on how I would ever get over there.
Looking back on the fourteen years of my career in tech so far, I can see how those planks came together step-by-step to build a bridge, though not necessarily to where I thought it would lead.
Here’s a little bit of what my early career path looked like:
Step by step
I followed my natural impulses and where my interest led me — cleanup and refactoring. At the time, this seemed not at all related to bridging that gap to building new systems. But, I refactored inconsistencies when I saw them. I left things better than I found them.
Then I started to notice which patterns of code were easier to understand, and codified usage for the team going forward.
As I started building larger features and taking on more substantial projects, I recognized how the underlying systems needed to be modified or built out to support the new functionality.
As I started taking on larger and larger projects, what I still thought of as refactoring became critical platform work — work that enabled our whole team to build out important product features more quickly.
As I stepped into leadership, I learned to expand my own impact beyond my own individual contributor work (something I hadn’t even thought about earlier in my career).
Instead of refactoring and cleaning up code on my own, I expanded my impact by bringing others along on my love of code-deletion. I started coaching engineers on the team and helping them get unstuck. I started coordinating the work of multiple engineers in tech lead roles.
At each step, I built experience and credibility that allowed me to recognize and take the next step.
Here are a few of the lessons I learned in the early years of my software engineering career:
Progress is happening, even if you don’t see it.
As an early career engineer (or early stage anything, really), it’s easy to feel impatient and want to jump straight to the part where you’re an expert. But trust the process. Even when you think no progress is being made, you’re putting in the hours — you’re chipping away at those 10,000 hours required to build expertise. Early on, just logging the hours is important — don’t overthink how exactly each project is leading to where you want to go.
When you’re in it, it can feel like nothing is happening. Progress can be hard to see clearly if you don’t zoom out.
As a manager, one way I’ve helped early career engineers realize how much progress they’ve made is by pointing out what kind of work they were doing a year ago. Usually it’s a pretty big leap from something like needing a lot of guidance fixing bugs or building small features, all the way to driving and building out much larger projects.
Speak up for what you want
BUT if you get to the point where you feel like your learning has plateaued, and you want to be doing certain types of work, don’t be afraid to speak up for what you want. For me, it was super frustrating when I realized that everyone around me was getting leadership opportunities, and I felt overlooked.
I spent a lot of timing waiting for my individual contributor contributions to be recognized, for someone to say “Wow Jean, I’ve been observing your work for quite some time, and since you’re so good and reliable at shipping code, I think you’d be great at this leadership role.”
Looking back, I realize no one knew more about what I wanted and what I was doing than me, and no one had the time to really observe the progression of my work that closely — not through malice or poor management, just the reality of many priorities competing for attention.
Once I started sharing with people what I was interested in doing more or less of, it kept me top of mind when opportunities came up. Also, just starting to do stuff without waiting for someone to give me permission also worked well.
Also, don’t be afraid to leave a company if it’s not a good fit anymore — staying at one company or team for too long as a new grad can result in the perception that you’re junior, when you’re actually not (maybe more about this in another post).
Don’t get too attached to the end state
I thought the end state was staff-level engineer. I didn’t have any aspirations for engineering management or executive roles. Who knew my path would take me into engineering management, leadership coaching, running a leadership development company, and now as a VP of Engineering at a startup!
I remember a conversation with a coach who asked me if I felt like I was more on a CTO or VPE track, and I honestly responded that I had no idea, because I didn’t know what either of those roles did and what those tracks looked like.
Had I completely planned and stuck to a goal (like climbing the ladder to staff engineer at Google), who knows how many opportunities I wouldn’t have noticed or taken.
A bridge is probably a poor metaphor to use, because it’s something you need to plan out completely beforehand before you start to build. It’s ok to take it one step at a time.
You don’t have to figure it all out!
I spoke to an early career engineer recently who was overwhelmed with feeling like she had to figure it all out — did she want to go into management or be an IC? Did she want to go into Product? Or found a business? The options can be paralyzing.
This may feel like advice from an old person, but if you don’t have a clear path forward, there is really no way to go wrong with building up a foundation of software engineering skills, and weighing your options then. There are SO many options available to you after a few years in an individual contributing engineering role at a known company — you can move into product, you can try your hand at founding something, you can join a startup, you can be one of the countless flavors of engineering leader. Unless you really want to, you certainly won’t be coding all day every day until you retire.
You can also join a startup earlier, but because larger companies have to onboard and train engineers at scale, they’ll have more robust infrastructure to train you up (onboarding programs, style guides, rigorous code review processes, etc). After a few years (even a year or two), you’ll have so much more information on what you enjoy, a broader network for opportunities, and experience that you can point to.
If this has been helpful, or if there are certain questions you have, or your own experiences you want to share, let me know!
Things I’ve been enjoying
Easily assemble-able meals - after cooking a lot the last few years, I’m experimenting with spending less time on cooking, and buying more ingredients that are easy to throw together for a meal, like salad greens, grilled chicken or smoked salmon, boiled eggs, etc.
Find Your Unicorn Space - from the same author as Fair Play, Find Your Unicorn Space is about re-claiming your creative life in a too-busy world.
Crocheting stuffies - While reading the Unicorn Space book, I followed an impulse to buy an amigurumi (small crochet stuffies) pattern book. My grandmother taught me to crochet when I was a kid, but I haven’t done much of it since. So far, I’ve made a small octopus, a jellyfish, and a small egg. It was actually thinking about Unicorn Space and crocheting that made me remember my early career, and how following small impulses like refactoring code can eventually lead to big changes over time. For now, I will enjoy making more stuffies, and we’ll see where it goes!
What advice would you give your 22 year-old self (or younger self if you’re not yet 22)? And what advice would you give an early career engineer? Let me know, and I can aggregate responses to share with you all.
Take care,
Jean
Hey Jean! Thanks for your blog post. I found it super inspiring. You inspired me to write the 5 things I'd like to tell my 22-year old self.
1.- Contrary to popular belief, (and this is one of my most contrarian opinions,) you're paid for your time, not for your results. When working, you're expected to work, not to be on IG.
Imagine 2 persons. You assign both the same project. One of them spends 2h working on it, slacks off for 6h, and delivers it by the end of the day. The other person spends 12h working on the same project (8h + 4h the next day), and ships some thoughtfully written code, though by all means they could have written it faster. Which of the 2 would you prefer working with? I'd pick the 2nd one, for they're in. The 1st probably thinks that they're smarter than everyone else, and in due time they'll use their time to practice Leetcode.
However, in time you'll realize that work != writing code. Reading, discussing, thinking, all that is work.
Besides, if you worked when you were expected to, you'll be able to relax when you're expected not to be working.
2.- Learn to pick your battles. At the beginning of your career, your battles are picked for you (most oftenly by your manager). But a point will come where you'll realize that you're better suited to pick your own battles than your mgr is, and you'll start experiencing a lot of autonomy. On the same line, autonomy is not something that is given to you by someone else, but something that you claim for yourself.
3.- Have grit. Things can get boring / unexciting at times but that doesn't mean you're not progressing –i.e. what you just wrote about in your post.
4.- There's more work than you can fathom so don't sweat too much over it. It's a never-ending stream of work you so ought to find your "marathon pace". However, you do need to know how/when to sprint - when to pull the proverbial all nighter and meet the shipping date - it's a skill.
5.- Be passionate; enjoying your work doesn't necessarily mean "having fun relaxedly" - it's enjoyable to be passionate –and maybe even a bit opinionated–.
Thanks Jean. It was nice to read about your journey and retrospective perspective. While not an engineer, I relate to your lessons learned. With the letting go of the outcome, I'd add -don't take your career choices so seriously. Circumstances change, opportunities arise and pass, if you are clear on where you want to go, you'll end up near there. Also, find a mentor. Mentors, despite popular belief, aren't always in one's org/company. Look around your network and find people whose philosophies, being, and work you respect.