October 1, 2019

How to Be a Good Senior Developer

Editors Note: Every software engineer at some point wants to level up and advance in their career. However, seniority doesn't cover the code quality only. In today's post, It Program Director, Ravi Shankar Rajan explains that it's more than just writing quality code.

If you want to be, a really good, senior developer there’s only one way to go about it:

Commit mistake, correct mistake, learn from mistake, share mistake—repeat.

A collection of mistakes becomes your experience and learning from experience is the key to becoming a successful senior developer. Simple, right?

That said, if you’ve recently started your career as an entry-level developer, you’ll be wondering what steps you need to take to climb the career ladder. Is it simply a matter of time? Do you have to go back to school or get some advanced certification?

Not necessarily.

Even though formal education may help you advance up the ranks, I know many developers who’ve reached senior status with only a college degree.

Something else to remember when it comes to senior developers is that great ones are not only able to write solid code but also have other traits that make them desirable. A senior developer is a person who can bring in 10x more value to the company. These are developers who know how “good stuff” works and can deliver value to the customer.

Think of it as more than a job title. It’s a work ethic. It’s not what you do, but how you do it which will make you a true senior developer. And there’s no way around this one. You’re not going to roll into your first job as a senior developer. It comes with mistakes—lots of mistakes—that are finally converted into learning and experience.

Here are some qualities I think would make for a heck of a senior developer, and that distinguish them from those who are not quite there yet.

They’re Curious

As Albert Einstein rightly said:

I have no special talent. I am only passionately curious.

Research says that you increase your ability to learn and retain information when your curiosity is stoked. When you’re curious, the limbic reward system of the brain comes into play. When the reward system is activated, our brains release a chemical called dopamine, which gives us a high and makes our learning faster even for boring topics.

Good senior developers go one step further. They channel their curiosity in a structured manner so they can use the information accumulated during crunch situations. One of the ways to do it to go deep in any language before going wide.

They Learn Their Chosen Platform Inside Out

Very few programming problems are original. Very few companies are creating technical stuff that hasn’t already been done by many more teams before them.

That’s the reason the majority of the things you are trying to do have already been solved by the very language/platform you are already using. For example, I once modularized a humongous 30,000 lines of SAP ABAP code into a class of 200 lines using SAP’s out-of-the-box object oriented classes. I was able to add value because first and foremost I had decided to master ABAP before delving into any other SAP module. I know it’s slow, but it’s worth the effort.

Good developers never accept matters as they are. Whether their code works or doesn’t, they are always trying to find the answers to every “why” they have to ask.

They’re Great Mentors

John Crosby hit the nail on the head when he said:

Mentoring is a brain to pick, an ear to listen, and a push in the right direction.

In 2008, Google did a major study on this question. The Project Oxygen team in Google’s People Innovation Lab spent a whole year data-mining performance appraisals, employee surveys, nominations for top-manager awards, and other sources to evaluate the differences between the highest- and lowest-rated managers. Their statisticians gathered more than 10,000 observations about managers across more than 100 variables.

Two important inferences came out of this study:

  • The most important activity for management success is being a good mentor. Successful managers know how to mentor their teams to success.
  • The least important is technical skills. This proves that a great developer doesn’t necessarily make a great manager.

As a result, Google changed its feedback surveys to reflect these qualities. Instead of simply measuring how much output a manager achieves, the surveys now focus on how much time they spend coaching their team, whether or not they communicate a clear vision, etc. They also developed new management training programs centered around these skills.

That said, one key expectation from every senior developer is that they should be able to interact masterfully with internal and external customers and stakeholders. Tech jargon will not get you anywhere when you interact with people from non-technical backgrounds. That’s why the best senior developers are the ones who don’t get wowed by technology.

Instead, you'll need to cultivate the skill of explaining complex technical concepts in simple language, using real-life examples, and quickly gauging the level of comfort the listener has with the jargon.

Mentoring is the powerful link between a junior and someone more experienced not only for career development but also for personal growth. Share knowledge, share experiences, forge ahead.

They Don’t Have “Shiny-Toy” Syndrome

According to Jeff Bezos:

A company shouldn’t get addicted to being shiny, because shiny doesn’t last.

This applies to developers, too. In fact, most developers are magpies by nature, always collecting shiny things, storing them away and looking for connections. If you’re not aware of this phenomenon, shiny-toy syndrome is typically characterized by wanting to own the latest toy, often irrespective of the practical or functional need, or being hooked on the intense but very temporary high of ownership before moving onto something else.

The best senior developers keep this disease in check. They know precisely when not to do something. They know that rewriting a library from scratch just to make it more readable, or switching to the newest framework from the older one are not always good decisions. They’re not risk-averse; they’re just careful in picking the right battles.

Because finally, it all boils down to the code. The code should do exactly what it’s supposed to do—and nothing else. The purpose of the code should be clear enough to grasp within minutes or even seconds. Navigating through the code should be easy, even without sophisticated wizardry.

Simplicity is the ultimate sophistication.

They Admit What They Don’t Know

Neil Gaiman once said:

Not knowing everything is all that makes it OK sometimes.

The hardest three words to say are not “I love you,” but “I don’t know.” That’s the opinion of Stephen J. Dubner and Steven D. Levitt, authors of the behavioral economics bestseller Freakonomics.

How will you handle that inevitable moment when it occurs? You’ve been talking confidently for 20 minutes about your accomplishments, enjoying the glow of being on top of your game. You answer yes, yes and yes again to question after question, but now they’re asking you about stuff that…well, you don’t really know.

This is a painful anti-climax for many. But, it’s perfectly OK to say so. It’s a lot better than covering up your lack of knowledge or skills. The key thing here is to know how you’re going to address the issue — either by asking someone else or digging deeper.

It’s all about how you answer the question that makes you senior. Can you lean into why they’re asking in order to get more context and be more broadly helpful? Can you offer to help find the answer together? Will you do some research afterward and follow up with them?

Being a senior developer doesn’t mean you have to know everything. It means you can help find out anything.

Lastly, They Can Detect the Smell of Bad Code

Seymour Cray was bang-on target when he said:

The trouble with programmers is that you can never tell what a programmer is doing until it’s too late.

That’s why good senior developers are very allergic to code “smells.” If it looks like bad code and smells like bad code, it’s probably bad code. The developers that came before may have made a mistake, and you will too. It’s how coding works.

As we build iteratively on solutions that have come before, we should strive to improve the codebase and not make it worse. So when you ask the question “Who the heck wrote this?” it should inevitably be followed by “What can I do to make it better?”

You also need to know what has to improve before you can figure out how to improve it. Learn what both good and bad code look like. Top football players spend much more time studying other good players’ games than average players do. I’m sure the same applies to top developers also.

Smelly code is code which, while you can’t quite articulate why, just doesn’t feel right. It needs to be removed. Period. That’s your unique selling point as a senior developer, which differentiates you from the crowd. Do the right thing, even if it is not the easiest to do.

In the words of Donald Kruth:

Everyday life is like programming, I guess. If you love something, you can put beauty into it.

Originally published on