computronus

Important to note that this is about "U.S. corporate borrowers of private credit", so companies and not individuals.

I do agree with the common refrain, actually, and disagree with the idea that work can be so big and complex that it has to be in one pull request.

A big queue of PR's for reviewers to review

Yes, yes please. When each one is small and understandable, reviewers better understand the changes, so quality goes up. Also, when priorities change and the team has to work on something else, they can stop in the middle, and at least some of the benefits from the changes have been merged.

The PR train doesn't need to be dumped out in one go. It can come one at a time, each one with context around why it's there and where it fits into the grander plan.

The [totality] of the feature is split across multiple change sets, increasing cognitive load (coherence is lost)

A primary goal of code review is to build up the mental map of the feature in the reviewers' brains. I argue it's better for that to be constructed over time, piece by piece. The immediate cognitive load for each pull request is lower, and over time, the brain makes the connections to understand the bigger picture.

They'll rarely achieve the same understanding of the feature that you have, you who created and built it. This is whether they get the whole shebang at once or piecemeal. That's OK, though. Review is about reducing risk, not eliminating it.

You end up doing work on branches of branches, and end up either having to become a rebase ninja or having tons of conflicts as each PR gets merged underneath you

I've learned not to charge too far ahead with feature work, because it does get harder to manage the farther you venture from the trunk. You will get conflicts. Saving up all the changes into one big hunk doesn't fix that.

A big benefit of trunk-based development, though, is that you're frequently merging back into the mainline, so all these problems shrink down. The way to do that is with lots of small changes.

One last thing: It is definitely more work, for you as the author, to split up a large set of changes into reviewable pieces. It is absolutely worth it, though. You get better quality reviews; you buy the ability to deprioritize at any time and come back later; most importantly for me, you grasp more about what you made during the effort. If you struggle to break up a big set of changes into pieces that others can understand, there's a good chance it has deeper problems, and you'll want to work those out before presenting them to your coworkers.

The original report is just for ansible-vault, but comments indicate widespread effects, hence the altered title here.

Reminds me of a job posting sent by a recruiter that expected candidates to seek "professional and personal hypergrowth", "keep up with an unrelenting pace", and "thrive on change". Dealing with these facets of work in moderation is all well and good. However, these and other points led me to guess that they had set up a high-pressure, possibly chaotic environment, perhaps on purpose.

I opted not to pursue the opportunity.

Lawrence: Well, what about you now, what would you do [if you had a million dollars]?

Peter: ... Nothing.

Lawrence: Nothing, huh?

Peter: I would relax, I would sit on my ass all day ... I would do nothing.

Lawrence: Well you don’t need a million dollars to do nothing, man.

https://www.youtube.com/watch?v=4lmW2tZP2kU

Green!

By my reading, the outrage is likely coming from the cushioned stereotyping from the podcast participant. They're stating that "neckbeard types" and autists aren't customer-ready and are uncomfortable talking with customers. That second part is worse because it may lead to assuming that those folks would never want to talk to customers, or even learn how, and so the PMs might "protect" them by never offering them the chance, while assuring themselves "that's okay, that's great, I mean it takes all kinds".

It doesn't matter, if my employer would treat me as interchangeable anyway.

And even interchangeable employees deserve reasonable accommodations. I do think a union can highlight those needs more effectively than individuals (especially for interchangeable ones, to your point).

demand all kinds of ridiculous accommodations that you could never have reasonably asked for on your own

The union oughtn't seek "ridiculous" accommodations then. It should seek at least reasonable ones, and possible aspirational ones, and negotiate it out from there. The problem we're seeing now is that even demands that most would find reasonable are cast as ridiculous by management. And if a union has trouble getting employers to listen, there's no hope that someone on their own can.

I've personally lost faith that a typical employer is capable of recognizing the value of an individual employee. So many of the recent layoffs have not accounted for individual performance or criticality to the business (Twitter's being a good example). So my own value isn't as strong of a bargaining chip.

Possibly, at least for my own experience. It's much less often that I rerun a search with !g. Brave Search's results are becoming more relevant to my own queries, and Google's becoming less so. Not to mention how ads like to masquerade as ordinary Google results; using Google is starting to feel less comfortable.

GitHub should monitor their status page traffic for spikes, which probably mean something is wrong somewhere, even if they themselves haven't noticed yet.

The Wipeout game series has a broad set of racing companies complete with in-universe histories and branding that evolves with each release.

https://wipeout.fandom.com/wiki/Teams

I think it was this one, The Virtual Reality Construction Kit by Gradecki. The cover looks very familiar!

https://www.goodreads.com/book/show/3165591-the-virtual-real...

My favorite project ever in undergraduate was getting these glasses to work with a PC. We got the specs (pun intended) from online resources and a how-to VR book published at the time (mid-90s). My partner designed / assembled the circuit board to interface the glasses to the PC's serial port, and I wrote a display driver that would switch video pages and simultaneously trigger the glasses to flip shutters. The result was 3D on a PC screen.

The demo program was a robotic arm simulator that my partner already had on hand, since it could easily render wireframes. The updated simulator rendered two wireframes of Optimus Prime, so with the driver in place, he floated in front of the screen.

And, of course, you could rotate him in space, and then hit the space bar to transform him in 3D.

Reading carefully about image deletion:

* "public images will only be removed from Docker Hub if their maintainer decides to delete them"

* "Public images will only disappear if the maintainer of the image decides to proactively delete it from Docker Hub. If the maintainer takes no action, we will continue to distribute their public images."

This sounds good, but it would be better to explicitly say "if you opt to let your free organization be suspended, Docker Hub will continue distributing your public images indefinitely anyway". It feels like there's a loophole here where if a public image comes to have no maintainer - because they abandoned its organization - then it no longer benefits from this assurance. That seems unlikely, but given how this change has been going so far, it's tough to give Docker the benefit of the doubt.

Sticking with the analogy, there are still others who suffer while one person is punished with jail time or otherwise. If the single earner in a household is locked up, their family suffers in many ways. If they happen to run a business, their business and employees suffer too. And none of them did anything wrong.

The problem is with the scale of punishing an entire company, though. There's a lot of fallout from that, it's true. So the punishment would need to be fair, limiting the offending entity as a whole without unduly harming innocent employees. This could be where the analogy breaks down (which argues towards how unfair the personhood of corporations is, if there's no good recourse for wrongdoing).

As for a chilling effect ... yeah, that's the idea. Employees in a company would be very much more interested in staying on the right side of the law because of the heightened risk to, well, everybody.

I'm reminded of businesses that need to stay accredited, or licensed, or otherwise in legal compliance with something in order to function at all. If one errs enough (criminally, say), it loses that blessing, and could end up folding, and all the innocent employees are out of a job.

It's interesting to think about "jailing" an entire company for its crimes. After all, in some legal (US) ways, a corporation is considered a person. If a company is found guilty of committing some crime, penalize it in an analogous way to a human. For example, if a person guilty of X ends up in jail for 30 days, a company guilty of X ends up ... here I'm not sure. Barred from doing business at all for 30 days? Forbidden from communicating with its customers? Cut off from, say, paying its employees? All things an imprisoned human would be unable to do themselves.

I can't tell if the idea makes much sense, but there's a symmetry there, specifically around the personhood of corporations.

Here's an explanation of DoOcracy, as linked from the open letter:

https://communitywiki.org/wiki/DoOcracy

(If you're like me and hadn't heard of the concept before.)

Let's also not forget the Lack's crucial role in forming the Standesk 2200, a classic standing desk hack:

https://alphacolin.com/ikea-standing-desk-for-22-dollars/

Thanks for the anecdotes!

Well, I'm proceeding from the assumption that thoughtful review, which takes time, is desirable. If the situation is really that dire, then it's even more important that you ship product that works. Code review happens to be one of the, if not the most, effective ways to catch bugs and prevent disasters. It's a good idea to make the review process work for you, even and especially when the pressure is on.

It's not about humongous reviews being "inconvenient". A drop of thousands of lines of new code takes a long time to review thoroughly, whether the company is at risk of folding tomorrow or a stodgy enterprise with decades ahead of it. If you have to constrain review time - or ditch reviews altogether, why not? - you can, but there are consequences regardless.

I haven't worked in early startups, but I haven't only worked at large corporations either. I hope that most of us, most of the time, aren't less than a business day away from unemployment, and so there's usually time for code reviews. (If not, there's a lot of useless material about it!)

Without sarcasm, and potentially getting off-topic, I would like to hear stories about how a startup survived impending doom with heroic, fast shipping of product that set aside a lot of time-consuming processes. What were the most crucial steps to keep? How was the technical debt repaid?

First, think about how difficult, and time-consuming, it will be for others to digest and review 2500 new lines of code that sprung from someone else's mind. So you will end up waiting anyway, for even a small part of your work to be merged.

The work of breaking up a big, inspired chunk of work into small pieces helps you learn more about it, and the perspective can reveal improvements that weren't obvious in the initial effort. You might notice those yourself, or reviewers may. The final outcome will end up overall better for it, so spending that time is worthwhile.

This sounds like a variation of Brooks's Law - adding people to a late software project makes it later. In this case, now you need to take time to help the new resources ramp up, and the new resources themselves can't make meaningful contributions right away. So the pressure isn't alleviated for a while, and in fact goes up.

Maybe he will bounce back with that new position.

(Ref: https://www.space.com/elon-musk-spacex-launch-trampoline-com...)

From https://ublockorigin.com/ itself: "The uBlock Origin project still specifically refuses donations at this time, and instead advises all of its clients, users and supporters to donate to block list maintainers."

As an example, I donate to https://patreon.com/blocklist . Amazingly, right now, there are only 43 patrons.

One suggestion I have is to update the "How to Request" section, which lays out a procedure for asking for a commercial license. It'd be simpler if the license terms require the licensor to provide contact information for commercial licenses in a defined location. That would help "guarantee[] ... paid licenses for big business are available on fair terms"; there's some consideration in this license for the rights of the big business here.

If the licensor can't be bothered to provide contact information, then they aren't upholding their side of the deal, considering the purpose of the license. The licensor could always use a different license, then.

ETA: It also makes the process for getting the license cut and dry. It's easy to determine if enough work was done by the big business to contact the licensor: did they use the contact information required to be present or not?

Humility is very important for coding (most things, really). Everyone writes "questionable" or "ugly" code, so it's important to accept that as much in yourself as you do for others. Think about what you would say to someone else in your position: would you be as critical of them as you are of yourself?

Moreover, in the early days of a new company, the priority is to get something working to create income - sometimes, quality be damned. Otherwise, there's a good chance the company won't survive to get the chance to hire people who will get the opportunity to criticize the code that made their employment possible.

"${stuff[@]}" expands into the elements of the array, with each one quoted - so even that first "foo foo" element with a space will be handled correctly. That is how I would write the loop as well, in general.

However, your technique also works, with some tweaks:

* The loop goes one index too far, and can be fixed with seq 0 $(( array_length - 1 ))

* There should be quotes around ${stuff[i]} in case it has spaces

I happen to have just written a do-nothing script, so I can answer why I found it helpful vs. a do-something script.

- I am still developing the procedure in the script, so it is premature to automate. A do-nothing script still benefits you by telling you exactly what to do - in my case, spitting out exact commands to run - but you can assess its steps before performing them.

- The script still gathers a lot of information and associates it together in order to figure out the correct commands. That work is valuable all by itself.

- Even though you have to run commands yourself, it's copy-and-paste vs. hand-typing, so it's already less error-prone.

- The script documents the procedure even without automation, so the benefit is immediate.

Now, I think that it's better for a do-nothing script to _evolve_ into a do-something script. But, if that effort is delayed or never happens, at least you've got something.

I agree that the blossoming of additional JDK distributions, spurred on by Oracle's initial license change, was a good thing. I'm a happy AdoptOpenJDK / Temurin user, at work and at home.

However, I don't see any benefit to this latest change in their stance. Everyone already had to wade their way through the confusion from that initial licensing change, and many (most?) spent a lot of time and effort getting to a new stable configuration on a different distro. Why spend more effort, again, to run back to Oracle JDK? I think most organizations have better things to do than deal with all this.

Also, who's to say Oracle won't change their licensing deal once again for Java 21?