Live data from Hacker News

Be Kind

briangilham.com

171–180 of 458 posts

Re: Be Kind

#171
post #147
post #4

I have the similar problem with code reviews. It is really hard to not sound harsh when giving a code review, especially in ones from junior developers where a whole laundry list of fixes comes out.

I work with a couple of particularly arrogant junior devs. In code reviews I will tell them things like "the way you're doing this works, but it's better practice to do ..." and they just shrug it off, saying they don't really want to change it, they just want their code merged. Drives me crazy. So junior devs, and really ALL devs, please be humble about your abilities or you will be terrible to work with.

It sounds like your org is lacking in some basic leadership. If issues are brought up in the code it either needs to be corrected or justified with the team.

Re: Be Kind

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

It depends on the project. Is it a web application for keeping track of daily tasks? You probably don't need that much rigor. Are you building something that if it fails will harm/kill/cost people a lot of money? More rigor is needed.

Re: Be Kind

#173
post #30

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…

Oh his behalf, I apologize. I literally started laughing at a junior's code once but in my defense, he had spent 3 years at Amazon.

That is completely unacceptable behavior. If you were in my company I would petition to have you fired. I hold a strict no asshole rule, life is too short to work with people who would do something like that.

Re: Be Kind

#174
post #69
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.

For some reason I am imagining you working in a server room shaped like an equilateral triangle (i.e. the walls of the room meet at a 60° angle)

And he came out of an aquarium (i.e. 90° walls + 100% humidity)

Re: Be Kind

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

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.

Re: Be Kind

#177

I run a number of side project sites and I do much of my work late at night. I have one simple rule for myself - which is to never deploy anything at night before I go to bed. I've made several critical mistakes which I deployed to production and then went to bed only to wake up and find out that users couldn't use my products. Thesedays, I do all deployment in the morning - that way, even if there is a critical bug,…

Definitely. I have a similar policy about deploying late in the day on a Friday. Rushing to get something deployed before an arbitrary deadline is generally a bad idea. By all means, push hard to finish the feature and qa it thoroughly, etc., by whatever cutoff, but wait to hit that launch button until the next morning. Saves so much stress.

Re: Be Kind

#178

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

I've always felt this attitude towards giving trust to the new hire is a good thing. It remembers me to something I read not so long ago where a Perl core contributor makes the same thing with collaborators.

What I don't find ok is to blame a person for an error going to production. Specially when the error is caused by the lack of supervision to the new hire code (code reviews) and probably QA.

Re: Be Kind

#179
post #93

Earlier quoted context omitted.

In which case angrily confronting that person would further justify their ill will towards you and strengthen their resolve to sabotage you. How is that productive or tactful?

And becoming passive implies the message that you're a pushover to whom anything can be done because there will never be nefarious consequences. To those people the mindset is: If I do X I might gain something (or feels good) and no mater what I'll never suffer any retaliation for it. Why shouldn't I do it?

I think perhaps your mindset, and possibly your situation, might be improved if you assumed less about other people's thought process and motivation, or at least if you didn't assume you were correct. It's very easy to come up with ideas about what someone is thinking and why, it's much, much harder to be correct about that.

By assuming you know why people are doing things, you've already biased yourself against future information that may contradict that. Maybe sometimes they aren't doing it to be a dick to you, and maybe sometimes what you view as gloating isn't directed at you, or isn't actually gloating.

Re: Be Kind

#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?
Post reply on HN