Senior Developer Means Coding... Less?! - Dev Leader Weekly 85

Senior Developer Means Coding... Less?! - Dev Leader Weekly 85

TL; DR:


Starting With A Disclaimer

As with all things (especially in software engineering):

It depends.

You and I both know that I can't sit here writing an article that has a universal truth that either senior software engineers do or do not "code less". There are simply too many variables and too much variety to try and declare an absolute.

Less than what? Where do they work? What expectations were given of them?

As with everything I write, this is my perspective from my experiences. And to kick things off, you might find that this video on Code Commute does a good summary of things:

What's Expected of a Senior Software Engineer?

I'll refrain from saying, "it depends" again (even though it's applicable) and instead try to offer you a good source of information that will be more applicable to each reader as an individual:

Ask your manager. And if you switch teams or organizations or companies before you become senior or while you are a senior developer... ask your manager again.

You're about to hear my opinion and perspective, which has bias built into it and may not be as applicable for you in your situation. But theoretically, the best person to give you insight and guidance into this will be your manager. Their role should include supporting you in your career growth, and that means ensuring level-set expectations for what senior developers should be doing. And it'll change from manager to manager, team to team, and company to company.

But I wanted to highlight the things that I've seen remain consistent:

  • The complexity of the domains you are working in will increase.
  • The ambiguity around the problems you're solving will continue to increase.
  • The breadth and significance of impact resulting from your work will continue to increase.
  • The circle of influence you are growing (and expected to be interacting with) will continue to increase.

By definition, none of these expectations inherently mean or suggest "do less code", but each one of these may suggest there are other skillsets you'll need to improve and exercise more regularly:

  • More time spent problem-solving
  • More time spent clarifying ambiguity in problem spaces
  • More time spent interfacing with stakeholders from different teams
  • More time spent mentoring the more junior teammates on your team
  • ... Likely more project management overhead coordinating large efforts across teams

What Should You Prepare For?

I figured I'd do up a list of more tangible things for you to consider. In some cases, you may not have such experiences when you're more junior. Some folks reading this will have different mileage on some of these as they had more exposure at junior levels -- and that's great!

Design Reviews: Yes! Something technical! You should anticipate that you'll be involved more with leading design reviews but also participating in reviewing the designs of others. Now, this will of course look different and take different forms depending on where you work. However, this could include things like putting a design document together, leading design discussions on your architectural proposals, and even presenting the outcome of architectural decisions to a larger audience for visibility/transparency. Expect to be a participant on more of these reviews as well as your technical experience will be a great asset! This will mean that communication and understanding the audience that you're speaking to will become incredibly important. These types of conversations often bring very strong opinions out -- and your job isn't to be the person who wins with their opinion. Your job is to create the best solution.

Project Status Meetings: We all hate meetings. I get it. Given the scope of impact you're having, especially having more opportunities to lead larger impact projects, it's very likely you'll be interacting with a wider variety of stakeholders. This means you'll have more surface area in terms of the number of people but also a variety of roles that you'll need to collaborate effectively with. Now, "meetings" in this context can be generalized to just "project status sharing" in whatever form that is for you... but you may very well find that you're representing projects or parts of projects as a stakeholder with ownership over the area. Clear communication will be paramount. You'll need to focus on understanding dependencies and timelines so you can bring awareness to other stakeholders if things are changing course. If you have project managers (and related roles) to interface with, these folks can be a huge asset to learn from and collaborate with.

Mentorship: In all of my years of managing engineering teams, one of the most common things that I see as an expectation of seniors is being able to mentor more junior developers. I've certainly seen the expectation of the amount of mentorship vary, but I've always seen this surface from my experience. Mentorship and helping out others absolutely takes time. You might even find that as you're becoming more senior and you have alllll of these other things taking your time away from coding that mentorship and coaching becomes frustrating. Why the heck should you have to do it anyway when you have more code that you could be writing? The more junior developers will be trying to emulate your behavior, and if you can be part of helping them become more effective sooner, that means it's a shorter time horizon before they're helping YOU. This will take patience. This will take communication. This will take understanding that you can't simply just give people answers and expect them to get better. But it's incredibly rewarding.

But What About The Code?!

Look -- the code isn't going anywhere. The reality is that as you get more senior as a software developer, your technical skills are expected to be ever-increasing. They're going to be a fundamental part of what enables you to deliver on work.

The significance of calling out everything else in this article is that the expectations on all the other areas will be increasing -- so you can't ignore everything outside of code.

The reality is that likely:

  • You'll be reviewing more and more code
  • You'll be spending more and more time writing and reviewing software architecture
  • There will be bigger and scarier bugs for you to dive into understanding and fixing
  • You'll have more responsibilities around the code base often by having history associated with it

When you're at senior level, you'll be expected to have a sharp understanding of what's going on in your team's code --and if you don't know, you know how to get the answer. So it's not like the code vanishes from your life, but you will have all of these other things to start balancing your time with.



Get this bundle now!

As always, thanks so much for your support! I hope you enjoyed this issue, and I'll see you next week.

Nick “Dev Leader” Cosentino

[email protected]

Socials:

Blog

Dev Leader YouTube

Follow on LinkedIn

Dev Leader Instagram

P.S. If you enjoyed this newsletter, consider sharing it with your fellow developers!

Shawn Ashworth

Senior Software Development Supervisor at UPS

1 天前

I code a lot, I considered myself a hired gun. Figuring out how to implement the next new thing, reverse engineering legacy stuff, advising on architecture and mentoring ..and yes lots of meetings.

Sobia Soomro

Driven to Develop Engaging Websites as a Front-End Developer | Skilled in React, JavaScript, HTML, CSS, GitHub, UI/UX & WordPress

1 天前

Senior developers take on more responsibility, but coding isn’t always off the table.

Anton Martyniuk

Microsoft MVP | Helping 20K+ .NET Engineers Advance their Careers in .NET and Software Architecture

1 天前

Senior engineers code a lot. Architects and Technical leads much less

要查看或添加评论,请登录

Nick Cosentino的更多文章