Comment by bbarn | Hacker News Reader

Comment by bbarn | Hacker News Reader

The same old argument is really all that's in play here. "I want to spend most of my time doing the technical task that I'm skilled at, and not dealing with other people".

Developers add value in so many more ways that heads down concentrating on code. A senior engineer should spend the least amount of time coding compared to everything else they do during the day. If they don't, do you really need a senior engineer? How much of a 4 hour coding session is something you needed specific expertise in and how much is mindlessly typing the syntax with a big of logic peppered in?

If your tasks can all be done truly asynchronously without blocking someone else, they probably aren't very exciting or special. Having worked for many years in both office 9-5s and global async teams, async teams are incredibly frustrating to organize if the work requires any collaboration. In a perfect world sure your 4pm is my 8am and we can work there, but factor in real life, people leaving early, coming in late, and it becomes incredibly annoying to deal with in practice. It takes much more management overhead, and you truly have to ask if the benefit you get from having engineers async is really worth that extra overhead. I would argue in most markets it just isn't. I would take a 20% worse engineering staff all working together than the alternative of a better staff split into different time zones. This is coming from someone who lives in Iceland and has had to work async for the bulk of my projects in the last few years. I found the lack of human contact and collaboration so boring that I took a big paycut to work with people again every day.

>A senior engineer should spend the least amount of time coding compared to everything else they do during the day. If they don't, do you really need a senior engineer? How much of a 4 hour coding session is something you needed specific expertise in and how much is mindlessly typing the syntax with a big of logic peppered in?

What else are they supposed to be doing? If requirements are fleshed out then all you can do is get started. The bigger the change, the more you'll have to be concerned about architecture and implementation details. I think sitting down and thinking about the problem before you code is necessary for any dev, but I'm here to write the solution at the end of the day.

>If your tasks can all be done truly asynchronously without blocking someone else, they probably aren't very exciting or special.

My company right now is about 15 people, 5 of which are engineering (including myself). When your team is that small, you don't have room for too many specialists. We're all capable individuals that can do the work without waiting for anyone. I'll get a ticket asking for a new web page, a new backend endpoint, DB updates, Et Cetera and it's the expectation that I do this all by myself. If there's something out of my wheelhouse, I can lean on my team but this is the exception and not the rule (and can still be done async). I don't know what special looks like for you but I can list the contributions I've made and the impact it has for our bottom line. In two months I reduced AWS spend by $5k/month, added payment enforcement logic netting us tens of thousands within the first week of its release, and seamlessly added a Huggingface NLP model into our AWS infra (our DevOps guy doesn't even know ML, he just treats the Sagemaker instance like any other resource). That's pretty impressive to me.

A senior engineer is someone you can point in the general direction of a business problem. They rarely get requirements, and never fleshed out. Their job is to understand the problem in consultation with stakeholders, guide a team through execution, and maybe but not always write or debug some critical parts.

As a senior engineer, if I told my manager in a performance review that I mostly worked alone on tickets with well defined requirements, I’d be on PIP immediately and probably fired a month later.

>A senior engineer is someone you can point in the general direction of a business problem. They rarely get requirements, and never fleshed out. Their job is to understand the problem in consultation with stakeholders, guide a team through execution, and maybe but not always write or debug some critical parts.

That sounds more like a manager or architect than an engineer. Engineers should take a proactive role in discovery and talking with business to figure out the best place to create value (that's a once a month meeting for us), but at the end of the day it's up to the PO to translate business needs into product development. Either way, I doubt you need 4+ hours a day to flesh out the technical requirements. When I worked at bigger companies, I'd spend only roughly 4 hours coding a day too. It's not because the problems were harder, but because there were blockers at every corner due to siloing and overly complicated business processes. I'd spend days in meetings and escalation emails just to get a networking rule exception.

>As a senior engineer, if I told my manager in a performance review that I mostly worked alone on tickets with well defined requirements, I’d be on PIP immediately and probably fired a month later.

Then you're a sucker. Engineers are supposed to write code. Even at the bigger companies, all senior engineers (and I mean 15+ experience) wrote code most of the time and did everything in their power to avoid meetings and other disruptions. That's how I learned about the "Law of Two Feet". Business expects you to coordinate between stakeholders and the rest of the engineering team. What's next? Should you manage the team's budget as well? Make long-term product roadmaps? Get yourself a promotion!

Managers are responsible for careers: hiring, development, satisfaction, promotion, visibility, and so on. Senior ICs (L5+) are responsible for the work. They own their products and domains, including architecture and long-term roadmaps, and are ultimately accountable for its impact. I did get myself that promotion... it was called Senior Engineer.

We have people who do JIRA tickets specified and prioritized for them ahead of time by others. They are called Engineer I and Engineer II. They don't get paid nearly as much or have the autonomy and recognition that senior engineers do. Most of them are biding their time waiting for managers to finally find projects they can drive instead of help with, so that they can finally demonstrate senior competencies and get the title themselves.

I guess it's just a difference of nomenclature theb. FAANG (especially Amazon and Microsoft) are just so big that the stratification creates a lot of roles to facilitate the org. Even at my old company (~5500 staff), our managers only owned one product but I guess your RM would have an entire portfolio.

> My company right now is about 15 people, 5 of which are engineering (including myself)

The problem with posting any comment on here, is I have to always preface everything with "Generally speaking" I assume it's implied, but yes - you will always have cases where something isn't true. Tiny companies is one for sure, but tiny companies with 5 engineers, well collaboration isn't as much of an issue.

Most of us work at bigger companies than that (I would argue even on HN). I too have lived in the world where I was DBA, front end designer, API designer, infrastructure, and even contract negotiation, and that's a whole other ball of wax. It's also not what the original post is really talking about in my opinion. Companies like yours are not the ones trying to do in office work remotely, and those are the types of companies I am talking about.

On a side note your job sounds either fun or stressful as hell to me. I can't decide. I hope you're enjoying it and being paid well :)

It's my first startup, but so good so far. I chose one that was older (8+ years) and had a fun stack (Clojure). Doesn't pay as well as FAANG but I get some cool lottery tickets (RSU) out of it.

Reply on news.ycombinator.com