What do senior software engineers do that junior one can’t?

A lot of what makes someone senior is simply that they made more mistakes, learned from them, and can avoid some of them. Note that learning is important, and just sticking around for many years does not make you senior in itself, but most people either leave this career or learn eventually.

If you are more senior, it means that I, as a manager, generally expect you to anticipate the risks and make good technical decisions under uncertainty. (If you can also make good non-technical decisions under uncertainty, you are very senior, what some companies call “staff”/”architect”/”principal”). In other words, if you run the project, I feel confident it will work out.

I think all the actual skills that senior engineers have are different aspects of this.

For example, the highest risk is often people. Either people on the project (a colleague who can’t debug, or gets rabbit-holed into some irrelevant side project) or people off the project (a client who has no idea what they want, a partner team who could not deliver on a dependency you need, a manager who is not technical, etc). So, a senior engineer should know how to deal with some of these things.

Another aspect of risk is knowing yourself. You should be realistic about what you can and cannot do, and do not fool yourself into taking on something you’ve never done before and expect it to work perfectly, or even worse, something you’ve tried and failed on before. Hope is not a strategy. On the flip side, a senior person probably does know more stuff than a junior one, so perhaps you can solve some problems that others can’t on a purely technical level, and that reduces the risk for you.

One aspect of the above that most junior engineers are prone to, including me, is trying to use the cool technology, and use it in the most clever way possible. I can tell you my own horror story about it, but I’ve seen many people succumb. They want to do something in Rust or Haskell, they want to use template metaprogramming in C++ (that was me), they create a custom domain-specific language, they found this cutting edge library on GitHub with one student maintainer that you don’t understand entirely but does exactly what you want in this super-clever way. You would probably regret this.

Another risk is plain execution risk. If you have to try something that may or may not work, you need to have a plan B ready. You need to iterate in small chunks. One common mistake that junior people make is to try something very large that takes months to do and is all-or-nothing. Sometimes you have to do this, but it’s very risky.

Being more senior just means you are a bit better at these things. But as a manager, I mostly just want to delegate the project to you, and I don’t want to care about the specific obstacles you deal with. The alternative is that I have to step in and do it myself, and in practice, this always happens to some extent, but the more senior you are, the less I have to interfere.