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

181–190 of 458 posts

Re: Be Kind

#181

Post by overgard »

scraft wrote: post #109

Nice little read. There is that little answer in the back of my head of: "It is a good question why I caused this problem. It is weird to think there is a competent company that has been around for so many years, yet they have no procedures in place to stop this from happening. You would think that any changes that could cause downtime on a clients website would go through an automatic test suite and only after passi…

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 back in their face and go on a tirade against them. That's a very quick way to make sure nobody ever wants to work with you again.

Re: Be Kind

#182

Post by biesnecker »

vilius wrote: post #180

This advice is obvious. How can you not be kind with a junior person that makes a junior mistake? It's human. An angry phone call would not have made any difference (except damaging the relationship). But what if Brian deployed on Friday night without testing 4 times in two years? And 3 times it caused trouble for the business. How do you stay kind then?

You can be kind while still being critical. Even if it's kindly letting the person go with as soft of a landing as you can provide rather than the walk of shame to the lobby with security.

Re: Be Kind

#183

Post by Raphmedia »

sparrish wrote: post #35
phn wrote: post #22

Earlier quoted context omitted.

Well, he'd have to sooner or later. Better start learning as soon as possible :)

Nobody should be deploying to production on Friday... Nobody.

[Client, Friday 4PM]"Hello, client here. I know it's Friday 4pm but we messed up and did X. Could you deploy Y fix, thanks!"

[Client, Friday 4PM] "We are having a big sale this weekend we told nobody about. Could you quickly deploy a fix where all the product's prices are red and bold? That shouldn't take you long, right?"

[Project manager, Friday 4:45PM] "Hey team, X just released an important security fix for Y platform. I need you to deploy it right now or the client could get hacked."

Re: Be Kind

#184

Post by whamlastxmas »

tclancy wrote: post #65
onion2k wrote: post #56

Earlier quoted context omitted.

And that means the developers will all try to fix their own mistakes without bringing issues to the wider team, leading to a worse solution to problems in general. Premadonna "10X" developers might write great code themselves, but if they're pushing the quality of everyone else's code down then the overall effect of having them on the team is a negative. Anyone who treats someone else on the team in that way, regardl…

https://en.wikipedia.org/wiki/Prima_donna I will die on this hill.

Maybe he meant pre-1958 developers, in the same way we used to use "BC" as "Before Christ"

Re: Be Kind

#185

Post by samspot »

Shanea93 wrote: post #41
sparrish wrote: post #35

Earlier quoted context omitted.

Nobody should be deploying to production on Friday... Nobody.

My company just had to do it today in response to a critical security issue we identified in production. Saying that nobody should ever do it isn't realistic, sometimes things go wrong on a Friday, sometimes you can't afford to wait 3 days to watch them become even worse.

See if you like this version better:

"Only deploy on Friday if you like working weekends"

Re: Be Kind

#186

Post by CuriouslyC »

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

In my experience, while someone might be extra careful not to repeat a mistake that has burned them in the past, making a serious mistake is often a sign that someone is careless, and more likely to make other, different mistakes in the future.

Re: Be Kind

#187

Post by bambax »

> One Friday afternoon (...) [Kevin:] what did you learn? / [OP:] I talked about the need for proper QA. About thoroughly testing my changes. About taking the time to make sure the job gets done right.

Kevin sure sounds like a great guy. But there was a simpler lesson to be learned: never, ever push changes on a Friday.

Re: Be Kind

#188

Post by whamlastxmas »

kenrikm wrote: post #175
rimantas wrote: post #47

Earlier quoted context omitted.

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.

Laughing at someone's code is like laughing at someone's painting or their novel or really any other creative endeavor. It's not ok period.

If someone's work is poor enough that a reasonable person might laugh at it, then there's nothing wrong with that. Hence the phrase "laugh at our mistakes". It doesn't mean you are a bad coder/painter, it just means you made mistakes that were a little funny and can learn from them like anyone else.

Re: Be Kind

#189

Post by solatic »

scraft wrote: post #109

Nice little read. There is that little answer in the back of my head of: "It is a good question why I caused this problem. It is weird to think there is a competent company that has been around for so many years, yet they have no procedures in place to stop this from happening. You would think that any changes that could cause downtime on a clients website would go through an automatic test suite and only after passi…

I worked for a boss once who essentially engineered this kind of problem to exist: he knew not having automated testing etc. was a problem, and instead of asking his (too junior) programmers to build up a test suite, he decided to let them fail and discover for themselves why writing up test suites is a good idea.

His reasoning (later revealed) was that you can't give people fish and expect them to become expert fishermen. They have to experience hunger and ask to be taught to fish. If people don't have the soul-crushing experience that teaches them why something is really important, they never really internalize why it's important. That the reason why we appreciate that this stuff is so important is BECAUSE we suffered through something that taught us that it was important, and that if we don't give junior folks that same kind of experience, then good practice just becomes something on the list of priorities and not a moral imperative.

There's something to that, but at the same time, it's basically a defense of institutional hazing on the investor's dime. So take it for what it is.

Post reply on HN