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.
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.
I got it instantly. Maybe because I also am one of those people who go around finding problems in the product that are seemingly invisible to the product manager, team lead, CEO, etc.
It IS hard to try to explain an alien concept to someone when you yourself in fact understand it.
Well at least you don't call it "inventing work," right? I'm on a platform team too, would cause a lot of wtfs if someone said that in a meeting.
I also don't think it's excusable to say it's hard for others to understand. The good SWEs I've worked with knew how to explain what they do to partner teams.
aristofun · · focus · HN ↗
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.
aprilthird2021 · · focus · HN ↗
mahboi · · focus · HN ↗
Gareth321 · · focus · HN ↗
boxed · · focus · HN ↗
It IS hard to try to explain an alien concept to someone when you yourself in fact understand it.
mahboi · · focus · HN ↗
I also don't think it's excusable to say it's hard for others to understand. The good SWEs I've worked with knew how to explain what they do to partner teams.
aprilthird2021 · · focus · HN ↗
boxed · · focus · HN ↗