4 ms·

I'd add that from an engineering perspective, 'brilliant' jerks aren't even that brilliant. An actually intelligent person is happy to prove his thinking via t

by vemv 9y ago

I'd add that from an engineering perspective, 'brilliant' jerks aren't even that brilliant. 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. Anything other than that approach is noise.

arcanus 9y ago
> Anything other than that approach is noise. Agree with everything except: 'Anything other than that approach is noise.' It is signal that the individual is not capable, and dangerous to work with.
- vemv 9y ago
  A noisy signal :) I meant noise from as in 'low information, high annoyance'
mighty_bander 9y ago
While I agree that it's better not to be rude to people, I think it's common for intelligent people to become impatient when forced to share their understanding in what is to them excruciating detail. It is correct to overcome this frustration, but it's also important to acknowledge its existence and accept it as understandable, if only in order to overcome it.
tbrownaw 9y ago
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.
- vemv 9y ago
  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?
  - AstralStorm 9y ago
    Obviously the richer or more powerful, or more credentialed one, right? (Status quo) /s
lazyasciiart 9y ago
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?
- vemv 9y ago
  I think you should reword your question as it's not a realistic scenario. Engineers freely choose to learn Java and apply to Java job postings, and if that's not the case I doubt they'd be vocal against the "value" of Java.
  - lazyasciiart 9y ago
    You seem like you're imagining a very ideal world. I personally know many engineers who joined a company for one reason, then the team/company began a new project and migrated to Java. I have seen people argue about the choice of underlying technology in code reviews. And if you think my specific scenario was unrealistic, then perhaps attempt to understand it as a general example of "something that is obvious to you and which you think you have explained adequately in the past and should not need to explain again and again". If you still can't understand it, then I think you may simply have never worked with anyone who was at a significantly lower level of knowledge/comprehension than yourself, and perhaps you just aren't capable of understanding the situation without having been in it.
    - vemv 9y ago
      I see your point. Still that's quite an extreme case. Devs regularly questioning a programming language is not a code-review problem, or a should-I-be-a-jerk problem. It's more like the problem that you escalate to the CTO (with argumentation!). Or you can pick your battles and move to a saner company.
- UncleMeat 9y ago
  The key is to provide clear and actionable feedback. If people fail to act on that feedback and continue to hold the team back, you should escalate the problem. "Don't be a jerk" does not mean "be a doormat". It means that when your provide and receive feedback you do it in a careful and effective manner.

by vemv 9y ago

arcanus 9y ago

> Anything other than that approach is noise. Agree with everything except: 'Anything other than that approach is noise.' It is signal that the individual is not capable, and dangerous to work with.

vemv 9y ago
A noisy signal :) I meant noise from as in 'low information, high annoyance'

mighty_bander 9y ago

While I agree that it's better not to be rude to people, I think it's common for intelligent people to become impatient when forced to share their understanding in what is to them excruciating detail. It is correct to overcome this frustration, but it's also important to acknowledge its existence and accept it as understandable, if only in order to overcome it.

tbrownaw 9y ago

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.

vemv 9y ago
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?
- AstralStorm 9y ago
  Obviously the richer or more powerful, or more credentialed one, right? (Status quo) /s

lazyasciiart 9y ago

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?

vemv 9y ago
I think you should reword your question as it's not a realistic scenario. Engineers freely choose to learn Java and apply to Java job postings, and if that's not the case I doubt they'd be vocal against the "value" of Java.
- lazyasciiart 9y ago
  You seem like you're imagining a very ideal world. I personally know many engineers who joined a company for one reason, then the team/company began a new project and migrated to Java. I have seen people argue about the choice of underlying technology in code reviews. And if you think my specific scenario was unrealistic, then perhaps attempt to understand it as a general example of "something that is obvious to you and which you think you have explained adequately in the past and should not need to explain again and again". If you still can't understand it, then I think you may simply have never worked with anyone who was at a significantly lower level of knowledge/comprehension than yourself, and perhaps you just aren't capable of understanding the situation without having been in it.
  - vemv 9y ago
    I see your point. Still that's quite an extreme case. Devs regularly questioning a programming language is not a code-review problem, or a should-I-be-a-jerk problem. It's more like the problem that you escalate to the CTO (with argumentation!). Or you can pick your battles and move to a saner company.
UncleMeat 9y ago
The key is to provide clear and actionable feedback. If people fail to act on that feedback and continue to hold the team back, you should escalate the problem. "Don't be a jerk" does not mean "be a doormat". It means that when your provide and receive feedback you do it in a careful and effective manner.