From Implementing to Solving to Finding Problems
Hello there!
This is the last issue of the year! I wondered if this one or the first of the year should be a review. But it was more appropriate to have the first one be the review.
I hope you spent your Holidays with your loved ones or had at least a few days of rest and recovery. Whatever your situation, holidays tend to be difficult, so I hope you prioritize your health. :)
Was this forwarded to you? You can subscribe here!
I've been thinking about this topic as I mentor other people and help them discover where they are in their journey.
Junior-level
When I started working as a software engineer, I wondered why X or Y were not solved differently. However, I was mostly asked to work on features or fix specific bugs. I wasn't in a role where people expected me to solve old problems differently.
In retrospect, I needed more system context and more practical experience.
When we're starting, it might feel cool to point at problems and ask why they didn't do them "better." Either after reading some paper or blog from a large tech company.
From a role perspective, you're mostly expected to implement solutions to problems that more senior folks have already solved since we're missing context and experience, but also political currency to be able to pursue "fixing" the issue.
Senior-level
After a few years of experience, I became better at problem-solving via pattern recognition.
There is a lot of power in thinking, "I've seen this before." It allows you to rethink what options are available, and with your other experiences, you can reuse a prior solution or develop a new one. This experience and pattern recognition comes in handy during live incidents.
We become better at finding hotspots or that squeaky wheel that occasionally keeps giving errors.
Other places where this shows up are when new projects come; you might not get a detailed ticket but rather a "problem," and you're in charge of finding the best solution.
Staff-level
After becoming an avid problem solver for the organization, you start getting on the door of the next step! Which is finding problems before they occur. You might be chosen to kickstart a new project, and that means anticipating problems.
You don't need to come up with either solution for everything or find all possible problems.
At this stage, you anticipate risks for your project and learn to mitigate them. You'll mentor more junior team members to solve their problems and also teach them how to find these problems before they happen.
Principal-level
Once you're past staff and into Principal and beyond. You will be expected not only to anticipate problems with projects but also to anticipate problems with company goals!
In this case, it means that if the goal is to increase revenue or enter a new market. You need to help the organization understand what problems we might encounter and which projects we need to do to handle them.
Conclusion
We might always be on the lookout for problems in our context. But as we grow in our careers, the expectations and experience help us shift our role from only implementing solutions to solving problems and finding problems!
While finding problems might be overwhelming at times, it's always helpful to have an idea of the expectations of our role to avoid getting burned out!
Your turn!
Let me know if this correlates with your experience and career progression! If you have any thoughts, let me know by replying to this email.
Happy coding!
Oscar
Things I discovered in the past week
- The world before Git talks about the "pre-historic" times when we didn't have Git. I don't think I'm that old, but I did work at a place where we didn't have a distributed version control system.
- Transaction Isolation in Postgres explained a cool deep-dive into transaction isolation on a SQL database!
website | twitter | github | linkedin | mastodon | among others