I grew up near an abandoned WWII era airfield. I have fond memories of first learning to drive by going out and blasting along the runway, had to avoid a few spots where trees had grown up through cracks in the tarmac, but it didn't matter if I stalled out the truck and I could get it up to a good speed.
Yep, I worked at a small company that got bought by a bigger one. We had a solid if aging product to support which was one of the big players for the niche. Once there was a leadership change, 2/3 of the devs got put on building a replacement software. Then in a couple of years our subgroup got spun off and sold to PE and the v2 project was shelved for another brand new design to align with the new ownership. I left just before the spin-off, but witnessed how the original software slowly rotted away and all of the marketshare dominance we had for that area slipped away.
Devs love new tech and the product people love something new to put their stamp on, but chasing that high can be ruinous.
I've done similar at my job where management wants us to use all of our tokens before they expire. I usually set it to documentation tasks and other minor tasks just to eat up tokens.
There's really no end to dot-language diagrams you can have it make. Call graphs, package dependency maps, let it try to figure out an architecture diagram, whatever.
Giving it busywork that you don't have the time or wherewithal to check carefully sounds like a disaster. Rather than introduce content that will be partially wrong and cause confusion if it's ever read, I'd consume the credits and send the output to /dev/null.
Just title it "draft". Odds are nobody will look at it anyway.
Add a pre-commit hook to re-create the diagrams on every commit (in case anything changed, of course), that way you can really burn tokens and look good to management.
At least that nominally creates some value at the end of the day. Documentation is the thing everyone wants but no one has time/desire to create. My most recent token heavy task was having an agent write unit tests for coverage on a little graphAPI tool I'd written a bit ago to satisfy SonarQube.
People don't want to read LLM-generated docs though. It'll lack the context to justify why things were designed the way they were, and there's always a risk of hallucination so you still have to verify the documentation's claims, since the person who published it likely did not scrutinize it.
There's two major types of documentation "why is this like this" documentation and then there's "here's the features of this library/tool" documentation. LLM stuff is fine for the latter as long as you screen it for hallucinations. Your right the former they can't really do because they don't have access to the reasoning but I've often found even the latter to be lacking in many teams.
IMO that's down to how you personally feel about the two sides of the process. For me the initial writing is super tedious and I've never gotten great at the voice of technical documentation but checking it for errors and correcting that is easy.
...Yes. I didn't say fire and forget but it can handle a lot of rote recitation of library flags and functions perfectly well. The kind of stuff that's autogenerated with javadocs, inputs, outputs and effects that are all in the code are available to the LLMs. Like all things with LLMs generate and review but I've seen some good outputs with minimal errors that saved days of work no one was going to be given the time to do.
Yes, this is story immediately came to mind to me. It also shows that the idea of poor people in the global south doing this for money isn't quite the entire story either. Most of the people exposed seem to be young Dutch people trying to make a quick buck attacking Canada.
There are still good niche and well moderated subreddits, but the big ones are pretty annoying. Lots of most extreme version of headline/summary to get the clicks. Tonnes of bot comments, especially with the rise of LLM. Repetitive joke responses.
Coursera used to be good, and I've found the occasional good course on Udemy, but neither are particularly great right now in my opinion. Well curated learning materials are such a unicorn.
They’re not trying to control your speech. They’re trying to improve your communication so your message gets across better. Unless of course your primary message is “I’m an ass and proudly anti-empathy.”
> yeah you're right the guy who told me which words I shouldn't say definitely isn't trying to control my speech.
>> Please don't use ridiculous and painful slurs in a serious conversation.
"Please don't" is just a polite request, particularly when used by an anonymous and presumably powerless stranger on the internet. It's not an attempt to take control or use force. It's an attempt to get you to introspect. Don't be so sensitive :p
Yes, chimps are intelligent. Thank you for noticing.
He used the word to refer to a hypothetical version of himself, one that failed to either notice or comprehend something simple. That’s the same context in which people use it as an insult against others. The only difference is that it was a self-applied insult in this case.
More importantly, the word, when used as an insult, uses real humans with real difficulties as the referent. Those people and their caregivers are the one’s that feel the insult. Whereas chimpanzee is an animal and remains unaware and unhurt when its species name is used as an insult. (My pseudonym is also not meant as a self-applied insult, most days.)
GPs usage doesn’t really matter to me though. It wasn’t an egregious thing to say. And, for me personally, the word has little value one way or another. It reminds me of grade school chatter.
I just find it comical that there’s a lack of self-awareness regarding the effect of its usage. But again, perhaps there was no lack of awareness at all and perhaps that was the real point.
I worked for a small company acquired by IBM in 2011. We had a good 5-6 year run where our product sales went up (largely because so many IBM people were selling it) and we were largely left alone. Once things slowed down a bit the IBM rot set in quick though. These days I think all that's left is a skeleton crew maintaining the obligatory long term contracts around the main product, every other part of the original company has been picked clean.
You can measure it by how many management steps you, as an employee of the recently acquired company are from the CEO in the hierarchy. As time goes on, this number tends to increase. It used to be easy to see this in Lotus Sametime or something that had some form of employee directory.
That's awesome. Before ~2007 they allowed you to use open-source Pidgin to connect to the Domino servers. A friend of mine and I used it to make a bot: if you sametimed me, you got Zork.
It reminds me of another IBM IT rule: they wanted your chat history (and email) older than two years to be all deleted for legal liability reasons. It was important to save your sametime chat history (an XML file) and export your email periodically if you wanted to keep this stuff.
This was actually better than Slack in one way- you could grep the files for things, and not have to rely on search within the tool.
