This occurred to me at work today
I was working on a task for which I completed coding and and testing. I showed the code to some of our Staff engineer after standup. The first thing he asked me is why is this fix working. I did try to understand how my fix is working. However after I discussed this with him it was clear that my understanding was superficial. Apart from that, the fix I made even though it works in the current version might break if the library version is upgraded coz I am depending on some internal behavior.
Considering that I have 10 years of experience it felt very disappointing that I could not think of this on my own.
Any advice?
First, don't pivot on this too much if it's an infrequent situation. Everybody has times when they don't get something right, or miss something obvious.
That said, if you find that this is a pattern, it's a positive sign that you noticed. This sort of self-awareness and reflection are a key to growth.
A lot of becoming a more senior engineer is about getting closer and closer to first-principles thinking. Growth over time looks like this:
A lot of levels 2 & 3 fail when people don't try to recenter around first-principles thinking. Instead of thinking broadly about satisfying goals using a wide aperture of possible solutions, we often instead hone in on one or two "obvious" ways to do what we want. Failures at level 3 are most catastrophic: I've seen teams of more than a hundred engineers working on a product for several years before the entire premise of the product came into question; it turned out that the product should never have been built, that the market never needed it.
BTW, have you potentially already posed this question to the staff engineer that you consulted? Getting his take on this (e.g. "What methods do you use to assess technical solutions such that you so easily saw what I missed?") might be a great concrete way to start.
I’ve been reading the StaffEng stories. It’s very interesting and you can get a lot of insights around how they think and operate
I would treat this as a learning experience - As Philip mentioned, you're already off to a great start by having this self-awareness and retrospecting on + sharing this moment!
It's easier said than done of course, but my general mindset is to embrace being the dumbest person in the room. Of course, you don't want to stay that way forever, but the idea is that it's good to be humbled here and there and be shown how much room there is for you to grow! It means that there's scope within your team to really improve yourself as an engineer.
The next step here is to be weave in this behavior proactively into your future work:
And of course, if you don't fully get their mindset yet, just ask! They're your teammate - It seems like they're open to helping. In general, whenever you get into an education moment like these, you should always push the boundary and ask follow-up questions to maximize your learning. We talk about in depth in our video here: How To Actually Learn Software Engineer Skills
Here's some additional resources on how to ask a good question:
Considering that I have 10 years of experience it felt very disappointing that I could not think of this on my own.
No need to be disappointed! I know many engineers who have 10 YOE and aren't staff yet - In fact, I think most engineers take >10 years to get to staff. Careers are a marathon, not a race: There's nothing wrong with taking 15 or even 20 years to grow to staff or even never making it to this level at all! And of course, staff engineers also have mishaps like these all the time - They're only human, just like all of us. This event has 0 negative bearing on your quality as a software engineer.
Lastly, here's some great resources breaking down staff engineer behavior + mentality: