Live data from Hacker News

Appearing productive in the workplace

nooneshappy.com

631–640 of 686 posts

Re: Appearing productive in the workplace

#631

Earlier quoted context omitted.

> An over-engineered solution (complete with CLI, storage backend, documentation, unit tests) for a trivial problem which that person would've solved by an elegant bash one-liner only 3 years ago. Importantly, I think AI companies are motivated towards the overengineered solutions as they increase the buyer's token spend. I'm not sure how we can create incentives that optimize for finding the 'right' solution, which…

> Importantly, I think AI companies are motivated towards the overengineered solutions as they increase the buyer's token spend. Yes that, and also, the more complicated the solution, the more likely no one reads or reviews it too carefully, and will instead depend on an LLM to ‘read’ and ‘review it’ Even ignoring token costs, there’s a high incentive for LLMs to generate complex solutions, because those solutions ge…

> Yes that, and also, the more complicated the solution, the more likely no one reads or reviews it too carefully, and will instead depend on an LLM to ‘read’ and ‘review it’

Exactly right. It's the other end of the bikeshed continuum[1]. If you send out a two-page design doc or a hundred like pull request, the recipient will actually review it. Let AI inflate that to ten pages or a thousand lines of code and they feel like they don't have enough mental capacity to tackle it so they let it slide.

[1]: https://bikeshed.com/

Re: Appearing productive in the workplace

#632
post #501

> The first is when novices in a field are able to produce work that resembles what their seniors produce [...]. > The second is when people generate artifacts in disciplines they were never trained in. There is a third shape. Experts who have become so reliant / accustomed to AI that it dilutes their previously sharp judgment and, importantly, taste . I am seeing more and more work produced by experts which seems st…

I have thought about it.

Present iteration of LLMs are, despite what normies would believe, aren't optimised to provide correct solutions. They are optimized to __sound smart__.

This may be just an undesirable artifact of the RLHF process. But the end result is same. They try (?) too hard to sound smart.

Last generation LLM writing was too obvious in its soulless journalistic nature. But the current generation LLMs do all the following things to appear smart; From the lowest levels to highest level

- use clever writing styles and punchlines. Not X, it's a Y'ed Z. (Though it's not funny and makes no sense).

- Overstuff the technical terms, most often using a +. "Add a shim + iptables rule + signal handler".

- Over engineer the low level design. (Eg rather write a function to do some complex parsing when a way exists to avoid it altogether. Write tricky bash script and parse the output for what could be achieved by stdlib in few more lines).

- over engineer the code flow: this is rather because they're clueless and can't step back. But I have fun seeing the LLM come up with 4 5 levels of branching and then extract it into a function, whereas a human would step back and try to avoid the branching.

- over engineer the high level design: well your mistake is letting the word soup machine lead the design. It will add all and kitchen sink with need bullet points and + marks. Only a pleb not sufficiently educated in the matters of computer science will be impressed with such Markdown kitchen sink designs. It's fine to rely on LLM for brainstorming and discovering how to do A, B and C. But if you outsource the job of design, it's instincts (!) to sound maximally smart using bullet lists and + marks will kick in.

Re: Appearing productive in the workplace

#633

Earlier quoted context omitted.

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…

I just want to mention that in my personal anecdotal experience, every codebase I have ever worked on, except 1, was underengineered and not overengineered. The last one was just "engineered".

Re: Appearing productive in the workplace

#634
post #575

Earlier quoted context omitted.

You missed the point - understanding comes from working through the code, not just reading it. This is nothing new: nobody has learned or done new mathematics or physics or whatever by just reading a textbook.

Sure. But it’s a lot easier to learn nonlinear mathematics or quantum theory with a textbook than without. In this case you’re not learning about “what is a for loop”. You’re learning “why a OnceLock here rather than a RwLock”. Many of us work on teams so we already have to deal with the majority of code being written by someone else. I’ve got code that’s more than a decade old, written by people I’ve never met.

Again, note that I said "work through" and not "read". Reading code is shallow. Debugging it, modifying it, inserting diagnostic code, etc. is not.

Re: Appearing productive in the workplace

#635

Earlier quoted context omitted.

Developers have been lacking taste for decades anyway, like all of those kubernetes clusters built out for companies that could run on a 50 euro a month dedicated server at hetzner.

Sometimes entire businesses collapse to a python dict and a backup UPS power supply

Software-wise maybe, but if their customers could replace them with a Python dict they would. Such businesses usually have value due to their social network consisting of suppliers, knowledgeable employees, and other customers.

Re: Appearing productive in the workplace

#636
post #489

Earlier quoted context omitted.

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'm starting to see pushback for this. I know a Product Manager that was fired for padding his documentation with AI to the point there were mistakes and wasted work due to AI hallucinations.

we as a culture will gradually find a resting place here in regards to "proof of work" but it will be a painful decade in the meantime.

Re: Appearing productive in the workplace

#637

Earlier quoted context omitted.

Perhaps the experts have decided that, for this specific instance, the thing we need to do is ad-hoc and throwaway, and is simply not worth paying the extra cost to make it tasteful.

How can a bash one-liner be more expensive to build than a full-blown CLI tool with the maintenance burden that comes with it?

Same way an excel spreadsheet can be more expensive to maintain than a web app.

Re: Appearing productive in the workplace

#638

> "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…

Audience is important. Devs should stick to the agile manifesto to communicate among themselves.

Decision makers want to see a wall of text in every project plan, decision document, and strategic plan. Not because they know anything about it, or even attempt to read it, but because they want to trust that you've thought about everything and provided a good recommendation.

AI is going to pull the wool over their eyes and they'll have no idea until it explodes in their face. I really think we're going to see a reversal of the 2000s high trust business environment, and as we move to a low trust environment, I hope you're all drinking buddies with your VP ;)

Re: Appearing productive in the workplace

#639
post #501

> The first is when novices in a field are able to produce work that resembles what their seniors produce [...]. > The second is when people generate artifacts in disciplines they were never trained in. There is a third shape. Experts who have become so reliant / accustomed to AI that it dilutes their previously sharp judgment and, importantly, taste . I am seeing more and more work produced by experts which seems st…

Taste.

I believe we (software engineers) have tried hard to eliminate taste in programming: linters, git message styles, you name it. And I think that's a good thing. Taste is not transferable. Consistent code is.

Re: Appearing productive in the workplace

#640
post #501

> The first is when novices in a field are able to produce work that resembles what their seniors produce [...]. > The second is when people generate artifacts in disciplines they were never trained in. There is a third shape. Experts who have become so reliant / accustomed to AI that it dilutes their previously sharp judgment and, importantly, taste . I am seeing more and more work produced by experts which seems st…

> An over-engineered solution (complete with CLI, storage backend, documentation, unit tests) for a trivial problem which that person would've solved by an elegant bash one-liner only 3 years ago. Importantly, I think AI companies are motivated towards the overengineered solutions as they increase the buyer's token spend. I'm not sure how we can create incentives that optimize for finding the 'right' solution, which…

> Perhaps a widely recognized but not overly optimized for benchmark for this class of problems?

I don't see how this could be achieved.

Any widely-recognized benchmark is going to be gamed by the genAI companies.

They have a strong financial incentive to do so, and their products' nature shows that they are not influenced by ethical or societal-good incentives.

Post reply on HN