Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

  • Hacker News
  • Why won't this site allow me to zoom on mobile? On desktop it works fine.
  • I wonder how this applies to personal projects. I find it hard to motivate myself to just "study a textbook". I do do so, but it almost always feels useless compared to actually doing something. It doesn't have to be grand, but it needs to be something I can at least "trick" myself into believing it's useful.

    Well, right now, I'm pretty happy and have a personal project that I'm very eager to have done and polished and see the result of. Hopefully life keeps throwing more of them at me. It's been a constant issue for me though.

  • The article content is both true and framed strangely.

    Does the author think "product customers" hand you a tidy list of requirements the stupid programmer automatons just have to translate into code? Obviously not. Customers also don't know what they want, or could want. Famously, they claim to want faster horses.

    Then the author goes on to list "crash led discovery", as if this was so different from prioritizing bugs in prod. Or, If you have no idea, just improving efficiency. Or talking to customers, err, users.

    All of this is true and none of this is any different from any of the other software, just translated into other lingo.

  • "inventing work" = "requirements engineering"

    "Inventing work" is a strange phrase to use imho.

  • I use the "what's going to kill us next" philosophy. Figure out what that is and do something to avoid it.

    Wash, rinse, repeat.

  • "that work does not exist unless an engineer invents it."

    This is so strange. To my mind the only purpose companies hire engineers is to support business. The staff engineer should not need a project manager to tell what is interesting for business aspects - even though the goals are likely mostly technical.

    I do realize this does not hold up always. But to me if you can't provide some reasoning for your work in business metrics you are participating in an academic exercise.

  • 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.

  • > Platform teams are engineering-led rather than product-led. There is almost never a product manager handing you a roadmap, no revenue line to follow, and no market to lose.

    It's precisely because of this framing and mentality that platform teams don't actually serve people well and are usually highly dysfunctional towers of people inventing work.

    The fix for having no market is to act like the teams you serve could leave. This whole article lists signals, and none of them is that. Being captive does not mean the users or internal teams don't have other options and don't notice. Being product-led means caring about your users. A platform teams should be product-led, not engineering-led in that very narrow meaning. Otherwise you invent work as this article so wonderfully exposes.

Explore Birbla archives