Live data from Hacker News

Brilliant Jerks in Engineering

brendangregg.com

231–240 of 243 posts

Re: Brilliant Jerks in Engineering

#231
post #104

Earlier quoted context omitted.

An actually intelligent person is happy to prove his thinking via truthful argumentation (and unit tests, documentation, and so on), and also happy to get his points refuted by similarly reasonable peers. That has nothing to do with intelligence. It's a particular culture that is taught and learned.

Intelligence is (among other things) about reasoning - proving and disproving things. Also about communicating facts. How else could we exchange ideas? And in case of disagreement who would win?

Obviously the richer or more powerful, or more credentialed one, right? (Status quo)

/s

Re: Brilliant Jerks in Engineering

#233
post #53

I am an Alice and I need some feedback as why is it a bad thing! I work in an environment when very small percentage of people know what are they doing. and people that know what is going on do not speak up because they are frustrated and know probably nothing will change. in this environment I do speak up whenever I get a chance and I've been in arguments with managers 3 4 level above me. everybody else wants to be…

You know how people talk about "soft skills"? Bringing people around to your viewpoint without straight up arguing with them is indeed a soft skill. If you're a PERL hammer you're going to go after most every problem with a PERL script, right? What if the manager 4 levels above you is a Python guy? Is he right? Is he wrong? Or does he just feel differently? What if he's a functional programmer instead? What if he's a…

[deleted]

Re: Brilliant Jerks in Engineering

#234

Earlier quoted context omitted.

Here's the email. Jest may be hard to discern via text, but I if I had made that contribution (directly or indirectly) and was met by this response by the maintainer, I think it would be my last. https://lkml.org/lkml/2012/7/6/495 Actually, after reading it a few more times, I can't find any jest in it tbh

He’s essentially saying “this userland code is beyond stupid, but we don’t break userland so here’s how we can keep it working.” The comment is neither aimed at the contributor (who works on kernel code) nor the reporter (who did not write the code). In fact if you read the rest of the thread you can see them concur and joke about it.

What ramchip said. If Linus had said that to a specific person it's unreasonable. Kernel people can be pretty salty, this is a little more salty that normal but not that much.

He's legitimately saying "yeah, we have to support this but you'd have to be bat shit crazy to think this is a good idea". And he's correct, going into the kernel for one byte at a time I/O is stupid.

Re: Brilliant Jerks in Engineering

#235
post #12
post #3

Earlier quoted context omitted.

I'm still part Alice, I think. The Carnegie book really helped me, for sure. The difficulty though is that at some point if you believe something is important you may ultimately have to go through some kind of dialectic to make your case. How to Win Friends and Influence People says never have an argument. If you follow this advice you will reap the benefits of the book. However what you're building in your team will…

When you have multiple completely reasonable options picking either one is not a big deal. Sure, if A is vastly better than B, you can probably convince a team of that. However, when A and B are about as good then arguing about them is a waste of time. Learning how to separate those situations is important, but not usually a major issue when approached in that context. If all else fails just have a coin flip and say…

This comment is predicated on the idea that each problem can be solved/handled in isolation. Each isolated solution can be weighed against another and deemed better, vastly better, etc.

I think in many cases an optimal product can only be produced when there is a holistic vision that is kept in view. And in this paradigm, is is much more difficult to say A is vastly better than B.

Here's just one example--> many software systems that I come to have trended into maintenance nightmares. When you trace back all of the steps from inception to the present moment, you realize that it is due to a series of these kind of A/B decisions that boiled the frog. In each case A wasn't vastly better than B. But the sum of all the A decisions... And this is where it gets harder to make a case... where you may have to take a long walk to make the case...

Re: Brilliant Jerks in Engineering

#236

Earlier quoted context omitted.

Imagine that every time you implemented a new feature in your existing Java codebase, everyone asked you to explain Java. Would you be happy to prove the value of Java to your colleagues constantly? Would you start thinking that your peers maybe weren't similarly reasonable to you? At what point does explaining things become frustrating to you?

If you are that high above, then it is part of your responsibility to educate and help bring those people up with you.

At the cost of not doing your job and not getting promoted, right?

If you're paid to do another job, yet you are working as a mentor or teacher and expected to do it still...

Re: Brilliant Jerks in Engineering

#237
post #70
post #65

Earlier quoted context omitted.

I see your point and I agree with you, but it is so hard to put ideas in peoples head! and it is taking so much effort! you can't do that in a meeting when 10 other people are sitting! I guess there is no way to get around it and I should just give up !

Yeah, this works better in one on ones, but usually I don't think it is that hard, particularly if the other person respects your opinion. The trick is rather than shooting down ideas, present alternatives, and guide the other person through finding the flaws on their own.(Note: Doing this without sounding patronizing can be difficult)

One of the tricks that helps people who have difficulty with this is by using the Socratic method. Posing your objection as a question (and not a rhetorical question) imparts a respect for the intellect of the person you're trying to convince.

Instead of saying "bubble sort is too slow for us to use" (oppositional, "you are wrong for thinking otherwise"), try "wouldn't bubble sort be too slow for us to use?" (collaborative, "maybe you have something to add").

Re: Brilliant Jerks in Engineering

#238
post #53

I am an Alice and I need some feedback as why is it a bad thing! I work in an environment when very small percentage of people know what are they doing. and people that know what is going on do not speak up because they are frustrated and know probably nothing will change. in this environment I do speak up whenever I get a chance and I've been in arguments with managers 3 4 level above me. everybody else wants to be…

You are wrong because you are ineffective. You want a good thing: you want your environment to change for the better. But if you find yourself getting into arguments with managers, then you are probably not effectively changing minds, and you will get frustrated. You already sound frustrated. Speaking the truth straight out can feel good, but it is rarely a good rhetorical strategy. Instead, back up, and start with t…

> what do the people across the table want? What do they believe is good, and what do they believe is important?

See, this is why the public sector is usually so ineffective and why it's so frustrating. The people across the table tend to jump from posting to posting, and make safe moves that are far from being the correct ones to fulfill the organization's larger goals, while cultivating political capital. Ultimately, they are motivated by the prospect of future postings and promotions, which are determined not by their performance in achieving the organization's goals but by how much political capital they have succeeded in accumulating.

There is no way to sell reform to these people, because reform involves upsetting the status quo, and upsetting the status quo costs large amounts of political capital.

Successfully leading change from the bottom in the public sector is for that rare cadre of people who are not just visionaries and cheerleaders for change, but are patient enough to spend years and decades building upon small changes that build up while not losing their patience and escaping to the private sector.

Source: been there, done that, screw that, couldn't pay me enough to go back and do that again

Re: Brilliant Jerks in Engineering

#239

Earlier quoted context omitted.

It has nothing to do with puritanism. If project leaders don't set good examples, people "lower down" in the hierarchy will also act like jerks, and the project will lose potential contributors as a result.

> people "lower down" in the hierarchy will also act like jerk It's not clear to me he is a jerk. If LT only shouts when things are important, people without important tasks have no reason to shout.

Important to whom?

Re: Brilliant Jerks in Engineering

#240

Earlier quoted context omitted.

Agree totally. In an idealized "intellectual-only" world, humans would be Spock-like and be pure rational actors. But we aren't, not even close. (And I would argue that that's a good thing, but that discussion is waaaaay out of scope). As soon as you accept that humans, including yourself, primarily make _emotional_ decisions and not rational ones, it becomes easier to steer decisions in a healthy manner.

> In an idealized "intellectual-only" world, humans would be Spock-like and be pure rational actors. I used to think more along these lines. I heard someone recently talk about Spock and Captain Kirk and their approaches to different situations, and he said that most people think Spock must always be right due to his logical side. He then said that many times Kirk’s more human emotional approach actually worked out b…

Right. In my opinion it's even worse. The thing that piss me off about Spock is that ignoring the emotional component is a very illogic thing to do. :)
Post reply on HN