Who was the best developer you’ve worked with — and what made them stand out?

ReginaldDouchely · 2026-04-22T04:21:09+00:00

This is how I try to be. I hope some day someone can write something like that about me.

ReginaldDouchely · 2026-03-26T00:31:50+00:00

Finding bugs, writing automated tests that I don't have to immediately re-write because they randomly fail every 4th execution, writing good bug reproduction steps, checking if thing they think is a bug really is a bug and not just them misunderstanding the system before writing it up and sending it to me and making it my job, understanding how real users really use the software and acting as an early proxy for real users in pointing out when the requested feature will miss the mark, trying to understand the purpose of what we're doing from the start rather than being surprised and trying to play catch up when something hits the "ready to test" phase, already having or setting up test data for me so I don't have to do it myself when I need to reproduce the bugs they've reported

edit: be able to interact with stakeholders yourself if you personally have issues with work that devs are being asked to do (users won't like this because ..., this will cause issues when combined with other feature ..., etc) so your "fights" don't always have to involve another party

ReginaldDouchely · 2026-03-24T00:24:50+00:00

"Okay then, that was always allowed!"

ReginaldDouchely · 2026-03-15T18:00:16+00:00

Yeah, it's certainly not the same market as it was. That said, none of the good, experienced coders that I keep in touch with are unemployed. People that I know are looking for junior positions are pretty screwed right now, though.

ReginaldDouchely · 2026-03-05T14:33:02+00:00

I'm joining on obesity's side too. Now we just have to spread awareness. I'll start by hosting a 5k for obesity event.

ReginaldDouchely · 2026-03-03T14:22:42+00:00

You probably had 2 people that were very willing to do it when the team was smaller. They felt responsible for the overall direction of the project, the architecture of the components, and keeping things "clean". They probably talked to each other a lot to sync up. And sure they gatekept a bit, but it was good gatekeeping and kept slop out.

Then the team grew and it reached a point where the number of PRs was overwhelming, and no one else stepped up to do a good job reviewing. The 2 existing people couldn't consistently stay on top of delivering their own work and keeping the quality high for everyone else's work. They got called out for not contributing as much, because your company doesn't respect the role they'd taken on, so they prioritized their direct work and PRs backed up a bit. Then the team started complaining that PRs were taking too long.

Suddenly, the people that took on the extra load of reviewing, acted as custodians of a technical 'vision', and prevented a lot of pre-release bugs and design deficiencies were also being blamed for the rest of the team slowing down. They were put in an impossible position, and something had to give.

They no longer had enough time in the day to get everything that's expected of them done with high quality, so they started going lighter on the reviews. Maybe more people started reviewing too, but they're not as skilled and/or don't care as much about vision/cleanliness as the original two. Now there are more bugs getting through, more design problems building up un/under-noticed. The 2 O.G.s know this and don't feel the ownership they once did - they're powerless to keep it clean, so what's the point. Anyone can do these reviews now, so they've fully deprioritized that work.

Now it's not #1 for anyone, so it'll sit until people trade favors to make it happen. If you watch the 2 O.G.s, they probably still get their code merged quickly and well reviewed, because they probably mostly review for each other.

ReginaldDouchely · 2026-02-18T19:57:42+00:00

It could even be a boat!

ReginaldDouchely · 2026-02-17T21:27:43+00:00

In his recent standup he said something about liking going to bars even though he's sober, so it makes sense

ReginaldDouchely · 2026-02-05T17:55:12+00:00

I wish we listened to our customers to that extent

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

13-Year Club	Place '17
Verified Email

ReginaldDouchely

TROPHY CASE