4 ms·

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

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.

bombolo 4y ago
How do you offload to silicon periodically creating a new private key to sign your future releases, but keep it far away from your builds until you actually will use it, but put its public key on the builds.
- ttymck 4y ago
  Something like https://www.vaultproject.io/ https://www.vaultproject.io/ or similar?
  - bombolo 4y ago
    If you're content with using cloud storage as "secure"…
    - looperhacks 4y ago
      You can run vault on your own infra
      - contingencies 4y ago
        Type 2
      - bombolo 4y ago
        Still less secure than not have it online?
salawat 4y ago
I'd say that if you haven't realized that as a doftware engineer, you are essentially enriching the capital wielding class and are essentially just their means to being able to wash their hands of the masses, you're probably either asleep at the wheel, see yourself as a temporarily inconvenienced billionaire, or really have no choice but to further that aim to achieve whatever your own goals are. The push for AI isn't even trying to reach further than can be grasped; it's the ultimate lottery ticket to the well-to-do.
- vanviegen 4y ago
  The same could be said about many innovations that most of us would call progress in hindsight.
- maxfurman 4y ago
  This is literally any worker? If you don't have a stake in the company, your bosses profit more from your work than they pay you for it, almost by definition.
  - neon_electro 4y ago
    Even if you do have a stake in the company, often the company controls the contract governing that stake, especially if you don't really own the stake you are promised (options). "Equity" feels like a mirage, often.
- pixl97 4y ago
  Oh, then I guess you better vote in a government that doesn't maximize gains for the wealthy. But taxation doesn't go well with the libertarian types here on HN. A few of us are millionaires in the capital class, and the rest are 'temporarily depressed millionaires' thinking we're moments away from enacting our own get rich scheme.
- post-it 4y ago
  > or really have no choice but to further that aim to achieve whatever your own goals are. I mean yeah. That's everyone.
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 ago
    Non functional requirements aren't code, good luck writing code that reflects them.
lamontcg 4y ago
> 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" In general this kind of attempt to automate humans is what kills companies as they get bigger. More rules and policies, written assuming the humans involved are all idiots and need to not think for themselves. And then instead of doing the hard work to standardize the systems, just offload all the quirky little differences that have accumulated over a decade onto the humans to try to keep straight, accumulating in a bunch of incredibly poorly written and maintained runbooks or whatever.
roncesvalles 4y ago
I've had this realization recently that software engineers are making far more (multiple orders of magnitude more) "business decisions" for the company than middle managers and MBA types. SWEs are essentially coming up with and codifying the logic that defines how a corporation operates on a very precise level. They're like "officers" more than commodity workers.
- neon_electro 4y ago
  This isn't just "business decisions", it encompasses "product design" at a very core level too. It's a lot.

bombolo 4y ago

How do you offload to silicon periodically creating a new private key to sign your future releases, but keep it far away from your builds until you actually will use it, but put its public key on the builds.

ttymck 4y ago
Something like https://www.vaultproject.io/ https://www.vaultproject.io/ or similar?
- bombolo 4y ago
  If you're content with using cloud storage as "secure"…
  - looperhacks 4y ago
    You can run vault on your own infra
    - contingencies 4y ago
      Type 2
    - bombolo 4y ago
      Still less secure than not have it online?

salawat 4y ago

I'd say that if you haven't realized that as a doftware engineer, you are essentially enriching the capital wielding class and are essentially just their means to being able to wash their hands of the masses, you're probably either asleep at the wheel, see yourself as a temporarily inconvenienced billionaire, or really have no choice but to further that aim to achieve whatever your own goals are. The push for AI isn't even trying to reach further than can be grasped; it's the ultimate lottery ticket to the well-to-do.

vanviegen 4y ago
The same could be said about many innovations that most of us would call progress in hindsight.
maxfurman 4y ago
This is literally any worker? If you don't have a stake in the company, your bosses profit more from your work than they pay you for it, almost by definition.
- neon_electro 4y ago
  Even if you do have a stake in the company, often the company controls the contract governing that stake, especially if you don't really own the stake you are promised (options). "Equity" feels like a mirage, often.
pixl97 4y ago
Oh, then I guess you better vote in a government that doesn't maximize gains for the wealthy. But taxation doesn't go well with the libertarian types here on HN. A few of us are millionaires in the capital class, and the rest are 'temporarily depressed millionaires' thinking we're moments away from enacting our own get rich scheme.
post-it 4y ago
> or really have no choice but to further that aim to achieve whatever your own goals are. I mean yeah. That's everyone.

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 ago
  Non functional requirements aren't code, good luck writing code that reflects them.

lamontcg 4y ago

> 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" In general this kind of attempt to automate humans is what kills companies as they get bigger. More rules and policies, written assuming the humans involved are all idiots and need to not think for themselves. And then instead of doing the hard work to standardize the systems, just offload all the quirky little differences that have accumulated over a decade onto the humans to try to keep straight, accumulating in a bunch of incredibly poorly written and maintained runbooks or whatever.

roncesvalles 4y ago

I've had this realization recently that software engineers are making far more (multiple orders of magnitude more) "business decisions" for the company than middle managers and MBA types. SWEs are essentially coming up with and codifying the logic that defines how a corporation operates on a very precise level. They're like "officers" more than commodity workers.

neon_electro 4y ago
This isn't just "business decisions", it encompasses "product design" at a very core level too. It's a lot.