| 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. |