Live data from Hacker News

Be Kind

briangilham.com

161–170 of 458 posts

Re: Be Kind

#161

Earlier quoted context omitted.

IMO, if you deploy on Friday, you are promising to be available for fixing it on Saturday... which makes it not really a Friday in the sense in which it's meant. Don't deploy when you won't be around to support it is a better description; but it doesn't roll off the tongue as easily.

So I should just leave a security vulnerability rather than fix it on a Friday, because I won't be available Saturday?

If it has the potential to take down your site? Unless you have someone who can fill in for you, absolutely.

Really, it will come down to a cost/benefit analysis. Are your chances of the site going down due to being hacked over the weekend higher than the chances of a last minute update taking down the site?

The answer is almost always no (much to a sysadmin's chagrin). If the answer is yes (i.e. another heartbleed), then you are probably going to be working through the weekend anyways.

Re: Be Kind

#162
post #24
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…

Stern really is the last resort mainly because the things that people really argue about are often just opinions. No one is going to argue that test1, test2, etc... are good test names. It is certainly better to let someone realize that on their own with a question than sternly tell them they are bad.

The very rare times when I have to be stern is with consistency issues. Usually though, that's even softened with a "Yes this might be a better way to do it, but it is not consistent with how it has been done so far. We'll make some time in the future to change it everywhere, but for now stay consistent." Often times the biggest issue with juniors or even mid level people is they are only looking at their immediate piece, and not thinking about the larger application or system level picture.

Re: Be Kind

#163
post #29

My first job was at an aerospace company in Florida. My boss was so nice. I was really surprised to get the coveted desk in the 60° server room. Coming in off those 90° 100% humidity streets to put on a parka and sit at my workstation wearing fingerless gloves. Man, anybody should be so lucky to apprentice with that guy.

Florida native here. You're not really doing yourself a favor by sitting in the A/C all day. You aren't allowing your body to accommodate to the heat.

Re: Be Kind

#164

Earlier quoted context omitted.

IMO, if you deploy on Friday, you are promising to be available for fixing it on Saturday... which makes it not really a Friday in the sense in which it's meant. Don't deploy when you won't be around to support it is a better description; but it doesn't roll off the tongue as easily.

So I should just leave a security vulnerability rather than fix it on a Friday, because I won't be available Saturday?

Read to comprehend, not to argue.

Re: Be Kind

#165
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…

Maybe tell a true story that helps your point, rather than a blatantly fictitious one.

I could tell a story about purple moon dragons, but it wouldn't "show" anything.

Re: Be Kind

#166

Earlier quoted context omitted.

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.

that's a twisted way to twist a story.

Aren't those the best?

Re: Be Kind

#167

Earlier quoted context omitted.

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.

What did you learn?

Re: Be Kind

#169

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.

Re: Be Kind

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

While I admire the sentiment, I've NEVER seen an asshole fired for belittling juniors/co-workers. Harsh, withering treatment is quite common not just with developers but in all technical fields. I wish things were different, but that's the reality as I've seen it.

At more than one place where I've worked with at least semi-functional management, people with attitudes like that tend to get moved to special "one person" teams and then are given a long stream of crap work (or at least work they feel is beneath them) until they get bored and quit.
Post reply on HN