Live data from Hacker News

Be Kind

briangilham.com

321–330 of 458 posts

Re: Be Kind

#321
post #153
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…

There is a cost in not having certain procedures in place. On the other hand the red tape has a cost too. A single mistake shouldn't lead unconditionally to a mandatory multi-step process that involves multiple people and may take several months to finish. The examples of the "cover your ass" decision making overpowering the common sense engineering are abundant.

That's true, you can definitely over-correct. I guess if I was the supervisor in this case, I'd be doing some analysis with the developer after the fact. Were procedures correctly followed? If not, use this event as an example of why the procedures are in place. If they were followed, was it a brain-dead simple error? If so, then obviously there is something wrong with our test plans. If it was one of those errors that turned out to be a perfect storm of environment differences, unexpected inputs, code side-effects or what-have-you, then there probably is no quick solution and the imposition of some overbearing system to try to limit something that will probably not happen again would be overkill.

It's always best to do an after action analysis to see where things broke down, I think. Changing procedures or adding protections might be warranted, as long as it's not the "get my permission before ever putting a Y in that field again" kind of enhancement.

Re: Be Kind

#322
I was just thinking about this today. Why is it that software engineers have a supreme mind set...

    "Oh you don't know that?"
    "Oh you don't know about that tool?"
    "Oh you use PHP?"
We categorize our peers into two buckets. One with whom you respect, and unfortunately the other as newbies, rookies, not worthy of our time and energy.

Listen, I am completely guilty of this behavior myself. Howerver, after reflecting I am going to try to be more helpful to peers. Remember that we are all constantly learning, and the knowledge and experience that you have took you time. That newbie was once you.

Finally, let's think about this in terms of rapport. If your dismissive and arrogant toward a peer when they ask a question, they are probably going to think you're a total tool and jerk. Howerver, instead if you have the knowledge and experience and show and teach them, they are going to admire and respect you. It is really the best option.

Re: Be Kind

#323

Earlier quoted context omitted.

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 :)

Can you give an example? I can't think of any situation to literally write if (true === true) rather than just if (true). (If anything.)

Re: Be Kind

#324

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

It's probably not unrelated that American air travel is very safe because there's a no-blame, learn-from-the-issue attitude to problems.

More generally it is very difficult to build highly reliable systems of any kind without having a very open culture where you focus on exposing problems and fixing them rather than blaming the message.

Re: Be Kind

#325

As software engineers: As beginners, we're over-confident in our ability, even if we actually suck and make lots of mistakes: https://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect The opposite seems to become true - experienced engineers (who have learned from their mistakes) seem to be extra paranoid. I've seen also older engineers that seem to be confident still, talk a bit game, but they just never learned.…

Yes, and that makes "being kind" a lot harder.

Many people reading the article think of a nice person that humbly tries their best but makes a bad mistake. But what if they're a hugely over-confident asshole?

I mean, not everyone likes everyone, so when someone you don't like to begin with is arrogant, you might easily label them as an asshole.

I think the deeper lesson of the article is not to consider other people assholes, and to be kind to them even if you don't like them at all.

Re: Be Kind

#326
I have witnessed the same thing at my current startup and this is the reason why I excel at my job and why my coworkers are some of my dearest friends. It is this sense of camaraderie that brings people together. We've all been through a lot, late nights of frantically pulling together an entire feature, reading scores of hibernate exceptions, debugging through IE bugs and jumping to help another developer with no questions asked. It is this through this journey that I learned how to provide safety nets for my junior developers and find ways to lead them to success just like my predecessors have done for me.

This is why I love being a developer.

Re: Be Kind

#327
I thought this article was fantastic. We could use more kindness at home, at work, and in general.

I find it really unfortunate when an engineer is fired because of a mistake. All the company is really doing is giving a more experienced engineer to someone else.

Re: Be Kind

#328
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 can confirm it is an approach taken by different companies out there.

I used to work for this company where every single Friday we would go out for lunch and get tipsy (wine with the food, some digestive liquor shots just at the end, then maybe a mixed drink or a beer at another bar) because we were the only team not allowed to go home early on Friday... for no reason. Mind you, we were some kind of internal IT team and there would be no one to request anything from us, so we never had urgent stuff to do.

Back in the office we would enable the "fire extinguisher mode" which meant "only move if there's a fire" and watch silly videos in Youtube, have some coffee with Baileys because why not...

Re: Be Kind

#329
post #325

As software engineers: As beginners, we're over-confident in our ability, even if we actually suck and make lots of mistakes: https://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect The opposite seems to become true - experienced engineers (who have learned from their mistakes) seem to be extra paranoid. I've seen also older engineers that seem to be confident still, talk a bit game, but they just never learned.…

Yes, and that makes "being kind" a lot harder. Many people reading the article think of a nice person that humbly tries their best but makes a bad mistake. But what if they're a hugely over-confident asshole? I mean, not everyone likes everyone, so when someone you don't like to begin with is arrogant, you might easily label them as an asshole. I think the deeper lesson of the article is not to consider other people…

>But what if they're a hugely over-confident asshole?

Then they have absolutely no business working on a team effort.

They never should have been hired in the first place.

Re: Be Kind

#330
post #280

Earlier quoted context omitted.

I was not familiar with this story; that prompted me to research it. I found it interesting that this aviation incident had a positive outcome, in the form of safety innovations: the Hoover Nozzle and the Hoover Ring. Wikipedia states: "A perhaps-undesired recognition is the Hoover Nozzle used on jet fuel pumps. The Hoover Nozzle is designed with a flattened bell shape. The Hoover Nozzle cannot be inserted in the fil…

In general, this design principle is known as poka yoke: https://en.wikipedia.org/wiki/Poka-yoke

This is a great design concept to know the name of! Thanks!
Post reply on HN