loading...

I Read 21 Articles About How to Become a Senior Developer So You Don't Have To

samborick profile image Sam Borick ・9 min read

I think it's fair to say that almost everyone wants to move forward in their career. For some, that means becoming a Senior Developer.

Since there are a lot of people that have this dream, there are also lots of people that write about how to attain it. Instead of contributing to all that noise, I decided to do a survey of as much of the existing noise as I could find.

So I went through 21 articles that came up when I searched for "How to become a senior developer" and adjacent searches.

Commonalities

The articles typically discussed the things you need in order to become a senior developer. There were not a lot of step by step guides like I was expecting, but more checklists of things that senior devs should be able to do. These fell into two major categories:

  1. Soft Skills
  2. Hard Skills

Soft Skills

"T shaped" knowledge

Per wikipedia:

The vertical bar on the letter T represents the depth of related skills and expertise in a single field, whereas the horizontal bar is the ability to collaborate across disciplines with experts in other areas and to apply knowledge in areas of expertise other than one's own.

T shaped knowledge is really useful as a developer, since we have to dive deep in order to get any work done at all, and nobody can have deep in all areas of development, so being able to collaborate is very important.

Here is a great article on how exactly to develop T shaped knowledge.

Mentorship

There were three major threads that came up around the topic of mentorship.

The first is to have a solid mentor or mentorship network. In addition to being able to contribute individually at a high level (being good at making software), senior developers are also expected to have good interpersonal skills. In order to develop those skills, you really need mentorship by someone who already has them. It's not really possible to develop those skills in a vacuum.

The second thread goes along with the first. You need to know when to ask for help. Working with others means being able to rely on them, and knowing your own limits.

The third thread is providing mentorship to others. The real value of a senior developer is that they empower others to be better developers too. This means little things like not being a jerk in code reviews, but also being a good teacher to newer developers. This also takes practice.

Thinking about The Big Picture™

"The Big Picture" is one of those things that people say a whole lot but can mean so many different things. Going through all of these articles, they tend to mean any (or all) of these things:

  1. The Business Stuff- how to meet KPIs or the current big deadline or whatever.
  2. The User Stuff- how to actually provide value to the people who use what you make.
  3. The Technology Stuff- how to build something that will last a long time.

I don't get the impression that there is a quick way to build these skills. It seems to be that it's just a matter of experience.

Part of this is accountability. Being able to accept responsibility for the big picture can take you a long way.

Problem solving

As James Hickey (@jamesmh ) said in this article:

Senior developers are more cautious, thoughtful, pragmatic, practical and simple in their approaches to solving problems.

This includes thinking about the impacts of your code in the long term, and being able to craft elegant solutions to the problems you encounter.

Make your goals known

This one is really simple to express, but very hard to do. Make it known at your place of work, especially to those who make decisions: "I want to be a senior developer". If you don't tell people that this is the path you want, they probably won't just assume it.


As my favorite article said:

It’s not by learning new hot framework or language... To put it bluntly, it’s more about understanding what to build and if it’s worth building instead of how to build it... [A] Single person possessing knowledge of both “what” to build and “how” to make it happen can deliver superior results.

Hard Skills

I think these are a lot more indicative of the developer culture, but aren't really all that useful. Don't take these too seriously, just have a laugh.

Typing speed

This came up so often that it made me laugh. As we all know, you can't get better if you don't type like a hacker on tv. A lot of similar advice to get good at your IDE of choice (gotta know all the shortcuts!). I think the kernel of truth here is you should feel comfortable with your tools, whatever that means for you.

Learn This Technology

A lot of advice to make sure you know the favorite thing of whoever wrote the article. Considering that there are still a ton of COBOL jobs out there, there is no particular technology that you need to know.

Work on side projects

There is this pervasive idea in tech that you need to work on side projects in order to grow as a developer. This is just not true. You don't need to be spending every waking moment of your life working on some kind of programming thing.

In my experience there are three reasons to work on a side project:

  1. Learning- picking up a specific skill you didn't have before.
  2. Experience- doing more programming in total (making you more experienced).
  3. Fun- sometimes programming is a fun thing to do!

If you want to do all three at the same time, then side projects would probably be perfect for you! If that's you, then you're in the right place! Check out WeeklyProject.Club.

If that's not you, don't feel bad about it!

"Learn the Classics"

This didn't come up nearly as often, but a lot of people tell you that you need to read Knuth, or Pragmatic Programming, or Clean Code, or some other popular book.

Articles

Here's the list of articles I went over. Each article has a breakdown of its key takeaway. Since most of them are listicles, they just have each point of the listicle, since that was typically the only substance the article had.

  • How To Become A Senior Developer

    • T shaped skills
    • Feeling experienced in solving problems and being able to relate your current problem to problems you've seen before
  • 6 Tips to Become a Senior Developer

    • Develop quickly
    • Find the ideal solution
    • Teach others and help others grow
    • Share what you already know
  • 10 Steps to become a Senior Software Engineer

    • Choose your path and stick to it
    • Read "the pragmatic programmer"
    • Master your programming language
    • Learn your framework
    • Become a master of your text editor / IDE
    • Use your Version Control System like a pro
    • Commit to doing Test Driven Development
    • Refactor as a habit
    • Learn software architecture
    • Unleash the power of the command line
    • Practice coding
  • What Does It Take to Become a Senior Developer?

    • Asking good questions
    • Be able to connect the dots
    • Emotional intelligence
    • Be able to teach
    • Be able to learn
  • 7 steps that take you from Junior to Senior developer

    • Invest in your tools
    • Typing speed matters
    • Explore a different problem domains
    • Write tests in your mind
    • Spend some time in your enemy’s framework
    • Figure out 5 things you wish were different about your current tools
    • Be inquisitive of old sores in your company.
  • Don’t be a Junior Developer: The Roadmap

    • SSH
    • Advanced Javascript
    • How to Improve Web Performance
    • Progressive Web Apps
    • Popular Frontend Library + How to Manage Complex State
    • Testing
    • TypeScript
    • Client Side Rendering vs Server Side Rendering
    • Securing Your applications
    • Docker and Containers
    • Different Types of Databases
    • How to Manage Sign In + Sessions In Your App
    • Infrastructure as a Service and Platform as a Service
    • About Continuous Integration
    • Delivery, and Deployment
  • From Junior to Senior: The Skills a Back-End Developer Should Learn

    • Asking for help
    • Communicating & collaborating
    • Problem solving
    • Javascript server side languages functional programming & blockchain
    • Design & back-end architecture
    • Keeping up to date with emerging technologies
  • How to become a senior software developer

    • Take responsibilities and execute
    • Always go the extra mile
    • Be a problem solver
    • Be continuously learning
    • Market yourself
    • Be likable
    • Be a mentor
  • How to Get a Raise or Promotion for Software Developers

    • Always Choose Responsibility Over Pay
    • Take Initiative
    • Invest In Your Education
    • Make Your Goals Known
    • Make Yourself Valuable Outside Your Company
    • Become An Asset
    • Ask For A Specific Number
    • Don’t Make Threats
    • Don’t Talk About Why You Need The Money
    • If All Else Fails, Go Elsewhere
  • 15 Tips on How to Improve as a Junior Developer

    • Read Stack Overflow
    • Zoom out
    • Do your own QA
    • Don’t ignore the world around your work
    • Separate your concerns
    • Write short methods
    • Seek constructive criticism
    • Find a mentor
    • Get really familiar with your text editor/IDE, and know its keyboard shortcuts
    • Pair program with more experienced developers
    • Listen to and respect more senior developers around you, as well as other juniors
    • Use good method/variable names instead of comments
    • Expose your ignorance, daily, Have side projects.
  • How to Get Promoted as a Software Engineer

    • Promotable Technical Skill Sets
    • Promotable Intellectual Skills and Work Habits
    • Be professional
  • 20 ways to get promoted in the tech industry

    • Think Business First
    • Technology Second
    • Raise the Bar … and Leave It There
    • Hold Your Nose and Raise Your Hand (volunteer for projects)
    • Don’t Pass the Buck
    • Be a Lone Voice in the Wilderness (be a leader)
    • Back Down Gracefully
    • Develop a Killer App
    • Stay on the Cutting Edge
    • Feed Your Mind
    • Find Your Yoda (get a mentor)
    • Take Deadlines Personally
    • Share the Wealth (teach others)
    • Be Your Own Cheerleader
    • Build Your Own Portfolio
    • Schmooze It or Lose It
    • Walk and Talk
    • Hire Your Own Replacements
    • Embrace the Gray Areas
    • Keep Your Nose Clean (Not Brown)
    • Consider a Switch -- for the Right Reasons
  • 10 things that change when a developer gets promoted

    • Less Coding
    • Architecting or “Hands On”
    • More “paperwork”
    • Thinking more strategically than tactically
    • Less control
    • An increase in responsibility
    • More time resolving issues
    • Toeing the company line
    • You become “one of them”
    • More meetings and more communications
    • Potential for more external relationships
  • The Software Engineering Job Ladder

    • Programming ability
    • Communication
    • Critical thinking
    • Initiative
  • How to become a Better Developer

    • Challenge yourself
    • Study the masters – and mastering
    • Learn the classics
    • Practice mindfully
    • Mind your body
  • 10 Ways to Become a Better Developer

    • Find & Embrace "Team"
    • Learn to Say “No” the Right Way
    • Get Your Code Reviewed
    • Review Code for Others
    • Code Accessibly
    • Code for the Future
    • Don’t Be Naive
    • Security Matters
    • Use Coding Standards
    • At the End of the Day
    • It Has to Work
    • Code for Fun
  • How to Become a Better Developer

    • Follow the right people on Twitter and use it diligently
    • Create your reusable code arsenal
    • Don’t take everyone's word as gospel
    • Listen to music without lyrics while you work
    • Work on side projects
    • Take a break
    • Ignore Imposter Syndrome
    • Learn something different (language, system, application type)
    • Share your work
  • How Can You Increase Your Value as a Software Engineer

    It’s not by learning new hot framework or language... To put it bluntly, it’s more about understanding what to build and if it’s worth building instead of how to build it... [A] Single people possessing knowledge of both “what” to build and “how” to make it happen can deliver superior results.

  • The Key to Becoming a Great Software Developer

    • Practice key skills
    • Find Your Own Projects
  • How To Become A Better Programmer On The Job

    • Diligence and attention at work
    • Collaboration and learning from others
    • Code, Test, Ship, Iterate
    • Join a community
    • Read extensively
    • Work on pet projects
    • Join or start a geek club at work.
  • The Developer’s Edge: How To Become A Senior Developer

    • Technical
    • Team
    • User interview skills
    • Learning
    • Interview
    • Community

And there you go! Now you never have to read another article about "How to Become a Senior Developer" again. What will you do with the extra hours of your life? Let me know in the comments! Alternatively, reply with which of these you struggle with the most.

Discussion

markdown guide
 

Having taken a day to think about it, I still think it's a nice list and I still think many of these points are relevant to other careers.

However, I disagree with the idea in the articles that someone should need to be a mentor as a requirement for seniority. Objectively, some people are just going to be really good at what they do.

I'm basing this opinion on my experience in the visual arts and performing arts. Some people are just really good. They got that way as a combination of talent and practice. And maybe they also had a teachers that encouraged them to continue. But not everyone is cut out to be a mentor and no one would deny that these people are less "senior" for that reason. This is true, IMO, for any profession.

Maybe I'm overthinking this bit, but why can't senior devs be mentors just by being there? Just with day to day demonstrating good practices can help new developers (and artists) can learn what it takes to improve?

The big problem with this criteria is that I see "mentorship" in job descriptions — meaning employers intend to use it as an objective performance metric. I just don't think its accurate or appropriate for everyone.

 

Thanks for the response Allison!

I think there's two different things people mean when they talk about 'seniority'. There's this concept of an individual contributor, someone who is able to do whatever they do extremely well in isolation and isn't expected to do anything related to management.

Then there's this other concept of the 'management track', where these high performers become managers of other people. This is not for everyone.

… but why can't senior devs be mentors just by being there?

I think this is totally fair! There is so much value in being an amazing individual contributor, this one included.

The reason I wanted to highlight mentorship is because I believe that most people can do a good job of mentoring, if they just put a little time into thinking about it and being intentional. It’s not for some people, but I think there are a lot of people who could be great mentors but haven’t tried to, because they don’t see how it would benefit themselves or their organization.

 

I don't think we disagree at all, Sam.

I know this is only one aspect being highlighted. My concern is only when it comes to employment decisions and performance evaluations. My thought is there can be different expressions of mentorship that don't necessarily have to be as explicit and traditional, and those can be valuable too. Perhaps thinking in this way can help more people consider themselves as mentors.

Fascinating conversation -- I'd never considered the limitations with how organisations perceive mentors.

As you say, there are many forms of mentorship, some of which go unnoticed. Some of my best mentors have been excellent -- yet quiet -- developers who led very much by example. Despite saying little, every now and then they would offer a nugget of advice that completely changed how I worked. I wonder now if this was recognised.

 

Thanks for this post, I'm in that middle level devrloper where I don't know how to improve and what to do to become an senior level and this really help.

About the projects I don't totally agrrr, it's good to have projects ambitious because at least for me they made easier and more fun to learn new things like Google cloud, ci/cd and other things, and

 
"You don't need to be spending every waking moment of your life working on some 
kind of programming thing."

This is great advice. When I was in college it definitely felt like everything in my life should be centered around programming. It's good to keep in mind that life isn't all about becoming a senior developer and it's okay to have interests that have nothing to do with it.

 

I'm going to spend my extra time saying hi to my neighbor's cats, although according to xkcd it will take me 2 months to get my time back.

I really struggle with finding mentorship. I'm a freelancer so I spend a lot of time working by myself, and in the midwest, there's no obvious place for me to go and find mentorship.

 

Meetups perhaps, meet other tech folks and build relationships. If there isn't one around you, host it. One piece of advice I read recently, "If you want to network with people, be the one who hosts the meeting."

I'm not sure if co-working spaces facilitate discussions but there's that too.

 

Look for local volunteer non-profit/civic tech groups like @codeforamerica brigades.

 

Don't forget, there are a number of dimensions to being a senior developer. A senior developer at a webdev consultancy is a vastly different job than a senior developer at Google, for example.

I wrote more about the various dimensions here: mooreds.com/wordpress/archives/2812

 

This was really insightful. Appreciate the comprehensive list 👍

 
 

T shaped knowledge

Can also stand for double-sided rake. Meaning that experience gives you enough pessimism that you always take into account the possibility of getting hit in the face with a handle even if the rake was placed teeth down.

 

I don't think title "Senior Software Engineer" exists anymore. With Tech stacks changing roughly every two or three years as well as development methodologies, there is no way to be "senior" in the field. Back when developers worked their whole careers in the same language and development process, the word "senior" in a title really meant something, but in today's fast changing technology landscape, someone who graduated three years ago and has been working for three years, will be more "senior" in those technologies than someone using another technology for 10 years. Today the most important thing is a developers current tech skill set. If you want to get "senior" pay, then you need to follow the most in demand tech stacks. These are the areas that will have a shortage of developers, driving the salaries up.

 

I think the sentiment behind this is partially true, but not all the way. Being a developer isn't only about producing high-quality code, a big part of it is mentoring others. As someone on twitter said the other day, the most important product of a senior developer is more senior developers. Being able to mentor others is as important as churning out code.

Additionally, expertise in one framework definitely does provide some additional experience in others. When you're good at any programming language, you will be better at another than a novice.

Saying that there is no such thing as senior developers invalidate the skills that those people have.

 
  • ... or Pragmatic Programming, or Clean Code, or some other popular book.* I won't lie, I tend to recommend both these books to junior developers. They taught me a lot. (Knuth, on the other hand, I haven't dared to crack open ... )
 

You don't need to be spending every waking moment of your life working on some kind of programming thing.

! Second that... since I made my hobby into a profession, I very seldom code in my free time.

This didn't come up nearly as often, but a lot of people tell you that you need to read Knuth, or Pragmatic Programming, or Clean Code, or some other popular book.

I did not read any of those and still I consider myself a senior dev, even though without the official title but by acknowledgement from my peers. And from time to time I think, I should at least once read the Clean Code. Not because I think it is „mandatory“, but because I think, that it gives you quite a lot of insight on how to write maintainable code.

 

Thank you for reminding me to pick up Clean Code again as I stopped after chapter 3 (like it of course warns you against doing). I've also signed up for the weekly project club since I lose focus (and hope) on my own projects lol.

 

I'm glad you got something out of this! Also welcome to the club!

 

I consider my self a senior programmer, in the popular sense of the word.

I’ve been doing this for 10+ years at varying places using lots of different tools. And I generally find my self helping out others, with concept explaining, debugging problems, mentoring, etc. as much as I work on my own.

I don’t really like the label tho, being a senior should not be a career path.

Being a better more versatile or specialized developer should be.

I have meet others labeled seniors that although good developers hardly had the experience to use their tools optimally, or even worse lets their skills stagnate to the point of uselessness in a updated context.

The tl;dr here is:
People use the label differently, and the moment you switch tool sets, or sometimes just update them it’s likely you go back to being a novice. Asking questions to that junior’ who just got out of school but happened to be taught about that new thing you want.

To heck with being a senior, be a better you instead.

 

Great article, Sam! I was intrigued by your link to WeeklyProject.club. I was hoping to see a listing of previous and current projects, and maybe a listing of folks' submissions for previous projects. It looks like the club is pretty new, but I just wanted to let you know I'd be interested in those features.

 

Thanks for the feedback! That definitely something coming soon!

 

Nice list.

I find it interesting that a lot of these are good tips for advancement in any job.

 

This is great work Sam, thanks for the article.

 
 

There is no extra hours, all extra hours going for learning and improving after this article))

 

Yeah, I pretty much agree with all of this.

Man I really need to read clean code and pragmatic. They must be really good. lol

 

I think that title of the book is Pragmatic Programmer not Programming

 

Great article! Lots of great resources to check out!