Hacker News Reader

Comment by niklasrde | Hacker News Reader

Do you think that's a bad thing?

writing code != building things.

In my org, seniors spend a lot less time building things: writing components, etc. They do spend a lot of time navigating office politics. But they are engineering specific office politics: how does system A interact with system B? What are the architectural implications? Ownership of long term data and technical and business strategies?

The "art" of negotiation can be ass-kissing but quite often genuinely with the goal to advance the projects they own and the enablement of the "people who actually build things", which at some point also involves the seniors. You need to build raport and relationships to negotiate seriously.

View on HN

I do think it's a bad thing, but not for the reason you think.

Promotion is an inherently political process. "Impact" is really short for "impact on the business leaders' opinion of me".

I think it's a bad thing when a promotion process that is political, pretends to not be political by dressing itself up with flowery language. What it leads to is engineers burning themselves out trying to deliver real value, then getting passed up because they didn't make the right appeals to the shadow council.

If we all know the process is political then we should at least work toward transparency, so that people know that it's not enough to work hard and deliver results, you also have to advertise and network yourself.

In the orgs that I have worked in, there were very few developers who could actually handle coding complex features and applications. The people navigating the office politics are important, but let's not pretend they are actually capable of pulling off the work. They can understand that "system A interacts with system B" at a high conceptual level, but are not capable of digging down at the detailed level necessary to make it happen.

My current org is the opposite. Loads of Very Smart Developers all building supposedly brilliant stuff in isolation for their fiefdom without any regard for how it fits into the bigger picture.

They don't need to. It's "very few developers who could actually handle coding complex features and applications" job.

I'm not the one you responded to, but I definitely feel like it's not necessarily a "good" thing or a "bad" thing. Having a senior be more involved in writing some functionality should mean more maintainable code with more complex issues factored in to the solutions, which should mean better predictability when it comes to planning new work.

At the same time, having seniors involved in more abstract discussions before implementation should also lead to better end results. That being said, having my engineers be involved in "ass-kissing" as you put it is honestly not a good use of their time. Leave office politics to engineering managers and project managers, in my opinion.

I agree that writing code != building things, but they're not disjoint either.

Senior who doesn't deliver (write code) is not a senior. Beating about the bush in meetings is easy, executing the stuff isn't.

Writing code is easy when you have a spec to work to. It more or less writes itself - see <30second submissions to Advent of Code last month (likely AI - but it doesn’t matter how it was written for this point; just that it was written and solved the spec).

Getting that spec is damned hard.

What do i mean by spec? Basically are you going to build the right thing. A hard problem - if you think it’s easy, it more than likely means you didn’t understand the problem.

The reason pinning down a spec is so hard is because at the macro level, there are very few actual solutions - mostly only trade-offs are available to work with.

>Writing code is easy when you have a spec to work to.

In my forty year career I never saw a spec that was anywhere near accurate or complete.

Sorry, I think that's delusional and if anything maybe only applicable to the very narrow and simple problem space. Nobody writes out the "spec" for the next best inference engine or the next best distributed database.

The senior needs to figure out that the next best inference engine or the next best distributed database are what needs to be built in the first place (or beating about the bush as you said). That’s hard. Lots of conflict to be explored.

Once it’s been captured what needs to be done (spec) enabling the rest of the team (execute) is comparatively easy.

Fail to spec, and the team can’t execute. They don’t know what needs to be built.

> Writing code is easy when you have a spec to work to. It more or less writes itself - see <30second submissions to Advent of Code last month (likely AI - but it doesn’t matter how it was written for this point; just that it was written and solved the spec).

I'm sorry, but it's hard to take your comment seriously when your definition of "spec" is AoC puzzle.

What is it specifically about an AoC puzzle that makes it not a spec?

Mostly the spec is crap and must be rewritten so…

Planning is very useful even though things never go according to plan, honest.

Also who writes the plan is completely disconnected from reality, so the plan is completely useless.

The context of this conversation is the actions of a senior developer. If the senior developer allows someone else to write the plan in isolation (thus allowing a completely useless plan to be devised), then they’re by definition of the senior role, not a senior developer, right?

A senior developer is not a passive position.

Reply on news.ycombinator.com