Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Be Kind

briangilham.com

Post reply on HN
Print view View original

121–130 of 458 posts

Re: Be Kind

#121

Post by new_hackers »

bjelkeman-again wrote: post #79
77pt77 wrote: post #71

Except in real life people sometimes make malicious "mistakes" deliberately and when caught and called out on them either completely dismiss them or even gloat. This reads almost like a fairy tale.

In my experience very few serious mistakes are deliberate and there is a huge gain to find a way to not make the same mistake again. Which include avoiding blame, but rather go looking for the root cause. People who can handle serious mistakes in others are some of the best partners you can have in your efforts. IMHO they aren't fairy tales.

Never attribute to malice that which can be adequately explained by stupidity.

Re: Be Kind

#122

Post by goshx »

rimantas wrote: post #47
hluska wrote: post #44

Earlier quoted context omitted.

I'm sorry, but you have no defense. Laughing at a junior developer'a code is completely inexcusable. Simple fact is, if you worked for me, I would have fired you for that. Junior devs are supposed to do bad things - that's why they aren't senior devs.

You are an asshole if all it takes to fire someone is some laugh. Everyone shoukd be able to laugh at everyone's code. It's just a code.

> It's just a code.

Well, no. It is the product of someone's work. Someone who is trying to learn and should be supported and taught how to make it better and why it is not as good as it should be.

Re: Be Kind

#123

Post by coldtea »

deadbunny wrote: post #103
coldtea wrote: post #95

Earlier quoted context omitted.

Friday is the best day to deploy to production. If something screws up, you still have the weekend to solve the issue before the big bosses are there. On weekdays you have the added pressure of other work. (Of course depends if your business is mostly or evenly loaded on weekends as on weekdays. In most businesses I've know it's usually the lower load/customer visits period).

No, the best time to deploy is when everyone you need to fix the issue is in the (metaphorical) building already. You should not be pulling people in from their time off to fix shit.

And if they've done their job correctly, you wouldn't have to -- even if you deploy on Friday.

Re: Be Kind

#124

Post by coldtea »

spenczar5 wrote: post #99
coldtea wrote: post #91

> 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. ...he said, before his final fatal flight. Apparently some people DO do the same mistake twice. ([Edit] to avoid confusion: My addition is about giving a different twist to the story, to show that it's not a given that people who made a mistake will not be prone to repeat it. Some peop…

Just to avert anyone else's confusion: Bob Hoover didn't die. Not sure what coldtea is referring to.

I was giving a different twist to the story to point that things can (and do) go differently to the rosy picture painted in it ("oh, you did a mistake once == you'll never make it again").

That's why in the except I kept, I didn't keep any reference to Bob Hoover. It's about the idea in the story, not some particular pilot.

Re: Be Kind

#125

Post by new_hackers »

_joel wrote: post #48

One way to avoid Friday deployment issues is to go to the pub. Obviously you need to spend all afternoon there and not be tempted to go back and deploy, otherwise issues may be compounded! It seems to be a common mitigation technique in some shops I've worked at ;)

I like the way you drink ... wooops I mean 'think', I like the way you think.

Re: Be Kind

#126

Post by ryanmarsh »

justifier wrote: post #87
endymi0n wrote: post #25

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.”

this is a great anectdote, but the reason i am replying to your comment is because of your user name i am a huge fan of the turn of the century dancer isadora duncan and her lover who she first had a child with, the theatre set design theorist, edward gordon craig who she affectionately called endymion a complete aside, but if you have, or anyone reading this has, yet to read duncan's autobiography 'my life' i highly…

Seems like something my wife would like to read. Just bought her a copy. Thanks for the tip.

Re: Be Kind

#127

Post by rpazyaquian »

crush_xc wrote: post #17

This was literally the biggest issue for when I started at my first job. We had a team member who was terribly condescending and talked down to everyone but especially me. You could tell that he hated the fact that he was on a team with a junior developer and took every chance he had to made sure I knew I wasn't as good as him. It makes a terrifying environment to ask questions because who knows what kind of response…

I had a similar experience at my first job. I was given a lot of access to important, core functionality like server configurations (e.g. using staging vs. production API servers and DB config), but mistakes weren't well tolerated. I've always been rather frustrated that I was given this unsupervised leeway yet judged when something inevitably went wrong - what did you expect would happen with a junior developer given master keys to all of your stuff? I still don't understand the thinking behind it.

Re: Be Kind

#128

Post by phkahler »

gwbas1c wrote: post #24
matwood wrote: post #12

Earlier quoted context omitted.

Best way not to sound harsh is to ask questions. "What are your thoughts on ...?", "Is this really what you meant to do?", "Do you think there is a better way to handle...?". It puts the power and learning opportunity back to the other person and lets them feel the accomplishment of improving. To the junior devs, when you screw up (and you will) own it and learn from it. Like public scandals, the cover up is almost a…

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…

Never say "do it this way". Try to explain why "this way" is better so they learn. If you don't they'll just think you're saying "my way is better" and resent you for it.

Re: Be Kind

#129

Post by arjie »

mattmanser wrote: post #85
phn wrote: post #42

Earlier quoted context omitted.

Easier said than done. It's best avoided, of course. But when on a startup you generally cannot afford to be an idealist.

Because missing three days of velocity will definitely cause your growth hacking to fall off the hockey stick and reduce the tempo of your disruption of unique hackathons for people with a left little toe deficiency?

Surely you can envision some scenario where it makes sense?

* It's the holiday weekend and your new website with its curated comparison feature needs to go live

* It's the end of the quarter and having this is the only way you can sign a deal now (enough of your partners will be bound to quarters that this is possible)

* You're in the business of live sentiment analysis from TV video and a critical bug needs to be fixed before this weekend's Presidential Debate or your news channel partner will be pissed

Reduce the tempo? Some of these can kill.

Re: Be Kind

#130

Post by masklinn »

77pt77 wrote: post #88
masklinn wrote: post #84

Earlier quoted context omitted.

> Except in real life people sometimes A minority of people are toxic, you start by cutting them slack as you'd do anyone else, then you cut them off. It's not really a problem.

Except those people are disproportionately represented in positions of authority and you really can't cut them off without effectively becoming a pariah.

That seems to be a scenario more or less completely unrelated to TFA or the discussion.
Post reply on HN