5 ms·
As an engineering manager, I cannot imagine assuming that people would read something. Engineering managers think horizontally in an organization, with enough
by tyre 4y ago
As an engineering manager, I cannot imagine assuming that people would read something.
Engineering managers think horizontally in an organization, with enough depth in intra-team individuals and inter-team dependencies. There's a lot of similarities to software engineering: understand the product, know enough depth for what you're building, and understand dependencies on the edges.
Core pieces of these for an EM are fundamentals of human behavior, motivation, and process. There are global-ish truths about humans and global-ish truths about complex human hierarchy. For the former: individuals are more likely to get defensive when confronted in public.
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, which I could confirm by Slacking them. 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.
- pmontra 4y ago> 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.
- pjmlp 4y agoNon functional requirements aren't code, good luck writing code that reflects them.
- tcfhgj 4y agoit's possible, e.g. you can time code easily
- pjmlp 4y agoOne case among thousand possibilities of what a NFR is all about.
- tcfhgj 4y agoJust wanted to show that requirements being not directly reflected in code doesn't mean that they can't be tested against; Further investigation certainly makes sense
- lifeisstillgood 4y agoI think that 999 of the thousand can be brought into the virtual realm - and that companies that do so will find their ability to measure and chnage the important non functional requirements will be an advantage. Just some ideas: - speed (obvious) - capacity (that's fairly obvious too) - reliability (MTBF, incident count) - The Google Speed vs stability metric - usability (starts out as a toughie but if you record users mouse / UI activity then it becomes measureable - and this is kind of the point - the more HCI is captured and available to the "virtual world" the more these problems are within reach. the more software eats, the more it can eat. - scalability : scaling up or down? Measureable
- pjmlp 4y agoI am really curious how-to express MTBF in e.g. C.
- kodah 4y ago> 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. In early greenfield software, sure, but given the test of time this assumption will always fail. The reason is that each team that works on a given software has an operating context that's often undocumented. They use lingo and rhetoric that likely aligns to that and is illuminating now but when that lingo isn't as common it'll likely die off. The very idea that words of a contextual language will be exactly relevant in the future is a short-sight in its own. Writing a lot of docs has its own tradeoffs, but I do think it's worth pursuing principles of writing good notes. I'm oft fascinated by reading the comments on old code that remain durable.
- lanstin 4y agoAnd documenting the lingo, the concepts with which the software was designed is more important than some system diagram or call sequence charts or API stuff. (For the maintainers; API consumers obvi need something).
- lifeisstillgood 4y agoI 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 second orgabisation will keep power in the new place. Software means we can I think seperate the two orgs.
- tyre 4y ago> The politics lies in what it wants to become - and that is a function of whether the people in the second organisation will keep power in the new place. Yes, this feels partly correct. There is a meaningful part of all layers that skew towards self-interest. Every hop amplifies the skew and has fewer checks because it is less visible/accountable to the top level. The local maximum for someone reporting to the CEO is much more closely aligned with the long-term best interest of the company than someone 3 or 4 hops away. Something I learned was just how much success is dependent on one's manager. In early startups, executing on what's best for the long-term success of the company (including when that is short-term optimization) is a good career strategy. Maybe the best. In larger companies—or at least in this single anecdata point, though others have said similar things about other bigger companies—that's not so true. I found that sad.
- lifeisstillgood 4y agoYeah. currently experiencing that in very much clear terms.