51 karma · joined August 19, 2021
* 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.
> 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.
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?
If not, why not?
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.
> 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.
.... 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"
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.
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.
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
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.
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?
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.
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.
A simple and logical pattern.
1) Unconstrained spending without commensurate taxation leads to a required inflation of the money supply
2) An inflation of the money supply with increase the price of assets relative to the value of the currency.
3) Asset owners thus become "more valuable" by measure of currency.
4) Renters / non-asset-owners have to eat the costs of inflation while benefiting by none of the inflationary pressure on assets.
ergo - a gold standard is just a proxy for "constraints on debt" is a force that acts against inequality between asset owners and non-asset owners.
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.
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?
---
Now, AI makes this *WAY* easier since you have a practically omniscient distro debugger with infinity patience and you don't have to wait on their responses. So this is probably coming down as a barrier soon, but I want to stress that "the only problem I had in 4 years" is loosely the same as "I bought a new car and the only problem I had was a catastrophic transmission failure. I just had to rebuild the transmission from scratch using specialized tools and knowledge and it was okay.