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

351–360 of 458 posts

Re: Be Kind

#351

Post by [deleted] »

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…

[deleted]

Re: Be Kind

#352

Post by kaikai »

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…

How about...

"Can you think of names for these tests that would be more helpful when we need to debug why they're failing?"

"Check out the styleguide for indentation like this; consistent code is easier to maintain"

"Here's a place where we did something similar. See how this logic goes over here instead? That helps us keep x, y, modular"

Phrasing things a little differently can make feedback feel like a learning opportunity instead of a criticism.

Re: Be Kind

#353

Post by Noseshine »

GigabyteCoin wrote: post #342

All this talk about being kind (or staying calm) in tense situations reminds me of this video I caught on reddit last year. [0] There is a dash-cam filming the inside cockpit of a plane when the pilot abruptly finds himself in one of those "death spirals" or "flat spins". The pilot doesn't say a word. He immediately reverts to his training, rights the plane, glides it towards the ground, and only grunts a bit when he…

  > "death spirals" or "flat spins".
Just an aside, for the record, obviously not important but since the topic came up...

A spiral and a spin are two very different things, and a spin and a flat spin again are very different.

In a spiral you actually still fly, in a spin you are not, you are in a continuous stall situation. That means from a spiral you can recover simply by "flying out of it", for a spin you have to do stuff you would not do when "flying", like full(!) and sudden rudder.

This heavily depends on the airplane, but a flat spin can be really dangerous, getting out of one often is much harder than from a "normal" spin. No problem in an aerobatic airplane, but in a jet it can be an unrecoverable situation.

Re: Be Kind

#354

Post by justin_oaks »

lotyrin wrote: post #319
justin_oaks wrote: post #158

Earlier quoted context omitted.

Of course. I guess I can give some examples. One developer writes huge methods or functions with a tangled mass of if-else. The inevitable result is that an else case missed and the whole thing fails spectacularly in some situations. Discussions with the developer are basically "That's how I've always done it and I don't want to change. I'll just add that missing else". Another developer constantly forgets to termina…

Teams are made of people, and people are made of animals stretched to purposes far beyond any resemblance to the environment they were designed for / by. Animals will have ingrained habits, many of these will be maladaptive. People though can create systems and systems can adapt for those habits. Do some cost/benefit analysis to enacting policies within the system that is your software development lifecycle. Assign p…

Well put. I prefer enforcing things by technical means when possible and via policy and process at other times. Sadly I see a lot of policy and process that isn't enforced, thus it might as well not be there. Nevertheless, I'll just attempt to improve that which is within my sphere of influence.

I suppose I'll just have to do my best to expect excellence and tolerate failure. I appreciate the insight.

Re: Be Kind

#355

Post by justin_oaks »

Bahamut wrote: post #196
justin_oaks wrote: post #116

Junior developers who make a mistake? Cut them some slack and teach them. Senior developers who make the same mistakes over and over and never learn? I've kindly pointed out the mistake and invited them to avoid it in future. After a few more failures, I sometimes talk to them sternly, but the sad thing is that they won't learn from either kindness or harshness. I'm not in a position to fire them. Does anyone have an…

Talk to your manager. That is their job to make sure they are doing what they're supposed to in a more formal setting if informal coaching does not work.

Yes, I suppose this is the "correct" way. If my manager doesn't have a problem with my coworkers failures, then I'll just have to tolerate it too.

Re: Be Kind

#356

Post by Spooky23 »

ninjakeyboard wrote: post #313

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

I think that I have become softer and harder. Harder in the sense that I have no tolerance for bullshit.

Softer in the sense that I want to foster an environment of respect. As a lot of the senior leadership that I've worked with has retired, I've noticed that the 30-40 year old crowd now is more brutal.

Re: Be Kind

#357

Post by paulddraper »

aturek wrote: post #338
GigabyteCoin wrote: post #329

Earlier quoted context omitted.

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

I don't agree. I've seen some very junior people change their attitudes rapidly (for the better) when working on a team; if we wrote them off immediately we'd lose out on a lot of promising people. I was also one of those developers and have since changed my ways :)

Yes, we might always change someone: a friend, a spouse, an employee.

But that's a risk; depending on that is ill-advised.

Re: Be Kind

#358

Post by yunruse »

GigabyteCoin wrote: post #342

All this talk about being kind (or staying calm) in tense situations reminds me of this video I caught on reddit last year. [0] There is a dash-cam filming the inside cockpit of a plane when the pilot abruptly finds himself in one of those "death spirals" or "flat spins". The pilot doesn't say a word. He immediately reverts to his training, rights the plane, glides it towards the ground, and only grunts a bit when he…

Approaching problems with a calm (and positive!) mental attitude is a tough life skill, even more so when it's become a life-or-death skill.

This is why I really dislike road rage - people take dangerous situations and make them worse, usually saved by instincts alone.

Re: Be Kind

#359

Post by narrator »

This is the Kaizen/Deming principle #8 of "Drive Out Fear". Here's a good in depth blog article about this as it's a difficult to explain topic that, especially for managers trained in the older methods of management, deserves a long form treatment:

http://michelbaudin.com/2012/10/27/deming_8_of_14_drive_out_...

Re: Be Kind

#360

Post by r_smart »

BinaryIdiot wrote: post #310
r_smart wrote: post #283

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

I've never waded into JavaScript, so I'll take your word for it. I've heard some...surprising...things about JavaScript, so I'm not really taken aback that this might exist.

I'm referencing a time when I was in school, and most everything was taught in Java, where that doesn't make sense. This was written by someone who was almost finished their degree and had already started at their professional job. Definitely junior, but I still feel like that's stretching the acceptable level of noobishness. That said, I have an EE degree, so maybe had to solve / reduce a lot more boolean algebra expressions than a straight CS major?

Post reply on HN