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

231–240 of 686 posts

Re: Appearing productive in the workplace

#231

Post by about3fitty »

Traubenfuchs wrote: post #81
proofofcontempt wrote: post #19

What is described here closely resembles my experience too. My company is full of managers who haven't written code in years. They hired an architect 18 months ago who used AI to architect everything. To the senior devs it was obvious - everything was massively over engineered, yet because he used all the proper terminology he sounded more competent to upper management than the other senior managers who didn't. When…

My company hired a lead architect and he stayed with us for less than a year. He introduced some overengineered shit we are still recovering from. How those people get to where they are and get hired for that kind of position is beyond me.

I think this may be a consequence of hiring for a position with the word “architect” in it. It implies the need for complexity vs. Getting a gaggle of senior devs together and letting them sort out CI/CD and patterns as they are needed. In a lot of cases, an architect is not needed but must justify themselves.

Re: Appearing productive in the workplace

#232

Post by Pannoniae »

zbentley wrote: post #205
LinuxAmbulance wrote: post #92

Earlier quoted context omitted.

AI has made my work about 5-8x quicker, just because I'm able to have it cover a lot of the grunt work (update 42 if statements in 32 different files) that took time, but no particular skill. I think the use cases where AI makes an economic improvement to the status quo for a business are rare, but they do exist, and they can be a significant improvement. It's like the early days of the dotcom boom and bust - people…

Without getting into AI-for-work good or bad, > update 42 if statements in 32 different files is a silly behavior for a programmer or an AI to have to do more than twice. We have tools that very effectively remove the need for things like that: programming languages that allow modular and reusable code, good design, etc.

Ideally. But that requires the correct abstraction, requires keeping it up to date.... that's basically an unachievable ideal. You either have overabstraction/overengineering (most codebases) or you have repetition. Repetition is actually more preferable in the LLM-world because you have to keep less stuff in your head. And the LLM's head too.

Even if something does look copypasted, it might actually be semantically distinct enough that if you couple them, you'll create a brittle mess.

Additionally, there's always going to be global changes (update the code style, document things, refactor into a new pattern, add new functionality to callers, etc.). The question isn't whether you use your lanuage's tools or you do it by hand, the question is whether you use an LLM or do it by hand :P

Re: Appearing productive in the workplace

#233

Post by Swizec »

skirmish wrote: post #178
Swizec wrote: post #158

Earlier quoted context omitted.

I write a lot and have on several occasions tried dictation as an initial draft authoring step. It was trash every time. Good for thinking through a concept but unsalvageable in the edit phase. Easier to throw away and rewrite now that you know what to say. Nowadays I like conversation as an ideating step. Talk to a bunch of people, try to explain yourself until they get it, see what questions they ask. Sometimes in…

> It can take weeks of work to produce a 500 word product vision document. Don't you get dinged as a slow performer? Management expects x5 speed on everything now that AI is available.

> Don't you get dinged as a slow performer?

No because the document is not the work. Management wants someone to figure out the solution to their problems. The document is just a step in solutioning.

Without the doc, others would have to re-do all that work if you get hit by a bus. Or you’d be stuck in endless meetings conveying the vision instead of figuring out the next problem.

Document length is inversely proportional to the quality of your thinking/insight. When you create fluff, everyone can see you didn’t do the work.

Re: Appearing productive in the workplace

#234

Post by mountain_peak »

jcgrillo wrote: post #154
bonesss wrote: post #63

Earlier quoted context omitted.

I’m an LLM enjoyer who also thinks that ‘er ‘jerbs are safe and, taken to their logical conclusion, most LLM-stroking online around coding reduces to an argument that we should be speaking Haskell to LLMs and also in specs and documentation (just kidding, OCaml is prettier). But also, I do a little business. You’ve hit the real issue, IT management is D-tier and lacks self awareness. “Agile” is effed up as a rule, wh…

Speaking not as a professional mechanic, but as someone who maintains a car, two trucks, a tractor, a couple boats, and has googled quite a lot of torque specs in my time... If you're googling torque specs in 2026 you're gonna have a bad time. They're frequently just flat out wrong, especially the AI summaries ;). Use the authoritative source of truth--the shop manual published by the equipment manufacturer. Accept n…

Absolutely - factory repair guides/apps are the only source of truth for official specs, although 3rd-party manuals are very good as well. That being said, I've often turned 3-hour estimated repairs into 15-minute jobs through clever shortcuts. For example, rotating an alternator to replace the run clutch through the gap in in the intake manifold as opposed to removing the complete intake manifold. I think that's where using experienced (and resourceful) developers pays off.

Also, for sale: BMW E60/61 Bentley 2-volume set. Barely used.

Re: Appearing productive in the workplace

#235

Post by [deleted] »

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…

[deleted]

Re: Appearing productive in the workplace

#236

Post by FridgeSeal »

AnthonBerg wrote: post #224
paodealho wrote: post #157

Earlier quoted context omitted.

I like them. It tells very clearly how much effort went into someone's work. I like them even more on code comments. It tells _precisely_ how much effort went into the pull request, so I don't spend time reviewing lazy work.

It does not at all indicate the effort that went into doing the thing. Clearly not. I propose that what you enjoy is having a token of the appearance of effort, easily constructed and easily observed and easily suitable for low-effort handling of these proxy objects for actual work.

I think you’re missing the sarcasm in their comment.

They’re saying that the emoji usage is telling them that very little effort was put into the PR and that they’ll treat it accordingly.

Re: Appearing productive in the workplace

#237

Post by 2ndorderthought »

spaniard89277 wrote: post #204
towers wrote: post #112

Earlier quoted context omitted.

The forcing of competent engineers to vibe code is something I’ll never understand. Also, I’ve heard rewriting people’s vibe coded efforts being a substantial issue, everything that engineers do nowadays seems to be code review.

Guys just go and ride it. It's their money. They decided to do this. They think you guys are stupid. Suck. Them. Dry. Or say goodbay, which is what I did on my previous role when the BS started to get obvious. Now I do LLM-assisted coding on my own terms. I decide what to do, review output and push back agains overengineered BS. But I'm a lucky one, as far as I can see. --- NO-ONE is going to be able to understand th…

I couldn't do it. It made me feel crazy. Looking back though, now I don't have a job and that stinks. Oh well at least I don't get nightmares about debugging the next production issue on call.

Re: Appearing productive in the workplace

#238

Post by jcgrillo »

mountain_peak wrote: post #234
jcgrillo wrote: post #154

Earlier quoted context omitted.

Speaking not as a professional mechanic, but as someone who maintains a car, two trucks, a tractor, a couple boats, and has googled quite a lot of torque specs in my time... If you're googling torque specs in 2026 you're gonna have a bad time. They're frequently just flat out wrong, especially the AI summaries ;). Use the authoritative source of truth--the shop manual published by the equipment manufacturer. Accept n…

Absolutely - factory repair guides/apps are the only source of truth for official specs, although 3rd-party manuals are very good as well. That being said, I've often turned 3-hour estimated repairs into 15-minute jobs through clever shortcuts. For example, rotating an alternator to replace the run clutch through the gap in in the intake manifold as opposed to removing the complete intake manifold. I think that's whe…

Yeah Bentley (and in some cases Haynes) make good aftermarket manuals too. And you can find good information on some forums. But you can also find a lot of bad information. Reliably sifting the good from bad only comes with experience--much like in software.

Re: Appearing productive in the workplace

#239

Post by paodealho »

skirmish wrote: post #165
paodealho wrote: post #157

Earlier quoted context omitted.

I like them. It tells very clearly how much effort went into someone's work. I like them even more on code comments. It tells _precisely_ how much effort went into the pull request, so I don't spend time reviewing lazy work.

So you just rubber-stamp the lazy work? What else can you do when this PR is assigned to you specifically for reviewing?

The last place I worked for, if it happened with someone new in the company or the team, I would find a polite way to say "do your job and fix this shit" and it worked.

Some people have put me on their blacklists after these interactions, sure, but they're the exact people I don't want to work with again. The important thing here is that I've never done someone else's work for free.

Re: Appearing productive in the workplace

#240

Post by gleenn »

Merad wrote: post #186
danaw wrote: post #129

i have a strong suspicion that the most productive software teams that leverage llms to build quality software will use it for the following: - intelligent autocomplete: the "OG" llm use for most developers where the generated code is just an extension of your active thought process. where you maintain the context of the code being worked on, rather than outsourcing your thinking to the llm - brainstorming: llms can…

> intelligent autocomplete I'm curious how much value others are finding in this. Personally I turned it off about a year ago and went back to traditional (jetbrains) IDE autocomplete. In my experience the AI suggestions would predict exactly what I wanted < 1% of the time, were useful perhaps 10% of the time, and otherwise were simply wrong and annoying. Standard IDE features allowing me to quickly search and/or bro…

Same, I use Claude but cannot stand typing and being constantly flashed with suggestions that aren't right and have to keep hitting escape to cancel them. It's either manual or full AI for me. This happens in a lot if web tools that have been enhanced with AI, like a few databases with web UIs that allow querying. They are so bad. I really wish they would just dump the whole schema into the context before I begin because I don't need fancy autocomplete, I need schema, table, and column autocomplete wayyy more than I need it to scaffold out a SELECT for me.
Post reply on HN