Live data from Hacker News

Be Kind

briangilham.com

301–310 of 458 posts

Re: Be Kind

#301
post #24

Earlier quoted context omitted.

I find that tone works when the developer has clearly thought things through. Other times, though, some developers need a very stern review. Things like: "Don't name your tests test1, test2, test3. Give them descriptive names," "Follow style," and "this does not belong in the dependency injector," and "don't screw with event publishing logic, filter this out in the event handler in the UI" are warranted when a develo…

Does being stern actually produce better results?

Yes, much better. It establishes that we are a "clean code" shop, and that sloppiness isn't tolerated.

This is important when dealing with junior contractors.

Re: Be Kind

#302
post #70

The reverse takeaway is perhaps even more valuable. Most are not going to be as angry as you expect them to be. When you mess up don't hesitate to tell people, it's going to be okay.

This is pretty much rule #1 for my team. If you make a mistake, I'm not going to yell at you, but

1) If you try to hide the mistake I'll be mad. As soon as you know there's a problem, we can mitigate the damage by addressing it immediately.

2) I want to see that you're learning from it. A pattern of repeated mistakes may take some explaining.

Re: Be Kind

#303
The virtues of being nice are often extolled, but it's kindness that's truly valuable. You can do nothing and be "nice", but only actions can make you kind. When you strive to be kind, you'll also start noticing who around also tries to be kind and who is merely nice.

Re: Be Kind

#304

When he returned to the air field, Bob Hoover walked over to the man who had nearly caused his death and, according to the California Fullerton News-Tribune, said: “There isn’t a man alive who hasn’t made a mistake. But I’m positive you’ll never make this mistake again. That’s why I want to make sure that you’re the only one to refuel my plane tomorrow. I won’t let anyone else on the field touch it.”

There are two schools of thought, especially in stock trading. 1) Reversion to the mean. This is what the above person believes and that this likely won't happen again. 2) Indication of a trend. The pilot is actually incompetent, and this will happen more frequently with this pilot than an average pilot.

3) Experience is a series of non-fatal mistakes.

Not everything is a financial metaphor.

Re: Be Kind

#305
The best teams and organizations are the ones that are constantly learning, and foster an environment that encourages and supports that.

And, can take those lessons learned, and establish practices to help prevent and minimize such mistakes in the future.

I've seen lots of teams totally embrace the first, but inexplicably, don't follow through with the second step. They go through the motions of "learning" without actually learning.

Re: Be Kind

#306
post #234
post #205

Earlier quoted context omitted.

I know you're probably not implying regression to the mean is causational, but that was my initial reading so I want to clarify for those who may not be familiar with the concept. Regression to the mean is simply that any given datapoint is most likely to be the mean, or close to it. This means that any exceptional data point,up or down, can be expected to be followed up by the mean. The example of this being misinte…

The pilot performance example is in Thinking Fast and Slow, I think.

Ah, yeah. I think that's actually where I saw it. Thanks.

Re: Be Kind

#308
post #253

Earlier quoted context omitted.

Think of what you're saying on a meta-level here. You would basically be telling this guy, "I fucked up, but I'm blaming you for treating me like an adult instead of a child. You screwed up by giving me enough autonomy that I could make a mistake." That might not exactly be a smart career move.. On a more personal level, if someone shows you kindness in the face of a mistake, the last thing you want to do is throw it…

I disagree. If you have something that is of significant value to the company, you need to hedge your risk. Automation is a particular hedge. People fail, and while processes do too, they often fail less. Would you be comfortable moving something fragile by hand that is worth a lot of money? Maybe. Would you prefer if the fragile item being moved was done with an automated process that was shown to best protect fragi…

Well, "process" and bureaucracy tend to march hand in hand. I think it's easy to get carried away with creating "processes" (i.e., additional bureaucracy) when sometimes people just need to show good judgement. Pushing code right before you leave for the weekend is just bad judgement, and the guy learned his lesson. Heavily bureaucratic institutions laden with processes are not exactly known for their efficiency or pleasant work force.

Re: Be Kind

#309
post #78

This was so nice to read. I think back to my very first coding internship after my freshman year of college when I messed up big time. I made a bad mistake that ended up forcing my supervisor to put down everything he was working on for a full afternoon and do an emergency fix. I so vividly remember sitting down in his office, trying to just calm down and keep it together. He never got upset or annoyed (at least he n…

Mistakes happen. I can deal with that. People lying about their progress however, that is hard to deal with.

Having been in this situation and been supervisor to people in this situation, it's possible to not be lying but also to not have complete understood the task or have it mis-spec'd.

Having someone rip into for lying when the spec was terrible to begin with is massively discouraging and the OP lesson applies just the same there.

Re: Be Kind

#310

Earlier quoted context omitted.

Fireable offense? Software Development is a profession, it's not coding school. Junior Devs are expected to have have an education, written code before, and know the basics. If they write something so crazy that it induces a chuckle, it's probably pretty bad. By all means tell them how to fix it, but don't mask the fact that the job they are getting paid to do expects them to know how to do this. Maybe an analogy wou…

Yeah, there's an obvious lack of details in the story that should preclude judgement of the poster. I've seen people write things like: if (true == true) I won't be mean to you about it, but I can't promise I won't chuckle a little before explaining why that's unnecessary. If you've been working in a professional setting for 3 years and are writing code like that, then yeah, I might struggle to be empathetic.

> I've seen people write things like: if (true == true)

Which, if you make that an === in JavaScript, can actually make sense in some situations :)

Post reply on HN