By Jedai Saboteur
Monday, January 12, 2026 at 3:43 PM Mountain Standard Time
I can’t tell you the exact moment I became a mid-level software engineer—because no one ever tells you when it happens.
There’s no ceremony, no promotion email that suddenly makes everything click. One day you’re still asking a lot of questions, the next day people start assuming you already know the answers. You’re trusted with more autonomy, more ownership, and eventually, more consequences.
Looking back, I can see that transition clearly, even if I couldn’t name it at the time. I was lucky to work in environments with a high degree of trust early in my career—small teams, real ownership, and room to make mistakes. That freedom accelerated my growth, but it also meant I learned some lessons the hard way, often while actively supporting production systems.
This article is a collection of those lessons. Not a checklist, and not a definition of what a “mid-level engineer” is supposed to be, but the things I wish I’d trusted, questioned, or acted on sooner as my responsibilities quietly grew.
When I started my work on the student portal, I erred toward the assumption that more-senior engineers had made better decisions that I possibly could have. I saw some decisions, pretty immediately, that made me raise my eyebrows, but I assumed those decisions were the best that could have been made. As time went on, and my knowledge in the toolset grew deeper, I realized some of those decisions were really just what worked at the time. Some of those decisions ended up becoming issues as time went on. I could have— should have— spoken up when something seemed off.
I worked nearly solely on the student portal for a solid year and a half. I’d come to know that product like the back of my hand when an organizational change shifted me to the platform team for a few months. While I stil took on a few features for the student portal, my days looked very different as I delved into devops and internal tools. I largely traded writing JavaScript to learning the architecture and execution of tools in the Kubernetes sphere. Bash scripting became my primary IDE-based activity. Then, my laptop got stolen and I quickly found out my replacement was unfortunately sub-par, requiring just as much research into workarounds and hacks as learning devops tools I was working with. Keeping up was hard with that extra mental tax.
Right around the time I’d hit my stride with the platform team, I was shifted to yet another team, this time focused on a green-field project to replace an older B2B system. It was largely a frontend endeavor, working with a new (to me) team of people that were pulled from various other places in the org. While I did a good amount of frontend work on the student portal, it was primarily a full-stack project and being confined to ‘one end’ of the process on the new team was more frustrating than the move to platform development.
All of that bouncing around was a net-positive for me, though. Switching tools and getting up to speed on something new became a more fluid process. At first, it was frustrating, but it became somewhat refreshing. I had a wider view of how all of our products fit together, what toolsets we had in use, and, importantly, how some of those tools could align. When I found myself returning to the student portal, I had a boatload more knowledge and suggestions that I was able to put into use very quickly.
As your familiarity with a project grows, you’re better able to anticipate its needs and see into its dark corners. That knowledge is why you’re there, your teammates and managers count on it. After my return to owning the student portal full-time, I started an initiative to update the front and back end. I wasn’t concerned about just preserving what worked, but ensuring that those who came after me would have the easiest workload possible if they had to touch that codebase. A lot of the work I ended up doing to that end were things I’d thought about for months to a couple of years, but wasn’t sure if they were the right moves. If I’d trusted my own instincts earlier on, I have no doubt that the work I did would have been a smoother process, and major incidents could have been avoided.
Incidents happen. Sometimes they’re your fault. Some of the incidents that occured at my last job were absolutely mine. Incidents can seem like personal failures, but in my experience, what truly matters is how you manage those incidents and prevent them in the future. For instance, we had a series of incidents that I thought were a failure on my part. After a slew of meetings and inspection of various parts of the system (both in and out of my control), we discovered that we were all operating on a false assumption about the data we were working with and testing against. It took working through those incidents to surface the deeper issues. I won’t lie, it felt a bit disheartening when they happened, and I felt like I was under a microscope for a period of time as we worked through them. Once we came out of the other end, though, I felt like there was a higher degree of trust and understanding between all of us, and more importantly, we had solid plans for eliminating future incidents— in this case, it took a deep dive into the data to create a more solid testing dataset and implementing feature flags for fellow engineers and stakeholders to test new features before they ever reached students.
There weren’t really any junior developers on the teams at my last position. We were all a few years into our career and owned something. There certainly were more senior team members among us, though they often were taking ownership of different projects or initiatives. They were people too, though, and there were certainly times when they needed help understanding the why or how of a certain tool or process. I have a deep level of understanding when it comes to JS/TS, and I shared a lot of that knowledge with team members more senior than I was. Our specializations are a large part of why we’re hired, and sharing knowledge within those spheres goes both above and below us. Assuming that seniors know more because they’re senior is a bit of a trap. While they might have more experience overall, software engineering is a massive domain, and some people barely (or never) touch certain tools/languages, or their experience with them might be a few years off. As long as we remember to be empathetic and leave our egos at the door, there’s capacity to pass our knowledge on, even to people with more experience than our own.
In the end, no matter where we are in our careers, we’re always learning. Whether it’s learning new languages, tools, processes, or nuances about the products we touch, the learning never stops. It keeps the job from becoming rote or stagnant, and helps us create the best software possible. The most dangerous position to take (imo) is that we don’t need to learn more once we reach a certain level, or tackle a certain project. The desire to know more about our craft and our projects is what drives the most innovation. We can’t just call it a day when our knowledge is sufficient to get the job done— that’s not why we’re in the positions that we are. At the end of day, we’re assets to the organizations we work with. Investments made by businesses that seek returns.
In hindsight, the title of this article is a bit of a misnomer. Most of these thoughts weren’t new to me when I became a mid-level engineer. I just didn’t trust them yet.
Confidence tends to lag behind competence. Many of us second-guess ourselves, hesitate to speak up, or delay decisions because we assume we’re missing some crucial piece of context that more senior engineers must have. Sometimes that’s true. Often, it isn’t.
The longer I work in software, the more convinced I am that growth comes from leaning into responsibility, asking better questions, and staying curious long after our knowledge is “good enough” to ship. We’re hired not just to execute tasks, but to think critically about the systems we own and the people who depend on them.
If you’re early in your career—or just starting to feel the weight of ownership—trust what you know. Take the risks you can afford. And never stop learning. Those instincts are often the signal that you’re already further along than you think.