Our team tends to prefix all our comments with one of
* thought: Maybe foo'ing is more common in the future - we can refactor if that happens.
* change: This is a leaky abstraction, would prefer to see this modeled like bar instead.
* nit: Naming seems a little unintuitive, consider "Baz", "Boo" maybe?
* fix: This unit test is validating the wrong field.
* chat: This is a big decision and would dictate how solutions of this category look like going forward. Let's bring this to the team first.
----
With the idea that some of those prefixes are stopping the PR until they are changed, and some are just a "take it or leave it" type comments. It makes it unambiguous to the opener that you consider these X things as "We've gotta get on the same page" and these Y things as "Stated preferences" or "just an observation".
word of warning - don't feel bad if you leave a nit, the other person disagrees and ignores it. If you felt strongly about it, it shouldn't have been a nit.
Man, once you start picking up on the LLM style you can't stop seeing it everywhere.
> It's not just the foo, it's the bar. Short sentence. Every sentence attempting to be profound, but isn't. I quietly put adverbs in strategic locations, quietly, deftly, and always lists of threes. Your advantage is the ability to foo, not just bar.
=====
re: the content
You're missing the point of "arguing" in the workplace if you're arguing with individuals and you see it as your objective to destroy them with facts and logic.
> So I’ve drawn a line. I only discuss pros and cons with smart people; I don’t argue right and wrong with ego-driven ones. With the first kind, a disagreement is a joint search for the better answer, and both of us walk away sharper.
This one points out the biggest miss and why this person finds their strategies impotent. The goal of "arguing" in the workplace, or more pr-friendly, "debating the merits" should never be to convince that guy to take your position. That's both ineffective and way harder. You should focus your energy instead on constructing the arguments towards the audience and bleeding support. Nothing of importance gets resolved in a singular meeting with a singular debate.
Watch some Oxford style debate prep to understand this point more deeply, but some number of peers are going to agree with your position ahead of time and some are going to disagree with your position. Instead of trying to obliterate all the points one-by-one from the person on the other side of the issue, try to make just a few succinct points that will pluck off a few onlookers. That's all you need at the moment. Take the tiniest win, move the overton window a little further in your direction, and retain all the goodwill and camaraderie on the team or in the org.
Do this in *SMALL* and *INFREQUENT* ways and over time you end up becoming the person who tends to be right on the issues and onlookers become more sympathetic to your positions by default. This lets you make bigger pushes, or allows conversations to start off as already "in your camp" to begin with. This builds up social credit (reputation) which you can then spend on taking more risky bets/positions within the org.
----
The other thing it lets you do is open the door for others to debate merits of their ideas. By keeping the focus on just a singular point or two, keeping it low stakes, and then being willing to walk away amicably at the first sign of any emotions you implicitly grant permission to others (who may agree with you, or who might just need to practice their own abilities) to voice a dissenting opinion on something orthodox. Maybe you agree with them, maybe you don't - but never shoot down a first timer's / shy guy's idea on it's first float.
> I'll say - it also wouldn't kill us to have slightly fewer people on the planet. We're already taxing much of our systems/ecosystems past their breaking points. Smarter people than me, entire groups of scientists, are saying that what we're doing now is badly unsustainable and we're heading for trouble.
If you believed this, would you be against sterilizing third world populations to limit the overall population growth ( given those are the populations which continue to grow in this environment ) ? If not sterilizing - what about propagandizing their younger population to not reproduce? Would that be a net-good?
> is the only known working solution to a decreasing population.
Which it obviously isn't a working solution in any nature of the word. Using arbitrary countries to avoid common mousetraps.
Hypothetically all women in Estonia suddenly opt out of having children for a variety of reasons. They had previously had no problems like this and enjoyed a high fertility rate up until now. The government of Estonia sees this and starts mass immigrating Japanese men and women and are able to stabilize their population. Though, the Japanese women also normalize to the same state of opting out after just one generation.
The government claims that this too is an emergency and seeks another seemingly arbitrary population of humans to import.
Agree with the entire article - but if I knew Pam, I'd coach her on
> Pam sees this and wonders, "What is considered a large project?"
The first interaction when getting hit with artificially introduced friction _SHOULD NOT_ be to just adhere blindly to the friction without a meta-consideration for the friction itself.
Pam shouldn't be asking "What is considered a large project?" - Pam should be asking "Why would a large project need this review and a small project not need this review?" Then categorize her project based on that answer. Understanding the purpose of the review should give her much more autonomy and confidence in saying "My project doesn't need X review." without relying on "I identified it as 'small'" and instead rooting her decision in whatever business concern is being hedged against.
This isn't your home with open stairwells and loose venting doorjams. This is a thirteen story office building with elevators and badged access easements.
> They turned the english language into enterprise java
.... tell them not to do that if you don't like it?
"PR Descriptions must explain the entirety of the PR's contents in 300 characters or less and be written at no greater than a 600 lexile score. After writing the description, carefully review it's claims against the changeset diff if any staged changes are unable to be tracked back to a claim in the PR description, reject the creation and alert the user of the discrepancy offering solutions on how to remediate"
> The solution to uncertain information isn't more information, which the AI can certainly provide, it's better information, and AI cannot currently provide that.
Aside from the LLM-ism (it isn't foo, it's bar) - this is a thought terminating cliche. You definitionally don't know if some information is better or not given that you were uncertain about the information in the first case.
"I went to three mechanics and got three different answers" - your takeaway is just "Ah - I clearly need better informed mechanics."
Which is on it's face absurd because if you could clearly judge the ability of the mechanics you wouldn't need their evaluation. You'd just do the evaluation yourself.
> Then again, many people don’t want the burden of caring for bytes for the rest of their lives and prefer to download on demand.
Agree that people want this - but this is an undue burden on the provider side. You have to perpetually maintain and provide access to content FOREVER including all the systems and support staff to auth.
Depends on what you mean, LLMs can probably _make_ pretty good AIs. It'll have all the AI scripts in the base game, including the three iterations (base, FE, DE) all the user generated ones ( including barbarian ) and then able to consume the language schema. Rig up a baby model that takes the matchup during loading and hot swaps one of your pregenerated AI scripts.
If you meant _playing_ raw based on LLM input - that's probably the wrong tool for the job. The latency for you to react to a mango shot is faster than a billion tok/s lol
Not necessarily saying that you are doing this right now but I find when people use "fascist" as a snarl word and not an actual word with a definition and qualifiers. Maybe your LLM interactions are picking up on the actual word "fascist", which has a definition, that DJT certainly doesn't apply to.
eg: https://www.merriam-webster.com/dictionary/fascism
> a populist political philosophy, movement, or regime (such as that of the Fascisti) that exalts nation and often race above the individual, that is associated with a centralized autocratic government headed by a dictatorial leader, and that is characterized by severe economic and social regimentation and by forcible suppression of opposition
You can not like the guy and point to things that he's done and wag your finger with the LLM - but if the LLM is anchoring your question as a categorization/definitional question - DJT isn't that.
=====
Maybe similar, less charged, - ask it if an apple is a strawberry, describe all the ways they are similar, Edible, Red, Fruit, Sweet, found in groceries, smaller than a breadbasket... While maybe unintentionally ignoring all the ways they are different. Then act exasperated when it agreed with you on all points, but still denies your appeal that an apple is a strawberry.
> Every time I get past the green field stage, I just end up throwing out what it writes half the time since its trash.
Is a skill/PEBKAC issue. You still need to exercise engineering best-practices like decomposing work to the smallest unit before taking a task on, brainstorming design first and implementation last, clearly defining your success criteria and requirements before beginning any work, etc.
I'm on a >10yr old codebase and have been able to get my org to orchestrate entire features, fully unit tested, e2e tested, storybooked, from scratch without touching an IDE. Refactorings and the endless mountain of 80% completed migrations from one pattern to another are now trivially able to offload.
Point your SOTA de jeur at the original docs, a few of the original examples/PRs and have it draft a skill describing the work, the scope, and the success metrics. Iterate on the skill with the main agent by subagenting to test the skill until you are happy with the result and it mostly gets it right with the guardrails you've defined. Again - keep the scope extremely small. It gives much less rope for the agents to hang themselves with and it is less cognitive load when you have to review/test the PR.
Then set up a reasonable cadence for it to execute an autonomous thread on and review when you get comfortable.
----
The issue I've been running into lately is simply that we've got so many PRs coming in that actually doing thorough human reviews on them is not sustainable relative to the rate the team is creating agents to open them and people (especially juniors and mid level) are getting burned out by essentially having entire days where they are just doing code reviews.
Notably this does nothing to "solve" the attack vector. You've got a live bomb in front of you and you're adding 10s to the countdown hoping that _others_* find it and defuse it in that time period.
I would challenge anyone proposing this to define more than one party doing security checks on packages to prove the point that many projects are waving their hands nebulously around saying "security vendors" and then YOLO'ing code into their codebase because they didn't here the muses wailing.
Alternatively from the other direction - Point to any dependency in your project. How can you get *POSITIVE SIGNAL* that security vendors _did_ look at it and okay it? How much scrutiny did they put into it? At what version did they last inspect it?
I've almost always gotten everything I want from security teams over my career. Usually a quick and honest chat with them gets you pretty far.
I always lead with some flavor of "In my perfect world, I have 100% access and ability to everything, everywhere all the time. In your perfect world, I don't even have a computer. Here's why I need X permission / Y user group / z application"
From the perspective of big corporate security - developers are a wild nuisance who file the lions share of the tickets and soak up an inordinate amount of resources. Being able to at least explain to them that you understand their objectives and are not overrequesting just for the sake of overrequesting goes a long way.
> Yup. I'm extremely unconvinced that a non-distributionary constraint (ex: limiting the money supply one way or another, i.e. the gold standard, bitcoin, etc.) fixes a distributionary problem.
Well, that's good because that's not what limiting the money supply does. It _acts as a force against inequality_. It doesn't _fix_ or _prevent_ inequality that already exists and doesn't claim to stop organic inequalities from arising - but it does put a limit on inequality resulting from an inflation of the money supply.
> Currently we’ve switched to a short (15-30m) technical problem that we hand grade before candidates get a call.
Funny because I do the same; I don't commit to doing any work/assessments before at least an honest interview round. Businesses have to understand that _they_ are the ones who have to solve for the filtering problem. Most great candidates that you are hoping to snipe are already in a stable job and do not _have_ to jump through hoops to get past a filter.
It shouldn't be noise. Don't update it if you're not intentionally trying to, otherwise you're exposing yourself to supply-chain risk for no reason. If you are regularly getting unexpected `package-lock.json` changes then you are doing something wrong.
> "What is Yacht Club's stance on AI and has AI been used in the production of Mina the Hollower at all?" to which their reply was "We all got caught up in AI fever like the rest of the world, but we didn't find it was very effective for what we're doing. Maybe our work just isn't that generic! We've found some ways it can help... like Google or a thesaurus, but it hasn't affected what's in our game." [1]
Can you see how this intentionally coy and evasive answer was made specifically to not say "No, we didn't use AI." but still sound like "No, we didn't use AI." so that people wouldn't immeidately bust out pitchforks and start review bombing their game before it takes off?
* thought: Maybe foo'ing is more common in the future - we can refactor if that happens.
* change: This is a leaky abstraction, would prefer to see this modeled like bar instead.
* nit: Naming seems a little unintuitive, consider "Baz", "Boo" maybe?
* fix: This unit test is validating the wrong field.
* chat: This is a big decision and would dictate how solutions of this category look like going forward. Let's bring this to the team first.
----
With the idea that some of those prefixes are stopping the PR until they are changed, and some are just a "take it or leave it" type comments. It makes it unambiguous to the opener that you consider these X things as "We've gotta get on the same page" and these Y things as "Stated preferences" or "just an observation".
word of warning - don't feel bad if you leave a nit, the other person disagrees and ignores it. If you felt strongly about it, it shouldn't have been a nit.