I let Twitter select my next blog post, and 50% wanted to know what was it like in the shoes of a senior developer! I've been settling in to the title for the last 11 months, and I'm happy to share my experience and how my responsibilities have shifted from mid-level. All of this will be in the flavor of mobile development. The primary differences between mobile and web at this stage, from my perspective, is that mobile developers are also responsible for continuous integration and deployment.
This list is inclusive of my experience and what I've observed at other companies I've worked in. My experience is mostly enterprise app development. If your experience is different, I'd love for you to highlight your responsibilities in the comments!
Solving problems
I'm not talking about code! Things arise all the time that need immediate attention. As a senior dev, it's my responsibility to make sure my team is not blocked by anything, shine light on problems that will help get them resolved faster, or if it's in my wheelhouse, jump in and help out! It could look like an environment problem, a code problem, a build problem, a business problem, whatever it may be. It's my job to ensure things are moving forward, and waving the flag for attention if it's not so we can address it quick and effectively.Mentoring
A big change for people as they go from mid to senior is they are the ones providing advice and guidance to their team instead of purely absorbing. A quick reminder that everyone is human and we're all sharing and absorbing constantly. For many, this is the first time they've really sat on the other side of the table, and it's great! You're responsible for shaping your new and junior team members to some day take your job. Or at least that's the idea, while you move on into architecture or management, or wherever your heart desires. It is your responsibility to ensure they have the support and tools they need to fully grow into the position and career.Providing actionable feedback
This is a big one that will show up almost every day. As a senior engineer, you need to be driving the codebase, product and team in the right direction. Apart of that is providing actionable feedback to your teammates that will help reach the end goal. Whether it's official performance reviews, code reviews, pull requests or a pairing session - your feedback is necessary and crucial to your teams success. Learning how to provide feedback that is helpful is critical. Instead of "this could be improved" - elaborate. How could it be improved? What is the original author missing that could help them see the problem. Positive feedback fits here too! "I really like the way you took charge of that meeting" - we all need positive feedback to learn where our strengths are. Let your team know you appreciate them.Keeping an eye on all the things
This one is a bit much at times, but it's really important to keep an eye on reviews, crashes, analytics, dashboards, abnormalities, test coverage, builds, etc. It's good to check in with your systems every few days to ensure everything's a go. Is code coverage trending in the right direction? Are unit tests functioning after that last Xcode update? Any new crashers with the latest release? Any bad events surfacing to the top, or an abnormal amount of unexpected ones? As a team, keeping an eye on these things will help you be proactive should a problem arise. In previous jobs, we found analytics and crash data to be a very valuable combination to use with our remote feature manager. With seeing a rise in crashes, we were able to take action and turn off a remote feature flag to ensure clients would no longer be effected.Identify problems and feature planning
As one of the codebase owners, it falls on you to identify any tech debt or refactor spots, and come up with a plan to tackle them. It also falls on you to help architect features and plan for how long a feature will take, to help "business" requirements and expectations.Build
Especially true as a mobile engineer, the build pipeline will likely fall in your court. Keeping your Continuous Integration pipeline happy, building out improvements, keeping the build passing and unit tests passing all falls on you (and your team). You can certainly share the responsibility, but you're ultimately in the driver's seat is what I'm saying.Giving credit
This ties closely with number three, providing actionable feedback, but I wanted to call it out specifically here. When you're working with someone else and do a feature together, let them drive. Help them get to the answers, but don't do everything for them. Tied also with number two, mentoring, you're there for their success. Their success means your success, and your teams success means your success. But highlighting your accomplishments solely is (mostly) over. When you're driving a team, it takes everyone, and it's up to you to call out when people do good, when your team delivers, and the features you all flush out.
Thanks so much for reading, I'm really enjoying being a Senior iOS Engineer! While my imposter syndrome does get out of control some days, I'll share some wisdom that really has helped me this past year. Teams work because everyone brings something unique to the table. If you have a weak spot, someone else is going to have that as a strong spot. You don't have to know everything, now go uplift your team and get some stuff done. :)
Top comments (8)
Some of what you list is probably better done by whoever wears the "Scrum master" hat, and some of it is better dealt with by whoever wears the "devops" hat.
The "sad" fact, is that if your employer doesn't pay people in those roles that I put in quotes, then yes, it is the Senior Developer that does it.
As you move up, through Lead to Architect the workload gets more hectic, and you have more meetings with 3rd parties etc. If you go the Dev Manager route, you get to delegate more, but only if you have a good team (and deciding on the team is your responsibility).
Unfortunately, I'm Architect and Dev Manager. So today I've been helping a junior through IDE setup, while talking to a director about options for ROI on a new project, and everything in between.
You're right! As I stated, my experience is coming from mobile, where there really isn't a market for Mobile DevOps. It's fallen on Senior Engineers at all of the large well known companies I've worked with.
I agree on all your points. As devs move up the ladder, the role becomes more about managing people than building code. I've been in the senior role for a few months now and what I can say for my experience is that I'm about 30% code, 30% people, 40% presales work. My role is essentially helping out my devs so they can focus on delivering the features on time and with as least bugs as possible.
I do want to add an 8th item on your list. For my experience, that has been building processes to help the team function more smoothly. From the git pull request process to sending daily updates, to how to handle change requests. Having a process for these kinds of things help the devs function more smoothly because they know what to do.
Do you not find that the daily updates and processes for everything hurt overall adaptability?
I have once worked at a company that, I kid you not, had a "process for creating processes."
Day to day things, like how to use Git, sure. Have a process, have everyone working the same way. But sometimes there's a guy on the team that hasn't had enough coffee that morning and screws up a commit. You need some people on the team (even if it's only 1 person) that can think outside the box while under pressure.
Same argument stands for all business processes... though those times should definitely be the exception, and not the rule.
There's a balance right - I've been on both extremes and I appreciate a good flow lol. It helps everyone, but there's certainly a tipping point where the processes are suffocating, and no longer serving the purpose of the process in the first place.
Hello, interesting how you see a senior developer and compare it to "mid-level developer" (which make more sense than with a junior developer). Around me, it's more called "technical leader (of the developer team)", which is also distinct from scrum master and team manager. But senior developer and technical leader are very close. Perhaps a matter of time spent in meetings rather than developing with the team :D
I'm a senior front-end engineer (web focused), I built our pipeline and actively maintain it. Though I'm working with a mid-range that's interested in ownimg it, which is a big part of our mid->senior progression. It depends on the company for sure, ours emphasizes ownership of the entire product. We encourage engineers to get involved from idea conception all the way through deployment even to the point of working directly with customers on getting their feedback, which I own jointly with our designer.
I saw a very interesting talk, also in this direction: