yeah, i think the “LLM sound” is just a corporate sanitized tryhard voice that no sensible human would have. the tryhard bit is an artifact of instruction training, and the corporate sanitization is there to make it very “safe” for conversational interfaces or smart prose processing for corporate clients. but if you give the ai an actual, productive, and somewhat complex task to accomplish, it very quickly switches to something far more human-like, because it’s no longer trying to overperform on a simple task.

yeah, chatgpt is frickin unparalleled in coming up with bullshit and phrasing it just the right way. my favorite thing is asking it to be sarcastic and passive-aggressive:

One principle that has guided my career in engineering, which my colleagues often overlook, is the profound understanding of the mirror-like relationship between an organization’s design structure and the software engineering outcomes they produce. Now, I don’t wish to dumb this down, but every time you witness a cluster of technologists huddled together, producing an array of systems, sub-systems, or module designs, keep your eyes peeled. They’re invariably going to be a spitting image of the organizational framework of the enterprise, often in ways that self-proclaimed ‘visionaries’ fail to foresee.

Now, with painfully forced patience, I must reiterate that this axiom is no trivial discovery or stroke of divine inspiration. It’s merely a reflection of the structural reality, something akin to looking out on a mirror carefully arranged by your senior management. The hierarchy, the stratification, the fragmentation across your esteemed organization, will be sculpted into the systems it produces. Picture each software module as a carefully chiseled stone that when aggregated, forms the larger cathedral that is your system architecture.

Ironically though, I’ve often seen leaders ready to splurge on sophisticated technology and state-of-the-art infrastructure, willing to make all grandiose promises on achieving data-driven decision making or accelerating the pace of innovation. Yet, they conveniently forget, due to what can only be a mission-critical memory lapse, that their microservice architecture has a curious tendency to mirror our own managerial slides filled with box-and-line org charts.

And let’s dwell a moment longer on these org charts, these delightful diagrams that claim to encapsulate the chain of command and accountability within the organization. There’s almost an uncanny resemblance, to the perceptive observer, between the lines of software code and the seemingly tiny, arbitrary changes made to these precious organizational diagrams. Lest we forget, the software your teams sweat blood to build will knuckle under to the gravitational pull of the enterprise structure, echoing its splintered silos and delightful dysfunctions.

However, for the sake of those cheerfully blinded by technical jargon and starry-eyed optimism, do carry on with your lofty ambitions to transform your IT landscapes, to catapult your organization into the brave new era of digital excellence. Just remember, the structural symmetry between your divided departments and disjointed computing systems is not random happenstance. If nothing else, they are monuments to the myopia of management, embodied in code and user interfaces, continuing to honor the timeless principle that so eloquently underscores my engineering prowess.

i literally just added “do the above assignment in a sarcastic and passive-aggressive tone” to the prompt, lol

Oooh, are we saying complete bullshit on well-known principles just to make ourselves look better? Here, lemme try

One principle that has guided my career in engineering is predicated on a theory which asserts that an organization inevitably produces designs closely mirroring its own communication structure. This tenet is deeply entrenched in organizational theory and has profound implications within the field of software engineering. It underscores the tangibly symbiotic relationship between structural communication channels and the inherent formation of design patterns, directly impacting project outcomes and overall system architecture.

Take an instance of a complex system architecture, for instance; the blueprint invariably mirrors the modus operandi of the organization, melding functional utility with intricate formalism. More specifically, it can be deduced that the nature and structure of information flow within an organization will ultimately inform the design, function, and interactivity of the proposed solution. Understanding this dependency provides valuable insight into optimizing organizational communication channels and realigning teams for effective outcomes.

A practical illustration of this principle is observed in large software corporations. A company with segregated departments, each responsible for a different process within a singular product, results in a fragmented, disjointed project output. Conversely, an organization that values collaborative, cross-functional teams is more likely to produce a product that boasts of seamless integration between its components.

For this reason, corporate structuring and re-structuring, when required, should be done with a pragmatic view towards improving communication channels. Aligning one’s business operation to reflect this principle, therefore, has significant implications on the maintainability, productivity, and overall success of end products. It espouses the virtues of flexible organizational structures that maximize communication efficiency and consequently, affords more robust and efficacious design frameworks.

In essence, understanding and implementing this paradigm shifts how companies view their organizational structure and its subsequent impact on outputs. It transcends beyond mere theory, providing a heuristic tool for entities seeking to improve their system architectures. As such, it is an indispensable guidepost in my engineering career, illuminating the path towards optimum function and design within both the organization and the products it creates. This, in itself, is an organogram of success, a paradigmatic shift in corporate thinking to create more efficacious products and overall, more successful businesses.

There was a man at CERN once who was sick of questions. His name was Tim-Berners Lee.

actually, do yeet the baby if you have an application with different needs. for example, if you want to play a game, you’re better off yeeting 60 babies a second and just hope that whoever is on the side catches enough of them to get a smooth stream of babies, than making sure every baby is handed gently to the next person and get the whole line clogged up the moment anything disrupts it. if you just use the yeetomatic 3000 you’re always getting fresh babies on the other end, a few might just be dropped in the process

the only mass solution i found to this was that i installed pgadmin, logged into the db, and manually removed all the bot accounts from local_user. you should also remove them from the person table as well (you can easily find them if you do SELECT * FROM person WHERE local = true ORDER BY published DESC in the query tool), that way they don’t show up in your instance stats, but removing them from local_user would be enough to stop them from logging in.

nothing, they all run cyberpunk at the same framerate

looks like it works well, aside from some js bug where kbin doesn’t seem to know where to put the preview image (a getElementById failure)

fun fact: you can embed links on lemmy with the standard markdown format: ![alt text](https://image_url)

it will show up like this:

that’s a valid question though. wtf microsoft, why did you have to take away all that cool customization?

yeah, makes sense. when i’m not doing a test-driven workflow, i usually only allow copilot to generate simple things. with unit tests it’s a lot easier because the tests are easy to read and verify, and they expose the errors in other parts of the code

which language do you work with? also, what kind of code do you write?

i do web apps in typescript, fullstack, and so many things are just layers upon layers on the same thing. you make a model, then you make a migration for that model, then a controller for a dead simple crud with just enough custom validation and shit that it’s hard to autogenerate, then swagger docs, then factories and unit tests. most of the time, i just write the model, paste it to the top of the file in a comment, then start writing the thing and the ai immediately wants to take it and do it by itself, so i just let it. there are usually a few mistakes, exactly in those hard to autogenerate places, so i fix a few and then the ai can help fix the rest with little intervention. (i do need to delete the mistake and palce the cursor, but it tends to know how to fix it). it’s been a huge time-saver for me.

but i noticed that it’s also damn good at just generic typescript/javascript. i have it enabled pretty much all the time now and i have yet to find a task where it doesn’t speed me up, even with the weird shit i do for fun.

however, i heard similar complaints quite a few times working with other languages. the amount of open source code that’s out there for your specific language seems to have a large effect on copilot’s effectiveness

ceremonies? what kind of cult do you work at?

but yeah, i have like two standups a week, we’re not that organized

me. i slack off 6-7 hours a day and use copilot to do the tasks in the remaining 1-2 hours. (at least i think that’s the ai and not my untreated adhd…)

in a few years, some genius will do a four day workweek experiment, people like me will forget to only work 4-8 hours instead of 5-10 per week because the amount of tasks is the same, they will conclude that there’s no reduction in productivity, a benefit of four day workweek will work as an incentive instead of a raise to keep people around a bit longer, and it will start becoming a standard. and voila, we got the working hours reduction officially.

i’ve already heard buzz that negotiating a four-day work week doesn’t tend to involve a 20% salary cut (probably because people are already slacking off a lot). i’ll have to research that more though, because at some point i’d do it even if it did result in a 20% cut, and time is so much more valuable tbh.