‹ BackHN Continuity

Thread

A Staff Engineer's Guide to Inventing Work

380 points · 93 comments · amortize

  1. aristofun · · focus · HN ↗
    This article is a good demonstration of what is deeply wrong with today’s corporate IT. And why any big enough company will sooner or later rotten. And why work at such a company these days feel so meaningless and mundane.

    For example

    > Thankfully, the signals that help us to invent work are already out there, and they arrive from four directions - from the systems, from the users, from your organization, and from the industry. What follows is a guide to reading each of them.

    In a good “ideal” org the only source of requirements should be users, aka customers, aka real people, user facing products, teams etc.

    There must be no room for speculations and “engineering” (aka over engineering), nor performance review driven development.

    I would personally fire anyone “inventing” work. Even if it’s myself.

    1. aprilthird2021 · · focus · HN ↗
      Why do so many people in this forum not understand the article. He is not literally inventing work. He is finding out what work needs to be done by reading the signals. Users and customers don't often know or care about the requirements of your system (are users and customers going to tell Facebook what it needs technically to handle a surge in users for its new AI that gives everyone on Earth a private VM to mess around in?). That's why you hire engineers. To figure out what needs to be done to keep serving the product, which is what users actually care about.
      1. aristofun · · focus · HN ↗
        > Why do so many people in this forum not understand the article

        I understand it deeper than you think.even maybe deeper then author think he does.

        The only singals that matter i already mentioned. Everything else must submit to this ultimate goal. If that’s the case there is no reason to invent anything even metaphorically speaking. And platform requirements arise naturally to exact extent the user problem justifies, not more not less etc.

        This is probably a fundamental philosophical division between “engineers” who love to engineer for the sake of engineering, who are arrogant enough to treat their trade as an art form even.

        And between mere mortals, regular engineers, who are hungry for solving real world problems as efficiently and quickly as possible.

        Instead of figuring out the mess and navigating the peculiarities of another “platform team” in a big org.

Open on Hacker News to reply ↗

Unofficial Hacker News client; not affiliated with Y Combinator.