The defining trait of a senior software engineer is empathy and understanding for those who came before them in a codebase.
Writing a new application from scratch is relatively easy. You get to pick the programming language, the tooling, where you’re going to deploy. You can pick the newest, shiniest thing, or your favorite thing, or the thing that will make you or save you the most money.
With a new application, every decision is yours. They all make sense because you made them. Being decisive is easy. Every choice is the right choice because history hasn’t proven them wrong yet.
With legacy code, nothing is intuitive. A less experienced technologist looks at legacy code and says:
“This doesn’t make sense.”
“This is wrong.”
“This is terrible.”
“I know how this needs to be.”
A less experienced engineer balks at legacy code. They take it as a personal offense. They complain. They appeal for time for rewrites.
An experienced engineer has written legacy code. They’ve walked into old, large codebases. They’ve returned to code they’ve written themselves and thought, “This is terrible.” They’ve navigated the seas of a thousand business decisions that found their way into illogical, convoluted systems. They look at legacy code and ask:
“What was the intent of the author?”
“What was the business and organizational environment when this code was written? How is it different now?”
“What technology was available when this system was designed? What resources were available to the original designers and authors of this system?”
“What problems were they trying to solve?”
“What does this code tell me about this domain?”
An inexperienced technologist provides answers with words and creates problems with code. An experienced engineer asks questions with words and solves problems with code.
This was originally written in February 2019. I’m going through some non-blog writing archives at the moment, re-publishing here what still holds up.