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!
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.
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.
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.
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. :)