Five lessons I learned to move up to Senior Software Engineer

The lessons in this article will help new or mid-level developers understand what is needed to move up to Senior Software Engineer. These are lessons that I learned during my career that helped me in my own journey.
Hopefully, now they’ll help you.
One — There is no black magic or voodoo, just code

It was 2008 and I was staring at my monitor, completely stumped. I worked at a biotechnology back then which was all the rage in my area. I don’t recall the exact problem, but it delved into the internal workings of the .NET 1.1 framework.
As I was investigating this issue, I encountered an article that said the issue I faced was one of dark black magiks where mortals should never tread. Deep voodoo. It offered a workaround, and I took it.
This was a mistake.
For years after that, whenever I encountered a problem of high complexity, I would think “This is some black magic here.” And I’d look for a workaround.
Don’t make my mistake. There is no such thing as black magic or voodoo in software. It’s just code. Often times the code is open source now and you can look directly at it and work out what’s going wrong. If you cannot, then there are a number of methods available to you to resolve your issue.
One method is to open a ticket with the company and wait for them to resolve the problem within their own software. This isn’t a technique limited to only senior level developers, but it seems that only senior level developers tend to realize this fact.
Work problems to completion and don’t take shortcuts or workarounds.
Two — Source Control Detour
This tip will be aimed only at very junior developers, but perhaps you’ll enjoy my painful story.
I was a completely green developer, fresh from college at the time and working on my very first real project. I’d been plugging away for twenty or thirty days (hooray, waterfall!) when I came in one morning and all my work was just…gone.
I took my problem to a senior developer on my team and his response was, “No problem. We’ll just restore it from source.”
I look at him, puzzled. “Source …what’s that?”
Now, in my defense, my coursework at university was theoretical not applied, so I just had no idea about some common things that most developers in the industry already knew. In this case, I got to learn the hard way be re-doing my entire project, working nights and weekends until I was caught back up.
The lesson here is make sure that you’re keeping an eye on your junior developers and they they have the basic information about your process…like checking code into source control. As a senior I make sure to review our process with new developers very early on and I’m looking for a commit within the first couple days.
Other lessons here include:
- Check-in smaller commits. This helps pull requests be more bite-sized for the reviewer and makes it possible to cherry-pick code as needed. It also reduces merge conflicts.
- Most merges aren’t that complex if you’re using good coding practices. If you notice code merges are unusually complicated or difficult this is generally a sign that you need to analyze your code check-in process
Three — The difference between a Senior and Non-Senior developer is mostly experience

At my first job, I remember thinking that the senior developers at my company must be certified Mensa-level geniuses. They all just seemed so…smart!
When I encountered an issue I’d be stuck for hours, but when I brought it to the attention of a senior they’d just immediately know what to do in order to resolve it. I was amazed by their knowledge and ability. They were like code wizards.
Now that I find myself on the other end of these encounters, I realize that the difference is primarily experience. Because I’m able to accomplish most tasks on near autopilot, more of my focus is available for solving the problem at hand. I don’t need to expend any brain power remembering how to write the code or thinking about how the system fits together. I can dedicate almost 100% of my brain power to solving the issue.
A junior developer, in contrast, must dedicate perhaps 50% or 60% of their brain power trying to understand the code, understand how the system works, understand what the architecture is, etc.. This only leaves 40% or less, to actually solving the problem.
If you are feeling inadequate at your job, but new to a company, programming language, or to software development itself, then know that it will get better with time. It’s like riding a bike or driving a car. Eventually you can do most tasks without thinking about it.
Just stick with it and you’ll eventually get there.
Four — I learned how to learn a system
One of my first challenges was figuring out how to make heads or tails of a somewhat complicated software product. If you’re unable to understand how your software works, then you’ll struggle to resolve issues or add new features and components.
I’ve moved between a handful of companies in my career and become adept at learning new systems quickly. For me, I prefer to start at the front and work my way to the back. This means learning how the front-end components connect to the back-end and then the data layer.
Everyone learns differently though. I know some developers that start at the back-end or even the database as a starting point. The difference that distinguishes a senior engineer is the level of depth that you learn and understand to. If you can understand the basic workings, that’s good, but if you take the time to understand the system at a deep and thorough level, then your value to the company increases near exponentially.
Many developers are afraid to take the time to learn a system in-depth, because deadlines. I believe it to almost always be worth the extra time. For every hour you spend digging deeper into the system, you’ll be paid back ten-fold in the future for that knowledge.
Take a little extra time now, to save a lot of time later.
Five — I learned basic design patterns and architecture design

Without realizing it, you’ll discover various design patterns and architectural designs if you stay in software long enough. Eventually, you’ll want to discuss some of these with other developers on your team and this is where we separate many good developers from mediocre developers and/or senior developers from…not-so-senior.
I would argue that you’ll naturally want to know the correct way to refer to a design pattern within the industry. You’ll see articles and blog posts discussing this pattern or that, and you’ll want to know which pattern is being referred to.
While there could be some power play here involving publishing a book with your own names and terminology for various patterns, it’s much easier to learn the industry standard terminology. When I’m in an interview session for a senior level developer and they can’t explain what the strategy pattern is, it’s a bit of a red flag.
Beyond design patterns, you’ll need to pick up architectural design. This also comes from experience. From being given a feature to complete and having to create your own design. With any luck you have a senior developer to give feedback on your design, but chances are you’re all on your own here. Trial by fire.
Therefore, my definition of a senior software engineer would include proven experience in both areas:
- Experience using various design patterns
- Experience planning and executing an architectural design for a system
Parting Thoughts
We reviewed five lessons that will help developers move toward that lofty Senior Software Engineer. Lessons such as:
- Learn your product thoroughly
- Use source control!
- Experience is king!
- Learn how to learn systems
- Learn design patterns and architecture design
While there are certainly more, mastery of these core five lessons will move you far along the path in your career, if you’ve not already mastered them. Best of luck in your journey and drop a note if there are other important lessons that you’ve learned and would like to share!