Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

In my experience, which, granted is limited (3.5 years programming), one or two team members I work with very rarely share their insights.

In the case of these team members I think one comes down to fear of maybe looking daft in front of the rest of the team by saying something that they think might be wrong. The other can just be a sanctimonious prick and will ask people questions that they simply wont know the answer to, to show them up in front of the rest of the office.

So in my experience fear is certainly a factor holding a person back. However on the flip side a person lording his knowledge over other people but not sharing it in a useful way conducive to improving the general programming knowledge of the team.

They both harm the team but in different ways. I don't know how these two problems can be solved though. Maybe encouraging opinion from the people who fear sharing their points of view and being supportive of them would help.

I'm at a loss though with regards to the power-bitches that like to make people look small with their own knowledge.



As a sanctimonious prick who asks a lot of leading questions, I find it's very difficult to communicate technical insights with other members of my team by just giving them the answers to the hard questions.

What I'm guessing you'd like sanctimonious pricks like me to say:

"That particular (algorithm|technology decision|doohickey) is bad for the following three reasons, this alternative is better because it's !(those three reasons), is less work, easier to maintain and also offers us the following three affordances. I've used this in a number of other installations and can vouch for its reliability and ease-of-use."

This categorically does not work! Don't do it! It allows for zero shared credit, puts everyone on the defensive and leads to bickering and bike-shedding. In the best case, the person you're arguing with will disagree vehemently, go away for a few weeks, then come up with a new idea all by themselves that is exactly the same as what you were arguing for. This achieves the same result but isn't a very pleasant way to get there. Questions work marginally better.

In general my lines of questioning follow one of the following formats:

1. Is there a reason we're not using <a := some no-brainer technology choice> instead of going to all the effort of rolling our own <a>?

2. Have you thought about how that's going to work when <one or more use cases that are almost definitely going to happen that you clearly haven't thought about>?

3. Is <b> something we're just doing now to get it working and then planning on refactoring later? <where b := a horrible mess they just merged into master>

4. It looks like the script is running when I enter <script>alert('bazinga!');</script> as my username. Seeing as it's your commit that caused it would you mind taking a look at that?

In terms of sharing insight without offending people, that's about as polite as I can get I'm afraid.


Your questions 1 to 4 look pretty normal and I would ask those as well. The parent poster is mostly talking about people asking questions just to make themselves look better.


It can be a matter of interpretation. Suppose two "highly competent" programmers A1 and A2 and two "moderately competent" programmers B1 and B2 are together.

If A1 asks those questions to B1, I suspect that A2 would view them as perfectly normal, appropriate and helpful, while B2 might view them as aggressive or "trying to show A1's superiority".


Perhaps, depending on B2's self-confidence. There's still that category of people that ask questions for other reasons than being interested in the answers to those questions.


"That particular (algorithm|technology decision|doohickey) is bad for the following three reasons, this alternative is better because it's !(those three reasons), is less work, easier to maintain and also offers us the following three affordances. I've used this in a number of other installations and can vouch for its reliability and ease-of-use.

This categorically does not work"

meh, if that gets the job done faster then say it. The chance of a 20 minute argument vs a weeks long delay? I'll take the 20 minute argument.

But then again, leading questions get my back up. I'm a "say what you mean, don't hint at it" type.

If I get offended because someone else knows better and tells me so without being rude, then it's my problem (and my insecurity), not theirs.


> meh, if that gets the job done faster then say it. The chance of a 20 minute argument vs a weeks long delay? I'll take the 20 minute argument.

I think it's possible that you misread my comment. In this scenario you get the 20 minute argument plus the week long delay, at least in my experience.


Leading questions are good, I don't advocate people just telling the answer directly and I follow your approach in terms of leading questions. From the examples you give I would suggest you aren't the kind of sanctimonious pick that I was trying to describe.

The example I was giving and probably not stating clearly enough, was of a member, who on a number of occasions has approached other team members and asked questions out of context like an on the spot quiz.

As an aside to my first post it's also interesting to see the people that will openly admit whether they have messed up.

Anecdotally it is usually the people who are less willing to share their knowledge that will try and shift the blame.

BTW, I am revoking your sanctimonious prick status....




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: