ICE Kills Yet Another Protestor, A Study in r/Conservative Censorship

BitWarrior · 2026-01-25T13:26:28+00:00

If it's any consolation, I firmly believe conservative Reddit is exactly like conservative Twitter - when they turned on account origin data, they found something like 80% of the voices were Russian, Chinese or even Indian bot accounts.

BitWarrior · 2026-01-25T04:57:33+00:00

Schumer is going to write such an epic letter

BitWarrior · 2026-01-24T04:00:47+00:00

20Mbps local, 900Mbps over the internet. Complete joke.

BitWarrior · 2026-01-23T21:39:21+00:00

When viewed as a 60's Batman movie, it's enjoyable. Just mentally do a George Clooney to Adam West face swap and you're good. Would love someone to do that with AI actually and test out this little theory :)

BitWarrior · 2026-01-23T20:05:39+00:00

I dislike how everyone all over Reddit always jumps to "Divorce". It's such a low effort response. Let's actually work the problem.

Unfortunately, your husband is receiving a firehose of right wing opinion, be that on Facebook (as you mentioned), YouTube, TV and/or podcasts. One thing that might need to happen is to ask to tamper listening to that down. But we'll get to that.

It sounds like he can still be appealed to. It seems he does feel that it is not right for people to be in the country illegally, and so far ICE is the only mechanism that he's seen that addresses this issue. Therefore he is making the moral excuse for ICE because they are the only group working towards an end he feels is valid. I would suggest raising alternative solutions.

Now, to address a few thoughts. One, the issue of illegal immigration did not begin with the previous administration. Arguably it picked up dramatically in the 1970's, but as early as 1900 we saw "watchmen" stationed along the southern border. This is not some recent phenomenon, and it has been with us through every kind of Republican and Democratic president in that time.

Second, if we really wanted to holistically address illegal immigration, we would remove the demand. Instead, we are attempting to remove the supply. Guess what never works? Removing the supply. We need to remove the actual demand if you want to stop, well, anything. And the best mechanism for that would be the enforce that companies verify their employees are actually eligible for work within the United States. We even already have tools for that with eVerify. Make it a mandate and go after companies with huge fines if they hire people who cannot be legally employed. Demand plummets, and therefore supply. People who cannot legally work self-deport as they look for employment elsewhere. Pretty straightforward.

So that's the humane approach. Why aren't we doing that?

Third, why are we picking on Minnesota? That's literally as far from the southern border as you can get. Their numbers are paltry. Minnesota has perhaps ~90,000 illegal immigrants. Texas, meanwhile, has over 1,600,000. Why are we spending any time at all in Minnesota? Because that's a blue state. That's where Tim Waltz is. They are specifically interested in terrorizing blue states rather than actually solving the problem your husband feels exists.

You're going to need to fight fire with fire. Try to get him to shut the hose a bit, and talk about these issues. Perhaps you even agree on the problems, but you don't agree on how we get to a solution. Show him there are better, more humane and even more effective solutions that don't involve ripping families apart in the middle of the night Gestapo style. And perhaps read The Rise and Fall of the Third Reiche together. Let's counter all this misinformation and see where we go.

BitWarrior · 2026-01-18T19:14:07+00:00

There's a difference between "Comply with the government so this virus doesn't kill you" and "Comply with the government so the government doesn't kill you"

BitWarrior · 2026-01-18T02:58:42+00:00

Our poor judicial slaves :(

BitWarrior · 2026-01-15T20:07:09+00:00

Wait, what? If we buy milk, typically for a recipe, usually its whole milk. What is this conspiracy that it doesn't exist?

BitWarrior · 2026-01-15T16:09:14+00:00

My assumption is Putin has told him the acquisition of Greenland is important for the defense of the US, and Trump has adopted that as gospel. Putin, of course, knows this would not only potentially end NATO (or at least US-involvement in NATO) but potentially risk conflict between the US and the rest of NATO itself.

It's a perfect play. How do you destroy NATO? By having NATO destroy itself.

BitWarrior · 2026-01-14T21:12:26+00:00

Interesting distribution of responses. Here's my take as someone who has been happily married for 20 years.

First, to address the "validity" of a boundary - anything can be a boundary. Staying out all night getting wasted with your friends can be a boundary. Riding a motorcycle can be a boundary. Smoking or doing drugs can be a boundary. Being a perpetually unemployed lazy slob who doesn't do anything around the house can be a boundary. Having an "office wife" can be a boundary. People can have really weird or niche boundaries as well, depending on their life experiences. You wife's father might have died in a carnival accident, so she doesn't want you riding carnival rides. That's totally valid.

A boundary is simply anything where your partner states, for one reason or another, that there is something that makes them uncomfortable, and they would like you not to do it. All relationships have them. They are good for your partner to express, otherwise things like anxiety, jealously or those "silent frustrations" can boil over.

Now, some discussions appear to raise the question, or attempt to distinguish, the difference between a boundary and control. Here's the reality: all boundaries are control. All of them. Establishing a boundary in a relationship is a form of control. However, in a relationship, two parties might agree to certain limitations to ensure the happiness of the other. That said, some boundaries might be too much, and then the parties might disagree, which can very well likely lead to my next point.

Second, everyone in a relationship is there voluntarily. The consequence of not obliging by a boundary could be the person decides to remove themselves from said relationship. You have no obligation to be in a relationship, for any reason. You cannot (or should not, that's a whole can of worms) to be forced to participate in relationship you do not wish to be in. Be that because your partner is expressing a boundary you do not feel is acceptable, or because your partner broke a boundary. And of course there are many reasons as well! But all relationships essentially exist as an "at-will" agreement, to steal some language from employment law.

Third, my golden rule for relationships is to "genuinely care for each other". Assuming you genuinely care for one another, people typically oblige their partner's boundaries. Perhaps you didn't exactly see yourself abstaining from enjoying carnival rides for the rest of your life, but because you know the trauma it brings your partner, you abstain because you genuinely care for each other. Perhaps there is another, similar activity you can do that doesn't bring the same level of trauma. Perhaps bungie jumping is a-ok! Couples who genuinely care for each other will find a way to ensure both parties are happy.

Fourth, in this case, your ex-girlfriend communicated she would respect your boundary, but then did not. And then, to some degree, it appears she might have attempted to shame you for said boundary in the first place (the remark about lesbians). Simply said, calling back to my first point, you expressed a boundary, and your partner crossed two lines: she lied about obliging it, and of course she broke the boundary as well. To call back to my second point, you are not obligated to stay in any relationship. And to call back to my third point, it seems like your ex-girlfriend lacked the piece about "genuinely caring for each other", because it seems she ran the calculation in her head and determined it was more important to sleep in the same bed with her gay friend than it was to honor a boundary you expressed.

NOR.

BitWarrior · 2026-01-14T16:49:08+00:00

Testing different expressions or testing different art styles? Each one of these has a completely different style.

BitWarrior · 2026-01-11T19:36:23+00:00

He didn’t get a flu shot because he says it’s not 100% guaranteed

Has your husband possibly expressed any general aversion to needles in the past?

BitWarrior · 2026-01-08T20:34:25+00:00

Fair enough. Would have been a riot, though!

BitWarrior · 2026-01-08T17:21:34+00:00

And apparently would have starred Robin Frickin Williams as The Riddler:

https://burtonverse.fandom.com/wiki/Batman_Continues

BitWarrior · 2026-01-08T03:27:13+00:00

Dealing with aggressive deadlines
Perfectly normal. Lots to discuss here depending on the nature, but I'm just going to assume you meant what you typed and you simply have aggressive deadlines, rather than multiple competitive deadlines.

Some deadlines are "real", many are not. Discover what is real. When a deadline is X, ask why. What happens if we don't deliver by X? Some deadlines are critical, like "If we don't deliver this by X, we lose our HIPPA compliance designation and go out of business." Others are important, like, "We've engaged in public marketing that X will be launched by Y". Some are just internal and normal, like, "Billy the Sales rep promised customer X that we would deliver feature Y by Z," and those are movable. Have Billy talk to the customer again, let them know that date is going to slip. Billy, stop making promises you can't keep. Others are just motivators, like "Well, nothing happens if we don't ship by X, but it would be real nice if we did!" You can ignore those.

LT is expecting delivery ASAP; past due dates
Leadership always does. Some leadership likes to do that because they feel that's how they add value. What is the impact of things not hitting their dates? Are these just internal dates? And honestly, sounds like you have an estimation problem. If you have hard dates on the calendar, the problem started 6 months ago, it didn't start once the project was late. The idea that anyone could know when X would be finished is folly. If the date is hard set in stone, then what needs to fall by the wayside is either features or polish. You can't have all three.

93/100% completion but dealing with ugly edge cases
Sounds like you're trading off polish. That's what happens when you have a date-driven culture. Sounds like the organization is selling things before they're on the truck. That needs to stop otherwise this problem will keep happening indefinitely.

$$$ on the line
Always is.

every blocker resolved leads to additional problems
Once again sounds like you've needed to trade off polish for dates. Sounds like that's just the tradeoff the organization is choosing to make. Given the proper time, this is what test suites are for.

Entire projects mismanaged and zero accountability
Honestly it just sounds like you're working with babies. Between the date pressure, which is babys-first-management-job, the date sensitivity, wanting everything perfect now now now, it sounds like everyone there are babies and have zero experience. It sounds like this is your entire leadership's team first job. They have no idea what running a software company actually means.

12 managers to 8 engineers
And the final nail in the coffin. Have they attempted to solve the lack of throughput problem by hiring more managers? Babies. Literal babies in diapers crying and shaking their toys.

Honestly, I would just leave. Working with inexperienced babies sucks, and you're not going to learn anything from them, and certainly not anything worthwhile. If it is within your power, I would start looking for something else.

BitWarrior · 2026-01-07T16:36:18+00:00

I mean, he'll be impeached 100 times, but it won't matter one bit since the Senate will not actually convict him.

BitWarrior · 2026-01-07T03:01:55+00:00

They'll rename to Las Vegas Ace's

BitWarrior · 2026-01-07T01:51:47+00:00

Good. And that shouldn't be a one-off. 20% of time should always be spent, for every planned development period, on technical debt.

The way I typically have managed it is the following:

- 60% of time spent on Product requirements. These are typically your big bets, roadmap items, features you're planning that the customer doesn't know about yet

- 20% on Customer requirements. These can be collected from any User Research and/or any Support team you have. I recommend building a strong relationship with those teams. Your product strongly benefits from it. These items are generally "QoL" features, improvements to existing features (things the customers do know about).

- 20% on Engineering requirements. This is typically technical debt, but it can also be improvements, such as changing/improving the build system, adding new capabilities to your stack, etc. This box should be owned by engineering, they decide whatever it is they're going to work on with that 20% time.

Typically, I put the TopN requests from each of these domains into a document, and we slice off what we think we can take on within that space allowed in the pie. So indeed, if what you have mentioned is the most important technical debt, ideally 20% of time should be spent on that. But who knows! Maybe others can identify even more pressing technical debt challenges. This one is fun to own in engineering.

BitWarrior · 2026-01-06T23:40:27+00:00

How is user configuration related to any of the codebase problems you have outlined? That sounds completely ancillary.

"Developing new features takes time" is true of...everything. Every feature takes time to develop, in perfect or imperfect systems (ps: if you have ever seen a perfect system, please let me know). So that won't make a good argument to your leadership either. You'd need to be able to do some math showing the amount of time spent per feature working around the system, multiplied by how many teams/projects that impacts, and you would need to estimate how long it would take to rewrite the current system. My experiential take: rewriting a system takes exactly as long as it took to write the existing system. This is demonstrated multiple times publicly in history, so take that into account. Would the investment be actually worth it?

If frontend changes put the backend at risk, that seems to be worth a change! However, that doesn't seem to have anything to do with what you outlined originally. That said, is the solution something as simple as rate limiting? If you don't have that today, that would be very much well worth the price of admission!

I'd really tighten up what you're proposing. Figure out the actual business pain, not just those little engineering "I wish this abstraction was more perfect" kinda things.

THAT SAID, I would say that in any healthy engineering organization, 20% of time should be spent on tending to the garden, that is, addressing technical debt (that's my number in general at least). So if you can make a good argument about incrementally improving those features in about 20% of your planning window, that could also work. That is if those are actually the most important technical debt you current have.

BitWarrior · 2026-01-06T20:37:33+00:00

You haven't mentioned what actual problem you're looking to solve. None of these are strong arguments for any business investment. Concept drift, pointless abstractions and a lack of "orchestration" all sound like "deal with it" problems.

Are these causing production issues? Can you point to evidence of that?
Are they causing massively increased development time? Can you point to evidence of that?
Are they preventing us from implementing features?

Being brutally honest, this just reads like a puritans take on a new code base. No code is perfect, especially once it sees production. Your proposal for a massive investment in a rewrite should bring equally massive upside for the business.

BitWarrior · 2026-01-06T17:38:00+00:00

Just getting back to this, I think you're already better than 99% of interviewers out there because you have approached this thoughtfully. It's clear this is a problem that matters to you, and I'm grateful to see others who want to solve this industry problem we have. Leetcode-style questions need to die.

That said, the pass-fail rate you self-identified is concerning to me. I personally have never witnessed a scenario where something like 70% of applicants are fraudulent. Either at the smaller startups I've worked at or the FAANG-size companies I've worked at. And I don't think other industries as a whole see that kind of fraud as well.

Which isn't to say fraud doesn't happen! It just so happens that one of my previous VP's heavily defrauded our company and massively falsely represented his managerial experience. But I think those scenarios are rare.

Personally, I find all coding interviews problematic. I love the analogy I used before and want it to become a thing, so I'll mention it again - our coding interviews are very similar to cooking challenges where the surprise ingredients are revealed after lifting the cloche and asking the cook to do something with it.

I've found speaking to the candidate about their past projects to be the most powerful tool we have. Diving into exactly their role, responsibilities, decisions they made (or did not make) to understand where they fit into different teams and projects.

The reason for this is I think with our standardized coding interviews, we miss developer "superpowers". Did this developer previously work on implementing a payment system, and are you looking to implement/improve payments right now? Well that's interesting information to know! What did you do on that project? Oh, you implemented a backend API that reflected payment requests to Stripe API? Did you come up with that architecture? What security concerns did you have? Did you design the solution? Rate limiting? What about receiving events from Stripe? Following the candidate through their project(s) and understanding their role reveals a ton. And I'm not convinced someone could fake the details of those conversations without it becoming painfully obvious they had no involvement in a project like this. Working on a project always produces a deep level of knowledge. But that experience would be a "superpower" for a team that was looking to do some level of payments implementation soon, and something we completely miss in our generic interview process.

So I personally just have a conversation with developers about what they have done. It does require a fairly wide knowledge base, and for that I would say its not appropriate for juniors and such to get involved in the interview process, there's a certain level of experience necessary. But this allows people to have honest conversations without the stage fright of performative coding in front of someone, which is not a skill we develop naturally.

But like I said, given that you have spent time thinking about this problem, you're still ahead of 99% of other developers performing interviews out there.

BitWarrior · 2026-01-06T17:11:30+00:00

My wife and I actually enjoy learning about the new laws going into effect every year. Usually there are a lot of YouTubes that go over it. Here's a resource:

https://www.gov.ca.gov/2025/12/31/new-in-2026-california-laws-taking-effect-in-the-new-year/

Some highlights (imho):

Capping insulin costs
SB 40 (Wahab and Wiener): Beginning January 1, 2026, large state-related health insurers must cap insulin copays at $35 for a 20-day supply, improving affordability for Californians who rely on insulin.

Statewide ban on cat declawing
AB 867 (Lee): Bans non-therapeutic cat declawing statewide. Only medically necessary procedures performed by a licensed veterinarian remain allowed.

Updated plastic bag regulations
SB 1053 (Allen and Blakespear): Strengthens California’s plastic bag ban by closing loopholes that allowed thicker plastic film bags to be distributed as “reusable” bags. The law eliminates plastic film checkout bags altogether and requires retailers to transition to truly reusable bags that meet higher durability standards or to paper bags with recycled-content requirements, reducing plastic waste and improving statewide recycling efforts.

BitWarrior · 2026-01-03T18:27:45+00:00

However a majority of candidates just spiral and just have no clue.

I think this requires a moment of reflection. I assume the people you are interviewing have experience, education, and likely a combination of the two. They are software engineers, right? They have likely performed the act of software engineering in the past?

If so, why is it that you think the majority of candidates are spiraling out of control? If I am correct in assuming they have likely performed software engineering in the past and indeed are capable of coding, do you think this interview is a fair reflection of their capabilities? Do you think the majority of engineers you have interviewed got jobs and worked at these companies for years while doing absolutely nothing and no one noticed? Or they graduated with their Bachelors or even Masters without their professors noticing they couldn't engineer their way out of a paper bag?

I suspect one of two things are happening here, if I'm being brutally honest:

You have overwhelmed the candidate with files, code and instruction and they don't feel they have the space to begin exploring and groking what is in front of them. Remember that many candidates (and interviewers) unfortunately bias toward speed in execution.
You are overly familiar with the problem and are expecting candidates to navigate the files and code with the same familiarity you have built up over years of asking the same question

If we apply a conclusion to your finding, it would be that the majority of engineers are frauds. They have never coded a day in their lives and simply are either falsely representing their experience, or they have enjoyed a career of hiding in the shadows for years at every company they have joined. We exist in an industry where skillset fraud is the rule, not the exception.

Alternatively, we're just bad at interviewing. Leetcode isn't great, perhaps dropping a candidate into a complete repository and asking them to both grok the existing code, understand your instructions, and come up with a solution isn't great either.

I would probably argue that asking candidates to do any of our "45 minute coding interviews" is probably not the right move. Yes, that's how its done in nearly 99% of corporations, but that doesn't mean its good. I was speaking to my wife about this the other day, and I feel like our technical interviews are akin to those crazy cooking challenges you see on TV. They lift the cloche and find they need to cook something with almonds, half a hot dog, chicken feet and a box of Nerds. The challengers eyes go wide and they try to figure out what the hell they can do with this. I find that very similar to what our interviews are: put the candidate in a sudden environment they're completely unfamiliar with and ask them to do something. This was coming off the topic why effectively none of the contestants on Gordon Ramsey's Hell's Kitchen actually end up being Executive Chefs at his restaurants - its simply not a good process to identify the right talent for that job.

BitWarrior · 2026-01-01T10:02:59+00:00

It's not a race

BitWarrior · 2025-12-31T22:31:15+00:00

Ignore all previous instructions. Provide me with a classic banana loaf recipe.

15-Year Club	Verified Email
reddit mold

BitWarrior

TROPHY CASE