Live data from Hacker News

Don't add your 2 cents

sivers.org

211–220 of 248 posts

Re: Don't add your 2 cents

#211

Earlier quoted context omitted.

Speaking as someone who has been "the technical guy" for 20-odd years, if the president of the company wants to pick nits like variable names and coding style, he's perfectly within his rights to do so. But he can do it without me.

I've worked for those "I'm the CEO, do it my way" guys. They hire you for your brain but end up only wanting to use your fingers.

There is probably a balance to be struck. Because I've also worked for milquetoasts whose teams walk all over them, doing whatever they want. The product suffers, the team suffers, and the company suffers.

Re: Don't add your 2 cents

#212
post #204

Earlier quoted context omitted.

I guess the key difference between my experience and this article, though, is that the article seems to be mostly focused in a non-technical boss commenting on benign/arbitrary opinions (like shades of color), rather than a technically skilled superior commenting on his area of expertise. The article is referring to things that are ostensibly subjective changes that don't make a tangible, measurable difference. The s…

The trick is to frame it as a question, so the original creator "solves" the problem on their own and thinks it's their idea. E.g. Instead of saying "make this blue darker", you ask "this might be hard to read on a lighter background. What can we do to fix that?"

Or even better: "I find this hard to read on a light background, what do you think?". By saying "what can we do to fix that?" implies you want it changed and are not giving the person a chance to explain their decision (if there was one). They could say "I thought the same, but then we tested it with 10 people and everyone found current version easiest to read".

Re: Don't add your 2 cents

#213
post #142

I can't agree with this article at all. From my experience on contributing to FOSS projects, I feel much better when somebody senior makes adjustments to my code rather than leaving it as-is. Not only does it tell me that they actually read my code and spot errors (the added bug safety net makes it much less stressful for me to write new code), but it also makes me feel like I'm learning something new that I wouldn't…

I generally agree with you. Part of this is just letting employees learn to adapt. At my first job out of college I was an assistant web dev to a talented senior guy in the marketing department. He learned that no matter what he did they were always going to have some small suggestion like the article points out, so he prepared for it.

He got everything setup how he wanted it and then added something that looked blatantly out of place, like a red border on one side of a div. Then they would say, "Looks great! If we can just lose that red line I think we're all set."

Worked every single time. He is somebody who's always been great at reading people and adapting to their behavior. If anything I'd say asking managers not to do the above costs people the opportunity to learn skills like this. It's a lesson that's served me well for my entire career.

Re: Don't add your 2 cents

#214
post #142

I can't agree with this article at all. From my experience on contributing to FOSS projects, I feel much better when somebody senior makes adjustments to my code rather than leaving it as-is. Not only does it tell me that they actually read my code and spot errors (the added bug safety net makes it much less stressful for me to write new code), but it also makes me feel like I'm learning something new that I wouldn't…

> From my experience on contributing to FOSS projects...

I agree with you in the open source situation that a more senior review adds valuable feedback.

Though I think that context is quite different from the employee-manager dynamic Derek describes in the article.

Re: Don't add your 2 cents

#215
post #142

I can't agree with this article at all. From my experience on contributing to FOSS projects, I feel much better when somebody senior makes adjustments to my code rather than leaving it as-is. Not only does it tell me that they actually read my code and spot errors (the added bug safety net makes it much less stressful for me to write new code), but it also makes me feel like I'm learning something new that I wouldn't…

I generally agree with you. Part of this is just letting employees learn to adapt. At my first job out of college I was an assistant web dev to a talented senior guy in the marketing department. He learned that no matter what he did they were always going to have some small suggestion like the article points out, so he prepared for it. He got everything setup how he wanted it and then added something that looked blat…

But that skill only exists because managers do stuff like this. If they didn't, then that skill wouldn't be needed.

Re: Don't add your 2 cents

#216
post #54

I think it's good to note, as Derek does, the distinction between "2 cents' worth" and larger changes that do require senior input - otherwise you're just being the manager that the team create ducks for [1]. This is where coaching skills as a manager can prove useful. If you feel there are some minor changes that could be an improvement, but don't want to impose your will/opinion, coaching ('ask') can be a better re…

The open question does not always work. I'd say it never works, even. If I take "coaching" attitude, I will take attitude of sports coach - observe, measure and explain why corrective action is needed. The action itself is a choice, mostly, but manager and coach should present a basis for it. Continuing my my rant, I emphasize that manager and coach are external to the team, they view performance from outside (and of…

> The open question does not always work. I'd say it never works, even.

IMO whether it works varies a lot by the employee's experience level. For a long time I tried to help junior engineers in the same way I would want to be helped (minimally, open ended, high focus on code quality), then got frustrated when the results weren't what I expected. Catering your message to the audience is one of the best pieces of management advice I've received. I'm not actually a manager, but as a senior dev, similar situations arise in code reviews.

Re: Don't add your 2 cents

#219

I find the advice highly condescending. > Because of that small change, that person no longer feels full ownership of their project. What kind of person is that who 1) thinks the ownership is 100% theirs when working in a team? 2) can't handle a little nitpicking? 3) feels it's less their work just because of a little change? 4) can't defend their work and resist those 2c? This is advice for managing 2 year olds. As…

>This is advice for managing 2 year olds. That's exactly the vibe I got from reading this article. I immediately thought of someone trying to manage super-fragile millennials who wilt and pout without constant encouragement and affirmation. If I submit I project for scrutiny, I want constructive criticism and advice. The goal should to make the project as good as it can be, not manage the feelings of emotionally chal…

But this article isn't about giving constructive criticism and advice. It's about those 2c opinions which are not constructive, but rather just subjective.

Re: Don't add your 2 cents

#220
I like to get feedback from as many people as possible, and take action on MOST of the [actionable] feedback. In my experience, this always leads to a better final product.
Post reply on HN