"inventing work" = "requirements engineering"

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

arealaccount 5 hours ago | parent | next [-]

I thought this was going to be an article about slacking off with style

	▲	Insanity 4 hours ago \| parent \| next [-]
		Well I was thinking more align the lines of pure "promoware". I.e, find something to build that'll get you promoted but is useless beyond that.
	▲	giancarlostoro 2 hours ago \| parent \| prev [-]
		Just tell everyone Claude is still working on it, even if you don't use AI.

▲

qrush 5 hours ago | parent | prev | next [-]

Agreed. A better framing would be "defining work".

	▲	theanonymousone 5 hours ago \| parent [-]
		Or "proactive engineering"

▲

pradn 3 hours ago | parent | prev | next [-]

It was clearly a "tongue-in-cheek" framing. Got me interested at least!

▲

theanonymousone 5 hours ago | parent | prev | next [-]

In their defence, requirements engineering sounds somehow reactive to me, while "this thing" is kind of proactive, for what it's worth.

▲

mytydev 11 hours ago | parent | prev | next [-]

I was thinking the same thing. The word that I would be more inclined to use is used multiple times throughout the article. Discovery.

	▲	nmehner 3 hours ago \| parent [-]
		Agree. Discovery is probably an even better term.

▲

groestl 5 hours ago | parent | prev | next [-]

I think it's a fundamental difference in philosophy. Does the work exist, and you discover it? Or does it start existing as soon as you think about it? This person seems to subscribe to the latter world view.

▲

cush 4 hours ago | parent | prev | next [-]

yeah I thought the post was going to be satirical

▲

tessierashpool 30 minutes ago | parent | prev | next [-]

> "Inventing work" is a strange phrase

The author used an LLM. The first paragraph has two em dashes (turned into hyphens) and a typical overlong list. The second paragraph has an em dash the human author turned into a semicolon, and the third has one he turned into a colon. The fourth paragraph does the colon substitution several times.

The fifth paragraph is so obviously machine-generated I don't understand why people are even discussing this blog post at all:

This is the other cost - invisible to many, sometimes including the ones who handle the toil work. Every team has toil, and it is almost never prioritized. But you already knew this one, so I won’t spend more words to say that toil is an important signal that there is work waiting to be discovered.

If all you want to do is post prompt outputs on your blog, I think a) you should be honest about it and b) you have an obligation to write very interesting prompts.

Might even be more useful to just share those.

▲

gloryjulio 4 hours ago | parent | prev [-]

Requirements engineering still applies to senior engineers. You are given a problem and you need to work out the requirements and the path to completion.

But for staff engineers, they need to to discover the scope themselves. That's where "inventing" coming from. Not saying inventing is a good word here, but requirement alone is not enough for staff level's work

▲

nmehner 3 hours ago | parent [-]

"Requirements Engineering", "Writing Code", "Writing Documentation" are all areas of work that are independent of seniority in my point of view.

I might send a junior to a well-meaning customer that already knows exactly what their requirements are to just document them and learn the process. Or I might require a principal engineer for the requirements engineering of: We need a new programming language. Let's figure out the requirements for it and what abstraction level is actually feasible for the target hardware platform.

Same for writing code: A junior might write code, a staff engineer might write code. Just likely on very different levels.

If an engineer comes to a manager and asks for budget for work they invented, I'd expect the answer to be something along the lines: "That is nice, but can we please focus on the stuff we are required to do?" That alone would be reason enough for be not to put ideas that way, but to come up with a requirement why it makes sense to do the work.

	▲	gloryjulio 3 hours ago \| parent [-]
		You are not talking about the expectations in terms of the corporate levels. Staff and senior have clear definitions in tech companies. A staff(l6) is the team lead who is required to find the scope for himself and team. That's in his job description. If he can't do that he would get pipped or fired. A senior(l5) is the tech lead on the project level. He is not in charge of handling the team's scope. As long as he handled his own projects well, he would usually pass the review cycle. The difference is crucial. At staff and above, the engineer's responsibility is vastly larger than a senior's. I am not saying a senior can't do a staff's job - that's how he get promoted once he demonstrated that he is operating at a staff level, i.e "inventing" scope for his team. But a senior's scope is much smaller than a staff's. This applies to almost all US medium to large tech companies