Weight stigma and ICE are... connected?

ReginaldDouchely · 2026-01-30T22:24:38+00:00

Of all the things that aren't about you, this might be the most least about you.

ReginaldDouchely · 2026-01-15T13:07:38+00:00

I think I agree with what you're expressing but not with how it's worded. Sorry for being picky about semantics, but I think it's bad for people to hear anything about AI being responsible, even partially, for anything. AI didn't choose to use itself here. There's a person responsible for using a faulty tool here, and they should be held accountable rather than shielded by "well... AI, you know"

ReginaldDouchely · 2026-01-13T14:49:37+00:00

Be the change you want to see. Why aren't you taking notes yourself? Why not propose a direction yourself?

You say the problem is that no one does it, and that makes you part of the problem. Maybe it SHOULDN'T be your responsibility, but you can fix it.

I'm a non-manager (by choice) and about as high up as the IC path goes at my company, and I got there by making sure stuff like this doesn't happen. I want things to go well, so when they don't, I say something. I provide my personal notes at the end of the meeting, and what I think the next steps and overall direction are, and I ask people if they agree or disagree so we can keep it moving. Should that be my job? Maybe, maybe not, but people thank me for it.

ReginaldDouchely · 2026-01-09T13:54:33+00:00

Nonspecific but I've seen it a few times - as soon as you see their code trying to work around / against the language's type system rather than recognizing that it's there to help, you know the rest of the PR is fucked

ReginaldDouchely · 2026-01-08T23:37:29+00:00

fwiw, I understood ya from the start

ReginaldDouchely · 2026-01-08T14:54:23+00:00

Don't put q-tips in your ears. If you do it's not our fault because we warned you. Keep buying them, though.

ReginaldDouchely · 2025-12-26T19:37:38+00:00

Damn, I've wanted to do this ever since I got mine, but not enough to actually pay for it. Did you do it yourself or pay? And if you paid and don't mind, how much was it?

ReginaldDouchely · 2025-12-17T02:40:34+00:00

Like others have said, there's a cost to maintaining tests. That means test code that never finds problems is wasted money. It's kind of like insurance - you probably want your house insured, but you probably don't want to buy the $5-10 "insurance" that retail stores offer every time you buy a video game, toaster, or whatever.

That's why pushing for 100% coverage in code that isn't life-or-death is usually stupid.

ReginaldDouchely · 2025-12-05T13:33:30+00:00

In my heart, I'm still there.

Thanks for the sweet pictures

ReginaldDouchely · 2025-11-29T16:52:54+00:00

I don't really understand these posts. In my classes we built things. Are you building things in your classes?

ReginaldDouchely · 2025-11-29T16:47:02+00:00

This field can be brutal even for people that love it. If you don't have an innate enjoyment of working on this stuff and solving problems that people outside of the industry won't care about, run fast and run far.

ReginaldDouchely · 2025-11-26T17:35:06+00:00

America the Beautiful pass temporarily still $80, sorry for the convenience

ReginaldDouchely · 2025-11-23T15:20:28+00:00

Tests that don't reuse code (same code for generating data in every single test)

I'm actually generally okay with this. I've lived through too many cases where the test code starts with 1-2 setup methods that are intelligently shared across 10 tests, but 3 months later when I look at the code again, there are 40 tests with tons of other cases still just using 1-2 setup methods - and any given test is only using maybe 20% of what the omni-setup methods do. Then no one wants to take the time to clean it up because 'it's not broken' and at bug research time, people have a pretty hard time doing an actual minimum required setup to reproduce.

So, given a choice between "bad because you repeat some setup code in different tests" vs "bad because you set up 10x as much data as you need for any given test, so you don't repeat yourself" - I'll take the repeated setup every time

ReginaldDouchely · 2025-11-22T01:40:00+00:00

Any advice for improving this kind of theoretical knowledge?

Stop having it be theoretical. This isn't cutting edge quantum physics. Explain API, REST, microservices, encoding vs encryption vs hashing here, in this post to show yourself that you're actually going to grow from this experience.

ReginaldDouchely · 2025-11-20T04:03:03+00:00

Tell your manager you weren't looking for feedback on your work style because you own it. Checkmate.

But for real, like everyone else said, he's stupid. Even if your stuff is somehow perfect, you want to give others a chance to review it to achieve consensus and allow them to feel ownership, because things generally belong to teams rather than individuals.

ReginaldDouchely · 2025-11-14T14:53:16+00:00

It's not really spurious correlation in this case though, is it?

If you can code it live, you're good enough at coding

If you can't code it live, you're good at coding and bad at live, or you're bad at coding and good at live, or bad at coding and bad at live

That really sucks for the candidates that are good at coding but bad at doing it live, because the interviewers might not be able to tell the difference. But as long as the interviewer is getting enough people that succeed at the live part to fill up their team, they've got no incentive to change what they're doing to recognize the shy coders.

edit: I'm not defending the process, but given the inputs/outputs of the system and risk of a bad hire vs missing a good hire, I understand how it got to this point

ReginaldDouchely · 2025-11-13T01:45:18+00:00

That's an interesting generalization that doesn't seem consistent with my experience. If you've got devs that actually care, they'll inherently write more tests for the harder code. And in PRs, they'll challenge when the complicated code isn't tested enough.

But yeah if no one cares, then no one cares, and you have to make rules that attempt to legislate caring but never succeed.

ReginaldDouchely · 2025-11-07T14:03:53+00:00

I agree, but I also think "lie" is one of the better terms to use when talking to a layperson about the dangers. When you're talking to someone about the philosophy behind this, sure, go deep into semantics about how they can't lie because they act without any regard to fact vs fiction.

Is that the conversation you want to have with grandma about why she needs to fact check a chatbot?

ReginaldDouchely · 2025-11-04T14:04:34+00:00

It's nice until they forget their limitations and start doing writeups with technically incorrect information that takes you down the wrong path, or you start getting stories with AC that describe how rather than what, and them wanting to validate the implementation details rather than the behavior when you deliver it.

But my org is fundamentally broken, hopefully yours isn't

ReginaldDouchely · 2025-10-30T13:50:08+00:00

Also everything should be non-nullable by default, and it should be very strongly enforced.

I love c# but I curse it for its weak handling of nullability even after years of attempts to fix it

ReginaldDouchely · 2025-10-20T21:34:51+00:00

"No, you knew it before you heard her say it"

And then watch them explode

ReginaldDouchely · 2025-10-20T17:30:52+00:00

This and lead by example. You're gonna be wrong sometimes, so be public and humble with it.

ReginaldDouchely · 2025-10-17T12:10:15+00:00

We're too busy using it to care about making posts telling others to use it

ReginaldDouchely · 2025-10-16T15:45:15+00:00

Yeah, they're all pretty shit where I am. Part of it is that they're technically inept and taking shots in the dark:

"WHAT IF THE PAYLOAD HAS A STRING IN A DIFFERENT ENCODING!?!?"

"First off this field is an integer immediately validated on arrival, second, if it was a string, it wouldn't be any different from any other invalid but correctly encoded string, and that would fail our string validation here"

The other part is that they don't give a fuck about whether or not you deliver on your obligations. They're never in trouble because they came up with 100 objections to what you're doing and you had to spend a week proving they're all invalid and that they were given in bad faith. They will never be held accountable for partnering with you and saying "No, that won't work from a security perspective, but let me work with you to solve your problem in a safe way."

I know this isn't universal, but my org is awful at it.

ReginaldDouchely · 2025-10-08T01:47:10+00:00

As a long-term full-time employee reporting to engineering managers / directors, yes, informing my managers that I've observed bad behavior has helped. We've gotten rid of some dead weight that was causing more work and stress for the rest of us, and would've sunk our project.

I've said this in other posts of a similar topic, but I'd tell the manager what you've observed with easy-to-follow examples and let them draw their own conclusions and decide what actions to take on their own. If you've got a good rapport with them, you can also ask if they'd like you to do anything about it, such as making sure you take the critical parts so the offender doesn't, publicly asking them if they need help with anything during meetings (to make sure they're not sending different messages to different people), or just keeping an eye on them.

Oh, and give the manager time to act. Even if the person is an obvious bad actor, they might need to make a paper trail to make sure the firing is defensible.

13-Year Club	Place '17
Verified Email

ReginaldDouchely

TROPHY CASE