harisrid Tech News

Tell me what’s your favorite part about working as a senior software engineer?

Tell me what’s your favorite part about working as a senior software engineer?

That’s a really good question.

I derive tremendous satisfaction from collaboration and working with more senior talent than me. Even with my years of professional working experience, I still take pride in being a mentee and working with strongly experienced individuals.

I admire the calm, composed personalities and demeanors of the older folks on my team – their experience level, their communication skills, and their 1:1 or group coaching skills shows up. When I go into a meeting with a person with years of experience, I can feel their presence – their aura – “light up a room” ( what some might label “executive prescence“) .

Even during times of a crisis or a pressing deadline, they demonstrate optimism and steadfastness; they navigate organizational blockades with relative ease, they see how to scope down complex products to simpler deliverables, and they still meet end customer expectations. Basically, you can say that “they know what they are doing”.

Can you identify what makes parts of your job challenging ( for you )? Give me an example of one or two things that makes your job hard for you? What aspects of a job do you find harder than others?

That’s an insightful question. Lately, my biggest challenge has been figuring out future directions and scoping out a list of features.

When I was a junior engineer, figuring out what to do was relatively straightforward – a more senior engineer created the tickets, assigned me work, and instructed me how to code up the feature ( with hints at helpful parts of a codebase or code structures to look at ).

But now, I’m more senior : my responsibility is less about writing code. Now I’m tasking out and figuring out future direction and delegating work to others. Harder to do, for a plenitude of reasons : customer requirements frequently shift, the future is an unknown, and hindsight is 20/20.

Sometimes, what I task out isn’t “always correct”. Tasks get scoped out to different time periods or planning sessions.

I’ve had experiences where I’ve written up a design document for a potential multi-quarter organizational effort, only to realize that we as an organization didn’t need to do that work ( or we had to do that work, but in a completely different manner ).

I’ve also had the experience where I did make the right stories, but the work has to be done three months or six months later, when dependencies have been resolved and feature releases are productionized, stable, and ready.

Was my work wasted? Absolutely not. As a senior staff engineer put it, most of what we do always makes for good learning experiences. The level of cognitive thinking and deliberate thought put into such endeavors never leaves – it stays.

What else makes being a senior software engineer challenging?

Hmm … let me itemize them. There’s challenges that both myself ( and others I’ve talked to ) have identified :

• Delegating and Trusting others – the more senior you get, the less time you get to spend on low-level code details. Sure you may review code and provide your input on some technical suggestions, but that’s about it. Outside of this very myopic scope, you have less visibility into your codebases. You’ll have to trust and rely more on your junior engineers to mid-level engineers to make the right choices. Release your control.
• You’re both a manager – and you’re not, a manager – there’s an implicitly-spoken expectation or rule that senior-plus individuals need to demonstrate some form of “leadership”, even if it’s “informal”. BUT, you’re also not a manager. You can’t exactly “boss” around other engineers ( as much as you’d like to ) or instruct engineers on what they should or they shouldn’t be doing, BUT, you can expect to see yourself take on a more advisory/mentorship-esque role where you’ll provide a more informal form of guidance.
• Scope Creation = you can’t just expect your leadership & management to always create scope ( e.g. your project complexity level/organizational impact ). Onus rests on you ! And you’re not just creating entry-level engineering scope ( e.g. a one-week refactor ticket ). If you’re say, staff+, you need to help identify scope for a senior engineer ( e.g. can you identify long-term organizational quarter-long features or design task and get a senior engineer to collaborate and lead the efforts with others )?
• Teaching and training skills – Teaching is part of the role, and you’ll have to teach skills across different areas – coding, design, some Linux commands, technical writing, and diagramming. Everyone comes in with different backgrounds, understandings, and nomenclatures, so identifying what to teach ( and how to tailor your approach ) is an endeavor. Not only that, but mentorship is a hard skill – learning skills is a lot easier than teaching skills. Some of my more difficult instructive moments have been less about coding, and more about working through tasks or designing systems – I had that conversation one day with a junior engineer where I had to teach concepts on automated testing, API endpoint versioning, and the metastable failure problem of distributed systems. These were enlightening moments, because I was backfilling on design thinking – skills that would serve him powerfully in his long-term future.
• Develop or Deploy – Pick One – How do you build an application, within a deadline and a tightly constrained environment, that satisfies your end customers needs? But at the same time, you make sure to pre-empt a business crisis and build the scaffolding & structures needed – security, rate limiting, auto-scaling, and performance? It’s tempting to want to keep on building, but there’s a point where engineering talent has to band together and say “Hey, let’s sign-off on the feature release”. At some point, we have to be pragmatic and content with what we have.

What part of your jobs do you derive less satisfaction much? If you could delegate a task off, what would you delegate?

I struggle tremendously with working on tasks related to setting up a local development environment or debugging environment set ups. Like a lot of engineers, I like it when I can immediately “hit the road going” and start writing change lists or productionizing features. Setting up and configuring a development environment can take a few hours, spread across a couple of days. Nonetheless, it’s a useful skill. And I want to go with the belief that the more often someone sets up an environment, the less work they have to invest spinning up and setting up environments.

What gave you the most surprise about your role?

The biggest revelation ( to me, that is ) is that more you “level up”, the less you code, and the more you communicate and talk to other people.

You’d think as a junior engineer that your senior engineers write more lines of code or work through more technical work.

On the contrary, I find that senior engineers are less engaged in code writing. They’re more engaged in all the other tasks that support an organization – reviewing code, menotrship, designing systems, communicating with stakeholders, or technical documentation. You could say that they do everything else to “make the world spin”.

This transition can be hard. Most of us came into our profession as passionate coders ; I’d imagine a lot of us secretly want to spend a six-hour day by ourselves on a weekend ironing out a mobile application or a game.

But I’d also argue that this is a good thing. There’s a joke that the best code is no code at all ( see https://blog.codinghorror.com/the-best-code-is-no-code-at-all/ ), and there’s truth to that ; any code you write is error-prone and bug-prone in run-time. But there’s also truth that the more you code, the less you write, because you know how to take efficient paths and shortcuts and you also know how to express your coding thoughts more concisely.

What piece of advice would you give to a junior or someone starting a new?

Learn the value of listening more and speaking less.

Yes I know you feel those feelings of anxiety of “If I don’t speak.” or “If I don’t say something for five minutes in a thirty-minute conversation, I’m no good”.

No this isn’t true. Actually, I want you to sometimes imagine you’re a student in a college-lecture style setting, where you need to listen attentively to your instructor.

Because even if you’re not speaking, you’re doing other things.

You’re listening. You’re learning. You’re absorbing new information, and new context.

Skills that serve strongly in future positions, like leadership or the C-suite, where it’s more crucial to listen and take in the inputs of the others in the room before making final decisions.