Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Appearing productive in the workplace

nooneshappy.com

Post reply on HN
Print view View original

331–340 of 686 posts

Re: Appearing productive in the workplace

#331

Post by fhe »

wcfrobert wrote: post #42

> "Requirements documents that were once a page are now twelve. Status updates that were once three sentences are now bulleted summaries of bulleted summaries. Retrospective notes, post-incident reports, design memos, kickoff decks: every artifact that can be elongated is, by people who do not read what they produce, for readers who do not read what they receive." Great article. The "elongation" of workplace artifact…

it was only after I had to manage others that I realized the logic for a lot of these simplistic metrics and rules. they are in place to hold accountable the worst performers. a simple example is when i introduced flexible work hours. it was fine with most people, but there are always a few members that abuse the system. they stretch it to the very limit to what can be interpreted as "flexible". as a manager it posed a dilemma for me. i didn't want to take away this privilege just because of a few abusers, but it was both unfair and set bad precedents if I allowed them to get away with this. and let's say they couldn't be easily fired. most of my peers simply ended up going back to a system where people punched in and out.

Re: Appearing productive in the workplace

#332

Post by red_hare »

wcfrobert wrote: post #42

> "Requirements documents that were once a page are now twelve. Status updates that were once three sentences are now bulleted summaries of bulleted summaries. Retrospective notes, post-incident reports, design memos, kickoff decks: every artifact that can be elongated is, by people who do not read what they produce, for readers who do not read what they receive." Great article. The "elongation" of workplace artifact…

I work for an "AI-native" company now and have found this to be the case.

EVERYONE (engineers, pms, managers, sales) uses Claude Code to read and write Google Docs (google workspace mcp). Ideas, designs, reports. It's too much for one person to read and, with a distributed async team, there's an endless demand for more.

So for every project there's always one super Google Doc with 50 tabs and everyone just points their claude code at it to answer questions. It's not to be read by a human, it's just context for the agent.

Re: Appearing productive in the workplace

#333

Post by oblio »

itemize123 wrote: post #301
groos wrote: post #273

During the last few months when AI usage was mandated in our team and usage exploded, our team's throughput has barely changed. Now, if this was due to people working 2 hours a day and painting, cooking and playing golf the rest of the day, this would be a great result, but I see many people work past 6pm, and yet the output is mostly the same. We are not tackling harder problems or fixing more bugs despite authoring…

what would you say the disconnect was? Was it a simple case of that your teams' not comfortable with merging AI code?

Or maybe the AI tools don't do what the advertising says they do.

Re: Appearing productive in the workplace

#334

Post by SoftTalker »

Geezus_42 wrote: post #266
SoftTalker wrote: post #174

Earlier quoted context omitted.

Many schools these days don't allow an "F" grade if the student makes any effort at all.

Source please.

Wife teaches 4th grade. They cannot give an "F" if the student turns something in. Only for completely missing work.

Re: Appearing productive in the workplace

#335

Post by Art9681 »

Counterpoint: If humans shipped perfect products they would no longer havejobs. The majority of time spent in an organization is fixing problems humans caused. For good reasons and bad excuses. We are not machines.

What we, collectively as a species are building now with AI is a mirror that reflects the failures and successes we contributed to.

No engineer here has a perfect record. No senior or principal either. We make a ton of mistakes that are rarely written about.

This is an opportunity for the ones that assume they have mastered the craft to put up or shut up. Anyone can write a blog with or without AI.

Put your skills to work and implement the system that solves the problem you lament. Otherwise, get off my lawn.

Its another voice screaming into the void without offering a solution. The solution is not to build a faster horse. It is not to reminisce about the past. That ship sailed.

Fix the problem. It's the 100th blog repeating the same thing we've read for two years. Nothing was accomplished here except wasting time on the obvious to pat yourself on the back.

A lot of time is being wasted writing blogs raising red flags.

That's the easy part.

Re: Appearing productive in the workplace

#336

Post by analog31 »

nlawalker wrote: post #11

>People who cannot write code are building software. People who have never designed a data system are designing data systems. Most of it is not shipped; it is built, often for many hours, possibly shown internally with great vigor, used quietly, and occasionally surfaced to a client without much fanfare. This made me think of How I ship projects at big tech companies [1], specifically "Shipping is a social construct…

This reminds me of a workplace where I spent many years. I asked several people what it meant for something to be "released" and nobody could tell me. I never even knew after I became a project manager.

Re: Appearing productive in the workplace

#337

Post by analog31 »

nlawalker wrote: post #11

>People who cannot write code are building software. People who have never designed a data system are designing data systems. Most of it is not shipped; it is built, often for many hours, possibly shown internally with great vigor, used quietly, and occasionally surfaced to a client without much fanfare. This made me think of How I ship projects at big tech companies [1], specifically "Shipping is a social construct…

This reminds me of a workplace where I spent many years. I asked several people what it meant for something to be "released" and nobody could tell me. I never even knew after I became a project manager. This was at a company that made hardware products.

Re: Appearing productive in the workplace

#339

Post by mikestorrent »

abvdasker wrote: post #309
wcfrobert wrote: post #42

> "Requirements documents that were once a page are now twelve. Status updates that were once three sentences are now bulleted summaries of bulleted summaries. Retrospective notes, post-incident reports, design memos, kickoff decks: every artifact that can be elongated is, by people who do not read what they produce, for readers who do not read what they receive." Great article. The "elongation" of workplace artifact…

This paragraph hit home with me as well. I work at a large tech company that's a household name and the practice of using AI to pad out design documents has become totally out of control over the last 4 or 5 months. Writing documentation is arduous and a little painful, which as it turns out is a good thing as it incentivizes the writer to be as succinct as possible. Why the fuck should I -- along with five other eng…

I've seen some of this as well. It's OK to send me an agentic screed if it's just going to be consumed by my agent, but I want a nicely written summary up top that was made by you... I'm starting to value poor grammar, typos, and other signs of legitimacy

Re: Appearing productive in the workplace

#340

Post by baxtr »

beachy wrote: post #230
Animats wrote: post #215

The OP has an amusing side point - LLMs have automated sucking up to management. There is a large market for that. His main point, though, is this: I have a colleague ... who spent two months earlier this year building a system that should have been designed by someone with formal training in data architecture. He used the tools well, by the standards by which use of the tools is currently measured. He produced a gre…

My friend built a construction management SaaS entirely via Claude. It looked damned impressive, and it kind of worked to demo, but he is in no way a programmer, though he understood the problem domain very well. I asked a few basic questions: - where is the data stored? - How would you recover from a database failure? - does it consume tokens at runtime? - what is the runtime used at the back end? - why are the web…

Sounds like it was a prototype to validate an idea?

I think at validation stage technical details like that shouldn’t matter. All that matters is there market demand for this.

If yes, go and build it properly.

Post reply on HN