The Evolution of a Software Engineer
I was doomscrolling through reels and saw a video about how software engineers respond to their product managers based on their amount of experience
- Junior engineer: "Yeah I can build that in 3 hours."
- Mid-level engineer: "This will probably take a week."
- Senior engineer: "Do we actually need this?"
- Tech lead: "What problem are we trying to solve?"
There's an insane amount of truth to this. When you get more experience you become more focused on business requirements as opposed to singular tasks.
Junior Engineer
"Oh yeah no worries, I can get that in production by today"
Most of the time, junior engineers are focused only on the task they're provided, and don't usually consider it in a larger context. Given their mindset of trying to impress seniors, this approach to problems makes sense. Questions about the new feature never get asked, and they go straight to writing the code.
It's not a bad thing to be enthusiastic, in fact it's the opposite. It can actually give you condfidence and exposure to building software. This is incredibly valuable to a junior engineer.
One of the downsides is that they often underestimate the task. Factors like deployment, testing, and edge cases aren't considered due to a lack of exposure. Bugs can come up in different features, API limitations, and even auth issues. This is pretty common in larger companies too. When you discover these issues, you realise it's smart to allocate additional time to tasks which are simple on the surface.
Mid-Level Engineer
"Uhhh I think this would take me a week"
This is more of a realistic approach to the feature implementation. At this stage in your career, you've experienced enough issues to know that problems are likely to come up and stall the deployment of the feature.
At this stage, software engineers start to consider specific factors like maintainability, testing, deployment risk, monitoring, and long-term support. This is where surrounding complexity is actually understood, as opposed to just thinking about the feature alone.
Senior Engineer
"Hold up, do we actually need this?"
This is where thinking starts to shift significantly. It takes a lot of courage to actually push back like this for the first time, so it's quite the canon event
Senior software engineers know that every feature introduces maintenance costs, complexity, and future bugs. Instead of immediately building this they begin questioning the requirement itself. From a junior engineer persspective it may look lazy, but in reality its because they understand the negative effects of additional complexity.
Some considerations they'll make include whether it's solving a real user problem, if it's generating money for the business, or how often it'll be used. Ironically, some of the most valuable engineering work comes from simplifying systems.
Tech Lead
"What problem are we actually trying to solve?"
This is probably the most interesting stage. Tech leads and staff-level engineers often move beyond feature requests entirely. Instead of focusing on the proposed solution, they focus on the underlying business problem.
This mindset alone eliminates most feature requests coming from users. Most of the time they realise it's not actually necessary to the business.
At this point the coding mindset has gone, and it's more about systems, communication, and tradeoffs.
Final Thoughts
There's nothing technically wrong with any of these approaches, but the latter has the most impact from a business perspective. As an engineer, you should definitely try and challenge new features assigned to you, and take into consideration what problem it's solving.
