The conversation

tyreHNSource author
Lessons learnedExperience excerpt · English

For the latter: the same way there is a compounded risk of latency and failure with multiple …

… For the latter: the same way there is a compounded risk of latency and failure with multiple network hops, there is a compounded risk of mis-alignment with multiple human hops. I recently worked at a larger company (Stripe) where I was 5 hops from the CEO. Coming from startups, the information loss/skew between the CEO and my team was incredible. I found myself very much aligned with the CEO, but by the time it trickled down to our team the incentives, motivations, and direction were mildly fucked. Navigating that is part of the craft, which we can feel any kind of way about but doesn't feel entirely avoidable. "[X] will read [Y]" is a human fallacy, not simply a manager one. See: "just read the docs", "did you read the article you're commenting on", "the code is self-documenting", etc.

Original discussionTwo Types of Software Engineers148 source comments · at import
2

What was this responding to?

Parent context · original excerpt

LI
lifeisstillgoodHN

I would say that the person who says "we'll just document the process and people will follow it" is not a software engineer but a "manager" - someone who thinks they can offload their difficult bits to employees. The software engineer wants to offload their difficult parts to silicon. And would love the opportunity to code up a "process engine" that would ensure people can easily follow the process online. The takeaway for me is that managers who think they can offload to people have missed the tide - coders are the new managers because their workers are silicon, don't complain and so as they are told coders are the new managers because CPUs are the new workers.

Full original

Community replies 0

No community replies yet. Add your perspective.

Replies from the source 2

Direct replies available in this import. Original-language excerpts.

PM
pmontraHN

> As an engineering manager, I cannot imagine assuming that people would read something. Engineers read code when they have to work on it. If naming and structure are good, it will be self evident what that code does and why. Unfortunately it takes a lot of time to learn how to code in such a way that the author and coworkers can come to that piece of code six months from now and understand what it does. A corollary is that everything should be automated or made impossible to do, because even looking at the company's wiki is something that most people prefer not to do. Unfortunately it's difficult to know which automatic process is doing something, given that that something is a known unknown.

Full original
LI
lifeisstillgoodHN

I think we are in agreement. As for the five or more hops issue, I think software is giving a generational opportunity to rework our organisations. I think every company has two organisations - the first is the one that does the real work (think the bit that records how much money each account has in a bank). That first part is becoming / has become totally automated - it is a "programmable company". The second part (tries) to chnage the first org. Direct it control it alter it whatever. That's the part that has project plans and managers. The two organisations are merged and confused in most places - even the hierarchies probably should be seperate. The point being that four of the hops you had weee probably not in the first org. The alignment was perfect for what stripe actually is / does. The politics lies in what it wants to become - and that is a function of whether te people in the…

Full original
Continue on Hacker News

Respect different perspectives. Share concrete experiences.

Sign in to post, reply, repost, and quote.