What’s the Difference Between a Senior Software Engineer and a Junior Software Engineer?

Self-note: this is a draft from 2020 that I end up writing in 2026. I try to recall my way of thinking back the best I can in order to finish the article without skewing with what I learnt since then.

Back to 2018, I was asked this question during an interview. I had little experience at the moment and, on the spur of the moment, my brain popped up the answer:

A senior engineer writes bad code and does know why while a junior engineer writes bad code and does not know why.

Despite being an attempt of humour, with a debatable level of success, I am still convinced, as-of today, that this belief summarizes my vision of seniority. I believe I properly considered the nuance of this question: it was about not good and bad engineers but senior and junior engineers. In other words, what is my definition of experience? .

The Why of this article

I am now working as a web front-end developer for more than a year as well as team lead for about a year. I, learnt, still learning, about what is it to be a software developer and more importantly, “What kind of software developer I want to be(come)”.

For organising my thoughts. Learning is nice but writing things down is a nice mental exercise to clarify what I really learnt. And it usually starts very blurry.
For sharing knowledge. I will never insist enough on that point: sharing is as valuable as learning. What if it helps someone by accident?
For having a future retrospective. if I read back this article in few years, I can check out the evolution of my thoughts. Maybe my focus will change, maybe my priorities will change, who knows.

How to define good and bad software engineers?

I’d like to do a brief stop on that matter. While writing this article, I will do my best not to emit any forms of judgement. Among eternal debates such as “Vue.js vs React vs Angular”, my belief is that “there is no best nor worst option: each framework / library has its own strengths and weakness.

Libraries and frameworks evolve in an ecosystem and we, software engineers, evolve in the software engineering environment.

And that’s what I am currently looking for: what are those traits and do I want them?

Coding was first by myself and for myself, like for many developers I guess. I am now coding with others for people I have no idea who they are.

When I look at current my “coding for myself by myself” environment, I rely on some people’s libraries, check some people’s tutorials or blogs, get saved by some people’s answer on Stack Overflow. “People” everywhere. Whether I want it or not, my coding environment goes beyond my laptop and is now a social environments with its own structure and etiquette but I have not entirely found my way to evolve there.

Let’s assume “Any social environment requires rules for the sake of stability” being true. While arguing over the truthiness of this statement might be an interesting exercise, I am not here to write a philosophical article so let’s move back to engineering.

However, the terms “rule” sounds being a lot of constraints to me. I prefer the concept of “principles”. While it might not the exact English definition, I believe a “rule” is applicable for many, if not all, members of a group, sometimes without the concerned members’ consent while a principle defines how one behaves given a situation. Unlike a “rule”, a “principle” is a pure result of my free will.

A caricatured rule would be: all your variables name must be with an article “a” or “one”, decided by my team lead who (ab)uses his hierarchical superiority to impose this rule upon me. On the opposite, a principal would be: I add timestamps to important, self-judding, comments to keep track of the comments evolution. No one asked me to do it but I do it of my free will. Now that the context is, finally, set: to adapt to my current environment, what (software engineering) principles do I want to follow?

My new silver bullet: I am not alone

In and out of the code, I like to follow principles. Applying best practices, whenever I can, being one of the principles I claim to follow. The Bible has the ten commandments. Ten is already too much. My brain being a lazy engine, I need fewer principles to keep in mind. How about a root principle or concept from which all principles will come out from?

I am not alone so I have to interact with others. While doing so I want to make sure that I properly understand them as well as making sure that I am properly understood

I feel relevant to split principles according to the interaction

Coding with and for my future self
Coding with and for other developers
Coding with and for non developers

Understand others and be properly understood by them is key, mostly to ensure I am not left behind, neither by my peers nor my end-users.

Deliver your code

A undelivered code is a sad and lonely code sitting at the corner of your hard-drive or repository. Delivering a code does not always mean hitting the deadline. A code might be waited by someone, which makes your code binded to your teammate’s deadline.

Imagine your code as the keystone of a product development. It comes at the end of a long thought process (product design, UI/UX design, architecture, release planning etc) and code is what links all of these together to bring the added-value to end-users.

Code like you are writing a library

Document, comment, explain…with parsimony

Know what you are coding, don’t deliver half-baked code because it is the best recipe for poor maintenance. As I want to code for my future self, I want to make sure I can easily pick up what I wrote without insulting my past self.

In short, code like your code is reviewed by a psychopath. Additionally, I believe excellency is invisible. Doing a great job makes your output boring: there is nothing to say, nothing to complain about, nothing happens.

Learn fearlessly

I was afraid of Git. During my start-up period, I used SVN in a very basic way as we barely used branches. Then I met problems over problems. Branching was needed. I knew Git who be my messiah. But it took me far too long to put my development on hold and focus on learning it. Few days later, I could not understand why I was afraid of Git.

Same goes for Docker.

To summarize, I believe experience builds up when you are perceived as reliable: not only an experience developer delivers examplary code but they also fit in their social environments. They are able to support their peers as well as they delivery critical values to their end-users, may it be visible (such as feature) or invisible (such as reliability) values.

To get there, a simple suggestion is: “Try, fail, consider to try again, try and land beyond your boundaries”