Hacker News new | ask | show | jobs
by plank_time 1863 days ago
One of my mentors at the first company I worked for in Silicon Valley never said “no” to one of my ideas. He said “okay, we’ll try it out and see what happens.” He was inherently supportive of new ideas and as a junior engineer it felt very refreshing to not have to argue my way into a feature that I felt strongly about. I’ve carried that same mentality throughout my career.

My worst colleagues were the exact opposite. They didn’t listen to anything that they were advised and then when the project failed they tried to pin the blame on me. Luckily the rest of the team vouched for me so nothing happened but it left a bad taste in my mouth. There really isn’t much to learn from scumbags since it’s obvious you shouldn’t be a scumbag.

3 comments

> One of my mentors at the first company I worked for in Silicon Valley never said “no” to one of my ideas. He said “okay, we’ll try it out and see what happens.” He was inherently supportive of new ideas and as a junior engineer it felt very refreshing to not have to argue my way into a feature that I felt strongly about. I’ve carried that same mentality throughout my career.

I try to always have this kind of mindset, but sometimes I just don't see how to do it. Imagine you are at the office, the break room's microwave just broke down and you are discussing with your colleagues what should you ask at management to replace it. Two units ? Since the company grew and one microwave for twenty people is not enough. One more powerful ? The old one took like ten minutes to heat even the smallest meal. And then a colleagues, very seriously, suggest that a big barbecue would be more efficient and can heat many meals at a time. If we take the physical constraints (buying a barbecue...) apart since in software we can easily let a bad project dies in the limb of our repository, how can you say "okay, we’ll try it out and see what happens" to them ?

You can at least entertain the idea, bad ideas spin themselves apart at the planning stage.

"I have a mobile smal bbq kit at home. I could bring that in for a try tomorrow. But were do we bbq. Fire detectors go off inside the building, so should be outside. Will bring it, but i wont grill out there in the rain, im for a rotating job on that. Volunteers?" There - death by self-execution. And you didnt even murder it by pulling hierarchy, which is always a good way to create a contribution dead company, were everyone just waits for the clock to go forward.

There is more to managing then making decisions (like in the movies). And in reality it should be more of a supportive role. And yes, sometimes you must entertain doomed ideas (like flying bicycles - those wright brothers, i kid you not).

> Will bring it

What if they say yes, and then you spend time bringing the bbq equipment to the workplace (although you didn't want to) and then your manager wonders "what are you doing, this'll set of the fire alarm", and you say "the others wanted to try this"

Provide the context - nicely, of course. If the manager is worth their salt they'll get it, all the way to the point that the BBQ is a team building exercise.

If said boss gets it immediately, I would like to know if he's hiring. ;P

Take 5 min to run it by your manager. "The microwave is broken so we want to being a portable grill to make lunch with Tomorrow."

If your manager has objections that's evidence it was a bad idea.

Maybe it becomes a company tradition instead to have a hill day instead though?

Thank you. I'll try to keep that in mind next time I'm in this kind of situation and see how it turns out.
There’s a difference between obviously absurd ideas and those that someone can go off and try in their own codebase. Giving some breathing room so people can experiment and try things on their own without disrupting the product is being supportive, in my opinion. It doesn’t mean everything should go in. But I give the person the opportunity to sell their idea. Maybe it’s better than I think, or maybe others on the team will support the idea. Unless you’re the only competent person on the team, if the team thinks its a good idea then why not? If you’re the only competent person on the team however, you should really leave the company.

It’s the same thing with code reviews. I make a distinction between issues of opinion vs issues of correctness. I will never let incorrect code get checked in, but if it’s a matter of opinion, then I’m more lenient to let things in.

> Unless you’re the only competent person on the team, if the team thinks its a good idea then why not? If you’re the only competent person on the team however, you should really leave the company.

Sometimes I ask myself this question and I basically can't answer because, well. What are the odds that I am ? And what are the odds that it's the opposite, their ideas are great and I am in the wrong doubting them ?

Actually the most common situation is that someone will come with a very bad idea, and when asked what they think about it, the other attendants will something like "yeah, maybe that could work". They don't approve nor reject the idea. And it looks like more passivity than anything, but if nobody says "nope, that's wrong" and I'm convinced it actually is, maybe I am the one in the wrong ?

I see exactly what you are saying about CR. And that's exactly my mindset. But sometimes people argue that it's a matter of opinion while to me it's a matter of correctness. In those cases I'm lost because on one hand I deeply know that they are wrong, but on the other hand I don't want to be the bad guy that always reject PR because I think my opinion is more important than their.

TL;DR : I don't know where to draw the line between people's limits and my own stupidity.

> Actually the most common situation is that someone will come with a very bad idea, and when asked what they think about it, the other attendants will something like "yeah, maybe that could work". They don't approve nor reject the idea. And it looks like more passivity than anything, but if nobody says "nope, that's wrong" and I'm convinced it actually is, maybe I am the one in the wrong ?

That’s called “The Abilene Paradox.”[0]

[0] https://en.m.wikipedia.org/wiki/Abilene_paradox

>It’s the same thing with code reviews. I make a distinction between issues of opinion vs issues of correctness.

Good way of putting it. Too often code reviews devolve into nit-picking and bickering.

I actually agree with this. Although I try to give the people I supervise as much freedom to come up with ideas and solutions as possible, there are some that almost always come up with outrageous ideas that will never work or they overestimate their own skills and over promise. I think that it is my responsibility to tell them that their ideas are not going to work and that's not a good idea to pursue them. It will only lead to disappointments and wasted time in the end.

That said, some of the people I manage are clearly better at dealing with the freedom to come up with solutions than others. I feel like it's often the same people over and over again that try to install barbecues everywhere. I tend to give some colleges more freedom than others, because I know from previous events (i.e. I have a bias towards them) that their ideas might not be so crazy as I think they are. But I tend to stop other colleges, that have tried to install barbecues in the office several times in the past, when they come up with ideas that I think are probably not going to work.

>One of my mentors at the first company I worked for in Silicon Valley never said “no” to one of my ideas

This is key to mentorship and building an actual team. Junior Engineers need help in building their Self-Confidence and grow into Leadership positions and this is the way to do it.

Note that asking you to come up with ideas and entertaining them does not automatically mean accepting it.

> There really isn’t much to learn from scumbags since it’s obvious you shouldn’t be a scumbag.

You can learn how to recognize them faster, or how to work with them despite their behavior, or practice standing up for yourself, etc.