sirmarksalot

A union is a power structure like any other, and unions get corrupted just like anything else. They need to be maintained by their members, otherwise they will prioritize the needs of their administration over the needs of their members. It's still better to have a union than to not have a union, but having a union doesn't magically solve everything. Try looking up what a "dues strike" is.

This looks interesting to me, but I've been looking for a language learning app that goes beyond flash cards and SRS as its core teaching concept. SRS is great for learning individual vocabulary in a vacuum, but kind of falls apart when you need to teach bigger concepts like number systems, grammatical theory, or conjugation rules. If you've already been taught the rules, then an SRS app like Wanikani can be a really great supplement to that, but it's not going to serve as a full learning experience.

This is where I find Duolingo and its imitators really frustrating, and I've been looking for a higher-effort product that actually uses subject-appropriate teaching strategies, and not treating SRS as a silver bullet.

The "puzzle" feature here looks interesting, so I'd like to see how integrated it is with the concepts, vs. being another view onto "word <-> translation" and SRS.

Depends on how you define "insecurity". Availability is one of the pillars of security, so even your joke falls apart.

Several years ago the trendy thing to do for security was to get a USB-A security dongle and lock your important accounts with it. Nowadays, laptops from several major manufacturers no longer ship with a USB-A port, so if you need to log in again and don't have a USB-C dock handy, you're locked out until you can find one.

> And don't be afraid to use negative emotion as a pointer for where to start

This is so important. My therapist would say that negative emotions like anxiety and anger are information from your body. It's not always useful information, and maybe acting on your first impulse isn't a good idea, but you shouldn't just ignore it because it's supposed to be bad.

Meaning that the main viable use case for them now is intra-site navigation, i.e. the menu bar at the top of the page.

I didn't mean to contradict you, just elaborating on it a little more and taking it in a slightly different direction. I think even with your caveat, there's still an implicit belief that there's still a relationship, however distorted, between what the user pays and what the seller does with your data, and my point is that the incentives just don't seem to work that way.

I'm gonna go out and assert that the statement "if you're not paying, you're the product" has never been true on a large scale. Rather, the two are unrelated. In this day and age, you are always the product, whether you're paying or not. And back in the 2000s when I first started hearing that adage, it was only true on the most transparently awful platforms. It was really just a thought-terminating cliche meant to shush anyone who bothered to complain about a free website doing something bad. The difference between then and now is that we now know how to monetize somebody's data in a way that solo startup founders in the early 2000s didn't. Sure the science probably existed, but it wasn't obvious to somebody making a website that that was how you make money.

Nowadays, the process of converting daily active users into monetizable data is trivial, so that's what everybody does, again regardless of whether or not you paid. When you think about the economics of it, your value as a commodity does not decrease just because you paid for something. No matter how much you pay for your subscription, your data is always valuable, and the only reason Netflix doesn't force ads on all their subscribers is because it'd look bad for them. But behind the scenes, do you really think they're not selling your interaction data just because you subscribe to the most expensive package? Monetizing users has always been a function of ease of implementation, not the out-of-pocket expense of the user.

Run cables along baseboards, under rugs, under doors, along the stair runners, etc. If the cable needs to cross an egress point, put a rug over it. If you can convince your landlord, drill a single hole to bridge the upstairs and downstairs. If you're in an older house that has straight cold air returns (not a heating duct), drop a cable through there, and pin it to the crown molding.

I think it's more likely that they've bought more accessories than you and get bit by more incompatibilities. I think the issue is that there's nobody designing the entire end-to-end experience of what happens when you use every accessory with every feature turned on. I'm sure there's QA on all of it, but tickets don't magically create an architecture.

I've noticed the same thing. In in-person conversation, I'm usually slow on the draw when it's time for the next person to speak, and if I'm with interrupters, they almost always beat me to it. But in video calls, the extra round trip of lag gives me just enough quiet to signal that it's my turn to talk, so I don't get shut out quite as much. Even if someone else is quicker on the draw, I've already started talking, so I don't just instinctively shut up when I hear another person going first.

Yeah, there was that whole South Park episode where they argue that the slur should be repurposed to refer to people who ride motorcycles too loud and turn left on red, but unfortunately that's just not how slurs work.

"kind sir" was auto-replaced with "kind f**"

I remember when that happened. "Sir" or "kind sir" had become a cliche, and the mods added a replacement filter to discourage people from using it. Understand that SA at the time lived by the edgelord ethos, "if I don't mean it literally, it's not offensive," so this kind of thing wasn't seen as homophobic, even though it totally was.

Good rain gear and a set of fenders feels like having super powers.

A system that requires nearly everyone to drive cars is not compatible with disabilities. If fewer people drive, it frees up road space for people who actually need to drive, as opposed to people who drive because it's the easiest way to get around. Also note that cars are often not a good fit for many kinds of disabilities. Public transit works much better with only minor modifications.

My friend has one. It's the only one I've ever seen.

A couple of my (Asian American) friends swear by Kask helmets for this reason, though they're quite expensive.

Living in a city, the idea of leaving anything of value on your bike, and expecting it to still be there when you get back is completely foreign to me. When I visited Amsterdam, I even had the seat stolen off my rental bike. Biking in the states means carrying a helmet inside with you everywhere you go, and it absolutely sucks.

Not sure what point you're trying to make here. Are you arguing that companies shouldn't have DEI initiatives because they didn't help sufficiently in this case? Do you interpret this as evidence that DEI is somehow bad?

This reaffirms the flawed notion IMO that the value of patents is in protecting ideas rather than the expense incurred in the development and validation of those ideas. A lot of the romance over patents is based on the idea of a lone inventor waking up one morning with an earth-shattering discovery, when the reality is that in most circumstances, those kinds of ideas are thought up by multiple people at roughly the same time, and rewarding the first person to write them down is counterproductive.

However, in the case of things like industrial patents or drug patents, where there is considerable cost in shepherding a design through a complicated regulatory framework, it makes sense to give the company that fronted those costs some kind of temporary protection from unfair competition. If you look at patents under that lens, it makes economic sense that an AI generating an algorithm over the course of hundreds of hours would be patent-worthy.

I noticed something like this with Nintendo's early Switch games. Both Breath of the Wild and Mario Odyssey had a design philosophy that something should always be just over the horizon, waiting for you to explore. It sounds romantic in theory, but the problem is that the game never gives you a good place to take a break, and it drives that same kind of addictive behavior you're describing.

It's a set of design habits that served the industry well back when they were trying to get people to pump in money, but which don't really do anyone any good when it's just you at home on a fully paid-up console game. It's not malicious, it's just a habit that got uncritically elevated to a Best Practice.

You are factually correct, but the intentions are a bit murkier. The explosion of video arcades in the 70s and 80s was due to how lucrative the machines were as an investment, not due to any passion on the part of the owners. The value proposition for arcades at the time was basically like gambling, but not illegal. While arcade games have always been skill-based, that's not the same as "fair," at least in the modern game design sense.

Yes, with repetition, you can eventually learn to beat Ghosts and Goblins on a single quarter, but the game is not going to just let you do that on the first try. Games of that era are designed to lure you in, then kill you with something completely out of nowhere after your 3 minutes are up and it's time for the next person in line to put in their money. This self-reinforced when you saw someone who had put in the reps getting really far on one credit, so you would think you can do that. But no, you can't. You die at the end of the first stage like everyone else.

It's not gambling, but it's still designed to extract money as efficiently as possible.

You're restating the article's point. Naive DRY says make the dumb analyzer happy by abstracting out the coincidental similarities. If you work in a place that recognizes that this can be a red herring, then great, but a lot of developers and teams don't make room for that nuance. That is what the article is arguing against.

The large file problem is a major issue in games, and basically means that developers who would much rather use Git, don't have the option of using Git because it would be crushed under the weight of all the art assets. So instead everyone's forced to use Perforce or Subversion, with all the workflow impediments that involves.

Depends what you mean by "change the model your brain [uses]". In terms of the fundamental model of how Git works, it perfectly describes what users actually want (get me the repo at revision X), but not what they expect (get me file A, revision 5, and file B, revision 7, and pray it builds).

In terms of the metaphors for the actual commands, I would agree. Reset and checkout basically make no sense for what they're actually used for. Switch makes things a bit better, but yeah, it would be nice if the entire Git CLI could be redesigned from scratch.

THEN WHY ARE WE YELLING?!!

I DON'T KNOW!

To everyone asking "what else works better," I remember using Product Studio at Microsoft, which was a thin client over an SQL database. It had some flexibility problems, but it was so, so fast. It's the only ticket management system I've ever used that didn't feel like it was getting in the way. Unfortunately, about 10 years ago Microsoft chose to modernize/dogfood on Team Foundation Server, which was just awful, probably worse than JIRA. I have no idea what they're using nowadays.

I wonder if the performance we got out of Product Studio had more to do with having a locally hosted instance, vs. running in the cloud, and I wonder if teams that host their own JIRA/Confluence/Bitbucket servers have a better experience. I do find that one of the major gripes people have with planning tools is that they break flow, and I wonder how much of that comes just from the amount of stamina required to maintain focus while waiting for all the spinners.

Yeah, so the details really matter here. A lot of people hear "In country X they live on $2 per day," and think that you can experience the same standard of living in that country as you do in the US. But that's really not the case. Even in places that enjoy a relatively high standard of living, while things like food and rent are cheap, all the things that are imported from the developed world cost exactly the same, and it just means that people can't afford them. Everyone may not want to live in America, but they all want to have the luxuries we enjoy, and which are enabled by American salaries.

But standard of living isn't really the reason someone would be miserable at work -- the real thing that makes this a bad arrangement is loss of agency, both for the off-shore contractor, and for the supervisor. This is where I accused you of not having done this before, because in my experience, and several friends' experiences, working with lower-paid, lower-experience software teams is extremely frustrating.

As others have pointed out, coming up with specs is a frustrating and unsatisfying process, and is akin to writing code, except that you don't actually get to run the code and see the fruits of your labor. Because of your working arrangement, the people actually making the product don't have the agency to take ownership of its architecture, and instead you get a whole bunch of copy-paste. If you push back and say, "no, this isn't what we agreed to," then they push right back and say that your requirements are unreasonable, because they don't have the expertise to architect the project right.

But suppose you decide you don't care about architecture, because that's what expensive people do, and you're hiring cheap people, then what's the harm? They can do things their way, even if it's less efficient, right? Except that now the team living with the bad architecture is responsible for fixing all the inevitable bugs that come up, and every time a bug is "fixed," another bug pops up somewhere else, and you, the supervisor/customer, are now responsible for all of it. You can keep filing the bugs, but you can't fix them yourself. Or maybe you can fix them yourself, but you can never improve the overall design, because your decisions will always be overridden by the copy-paste brigade doing the "real" work.

It's a world where all the code bases are awful and nobody gets any job satisfaction.

I suspect you've never been a technical liaison to an offshore team. I believe your vision is to replace all satisfying work with soul-crushing work. If all your work is done by people who don't want to work there, including the supervisors, then what kind of quality can your company expect?

I think the Agile Manifesto is an exercise in subversively asking management for a very reasonable-sounding thing that is completely impossible: autonomy. Every line poses a threat to a well-known corporate best practice, and the natural reaction is to co-opt the message and bring the items in the left column back into the right column.

In the case of Scrum, it's that "individuals and interactions over tools and processes" line. Scrum did start out as a popular Agile methodology among developers, but because it was the most prescriptive and process-oriented of the methodologies, it got adopted and twisted by management and turned into a tool to reassert authority. Now it reasserts that tools and processes are, in fact, more important than individuals and interactions, but this time with the "Agile" label.

I'd love to try working on a Scrum project that doesn't rely on JIRA. Just notes on a corkboard with a quick "need anything?" conversation in the morning.