12 ms·

How to Pick Your Battles on a Software Team

190 points by philk10 10y ago

manacit 10y ago
I wanted to like this article, but I feel that it focuses too much on "winning" and "losing" - building software is (mostly) a creative task, and (I think that) treating it like a series of wins and losses can be a dangerous mentality to start off with. Finding a creative equilibrium between two ideas is the key to forming the right amount of "creative abrasion", but walking away from every discussion feeling like you won or lost is not going to get you there. If you're arguing about smaller or inconsequential things like tabs vs. spaces or other stylistic items, you need to spend some time and document guidelines, which should be enforced equally on everyone. This saves tons of time down the line, and eliminates a lot (but, of course, not all) of these problems.
- mknocker 10y ago
  I fully agree. When working on a team, you have to think about the future not only the current moment. If every time you have a disagreement it results in a win-lose situation I can guarantee you the mood among the your team will go down quite rapidly. I would suggest 'Getting to yes' by Bruce Patton, Roger Fisher, and William Ury on this matter of negotiation.
  - pjc50 10y ago
    But this is one of the things that the article sets out to define! That the work process should not be driven individual competitive arguing (which is pretty much the default mode of interaction for male technical staff), but people need to think about whether the arguments that they find themselves having are worth it for themselves and for the team. "Conversely, there are several different conditions that constitute “losing.” The team can lose if you make a teammate feel like their contributions aren’t valuable. The product itself can also lose by missing out on early critique of its features, or by missing an opportunity to have its features developed less expensively."
  - mk89 10y ago
    I don't know this book - thanks for the advice. I would recommend "How to win friends and influence people", which gives also good advice and a lot of hints.
    - mknocker 10y ago
      Yes. I read it. Good book indeed :)
    - AlexCoventry 10y ago
      Getting to Yes is a far, far better book than How to Win Friends, with a much more nuanced and broadly useful perspective.
- gjmulhol 10y ago
  I agree -- there was also a very "product v. engineering" vibe to it also. Maybe my company is different from most they see, but we don't have product doing code reviews for developers. The place tension can arise seems to be more around the fact that product always wants to move faster and engineering expresses that they can't always do that. I don't think either side is right all the time, but the way the article starts with "Winning battle = product giving into engineering", "losing battle = product being pushed into a better decision by engineering" screams to me of a lack of understanding that in a good organization each party has the best possible information for making decisions that represent the interests of the company from different perspectives, and these meetings are to figure out how those interests align or conflict and sort them out.
- Practicality 10y ago
  I generally agree, although she does try to redefine winning as a discussion that results in more of a win-win for everyone and losing as an area where someone "wins" the discussion but offends the other party, so it's not quite as contrarian as it seems. So, I think she means, a win for everyone, and she has the right approach. But I also agree with you, the terminology isn't quite accurate.
- bigpeopleareold 10y ago
  True, but some of this rang true since, in the past, there were certain people I felt like I was competing with. Over time, of course, that gets toxic and bad for business, something which needs a long-term solution.
- ams6110 10y ago
  Ideally things like tabs vs. spaces, indention levels or bracket styles, etc. are checked by a pre-commit hook so there's never a person being put in the position of choosing between looking like an asshole for picking on something "trivial" vs. upholding standards.
- mk89 10y ago
  Either I completely misunderstood the article, or ... I also had a similar feeling, and I think it's more productive to focus on results and goals, rather than "winning" or "losing". Nobody wants to be a loser. Further, I don't like the term battle, as it has a negative connotation, and this is exactly what you need to control or even to get rid of in a team: battle, win/lose, blood, emotions, arguments. In general I find the article pretty superficial and somewhat biased. In a real work environment you might have the best idea ever that might lead the product/company towards success, however, in front of you there is a senior dev/team lead to convince, and he is defensive and negative (and who knows, maybe he is having a bad moment in his life). How do you "win" this "battle"? By rationally "showing the numbers"? If we were all robots, this approach would possibly work, but in a team of 5 people there are 5 animals with 1) emotions, 2) personal problems, 3) different personalities, with ambitions, etc etc.
deleted 10y ago
[deleted]
kendallpark 10y ago
I agree with other commenters that this is simply too combative an approach. I've personally have had better luck with negotiation and redirection. I will say, I kinda burned out with product managers that don't understand technical requirements. Or product managers that lacked vision. I'm at a point where I'm pretty much done programmer other people's (uninspired) ideas (and am fortunate enough to be in a situation that allows me this freedom). There's a huge productivity difference when I'm working on a piece of software that I'm passionate about vs an app that consider misguided.
heartsucker 10y ago
I think this article misses the point that somethings are also completely right or completely wrong. For example, using string concatenation to build HTML and SQL. This is, just about always, a very bad idea. If a team is entrenched in doing this, it's not going to be a "winning battle" to undo it. You're going to anger the devs by changing all their code or making them use new libraries or whatever, but this is the way it needs to be done. I agree that approach matters, but let's not call it "battle skills," how about "not being a dick to your coworkers" and "interpersonal skills." If software development teams really are teams, take it from sports. Sometimes the captain needs to say "this is the playbook we're using, end of story" and everyone needs to trust that they're captain for a reason.
- sleepychu 10y ago
  "but this is the way it needs to be done." Actually, I'd disagree. It doesn't need to be done that way and this is a good example of a battle you're likely to lose that won't really cost you anything (other than some unpleasantness hand crafting SQL queries). I'd argue that even with significant opposition, any battle that needs to be won can. "I don't think we should store all the user passwords in plaintext on the server."
  - gwbas1c 10y ago
    In that situation, the correct thing to do is get 1-2 people fired, or go find another job. Life is too short to work with people that incompetent.
  - heartsucker 10y ago
    Please read about SQL injection[0]. Not using a library that escapes your strings is how Bobby Tables[1] ruins your production database. [0] - https://en.wikipedia.org/wiki/SQL_injection#Incorrectly_filtered_escape_characters https://en.wikipedia.org/wiki/SQL_injection#Incorrectly_filt... [1] - https://xkcd.com/327/ https://xkcd.com/327/
    - sleepychu 10y ago
haihaibye 10y ago
Interesting article, I like the focus on interdeveloper relationships. Software is a team sport, there should be more articles on this underserved area. We probably have more text dedicated to tabs vs spaces.
whack 10y ago
I agree with the author's advice, but a part of me can't help but feel that "picking your battles" is a sign of a poorly functional team. The entire premise behind "picking your battles" is that battles are expensive, and hence, you can't afford to fight every battle. But in a highly functioning team, bringing up suggestions and points for discussion shouldn't be expensive. It should be natural and fluid, with every person in the team expected to voice suggestions and concerns whenever they see them. In a team where people aren't constantly trying to jockey for position, where people are open to discussions without getting caught up in their egos, having people bring up suggestions freely is of great benefit to the team and the project. Maybe the real question that needs to be asked isn't how to "pick your battles", but rather, how to build an organization where people can contribute suggestions and concerns, without getting themselves dragged into a battle.
- nilved 10y ago
  > I agree with the author's advice, but a part of me can't help but feel that "picking your battles" is a sign of a poorly functional team. This is true, but practical. Most people will never work on a functional team.
  - jacquesm 10y ago
    Applying this advice could quickly turn a functional team into a non-functional one.
    - hitekker 10y ago
      Which advice are you referring to, the OP or the parent comment? Little confused.
      - jacquesm 10y ago
        OPs
    - weberc2 10y ago
      Really? It seems like picking your battles can only help make a non-functional team a little more functional.
jacquesm 10y ago
How about some good old consensus? Battles are not the way to go, regardless of the stakes. If you feel the direction a project is going in is not to your liking you can always quit. As soon as you start phrasing things in terms of battles, winning, losing and so on you're going to end up very frustrated and potentially toxic to the rest of the team. A good team member knows how to make their objections heard without engaging in confrontational tactics and will be able to present their reasoning in non-confrontational fact driven terms. And is able to accept that they do not always get what they want. If that happens too frequently then maybe ask to be transfered to another team or maybe leave for another company. But leave the war and associated terminology and attitude out of it. I've had someone in our little group at TT who would approach each and every little item like a battle and I was very glad when he moved on, it's fairly easy to destroy an otherwise winning team when someone starts to treat the process of software development as something that can be won or lost. There is work to be done, and if we do it well we all win, and if we mess up then we all lose.
- redether 10y ago
  > How about some good old consensus? My concern with consensus, is that most teams are comprised of a single or two senior people supported with a larger number of less senior people. If consensus is the protocol-de-jour, your service/product/offering suffers in the mid-to-long term (as well as alienation of the senior people whom you want driving).
  - jacquesm 10y ago
    > If consensus is the protocol-du-jour, your service/product/offering suffers in the mid-to-long term (as well as alienation of the senior people whom you want driving). I don't believe that is true. Junior people are only junior people if you treat them like that. If you are the lead dev and you work together with people junior to you (in experience, possibly not in years) then the fastest way to get them to grow is to get them on-board with the decisions taken as a team. "Pulling rank" is an option of last resort and it is actually a management failure, far better to spend the extra time to educate your team members to the point where they start making the right decisions. This may require introduction to some of the aspects driving commercial decisions but that's fine. That's an investment, and in a job market that is overheated you might be teaching someone enough to leave and to go work elsewhere but I've found that this strategy is more often than not rewarded with loyalty. At least half of these problems boil down to effective communications.
gwbas1c 10y ago
Honestly, if there are that many battles in a developer's day, it's a sign of mismanagement. Some bad company leaders think that the right thing to do is constantly have people negotiate over silly details.
- jacquesm 10y ago
  > Honestly, if there are that many battles in a developer's day, it's a sign of mismanagement. Or a bad hire.
  - dbcurtis 10y ago
    Maybe. The article outlines some behaviors that a good manager would immediately squash. Most people will conform themselves to the prevailing culture. When bad behavior is confronted honestly, squarely, and articulately by a manager, the offender usually conforms to the healthier cultural norms as articulated by the manager. Only if the bad behavior is confronted and still persists can you call it a truly bad hire. In which case it should be dealt with. No amount of productivity justifies being a jack-ass.
- arethuza 10y ago
  "He observed that a committee whose job was to approve the plans for a nuclear power plant spent the majority of its time on discussions about relatively minor but easy-to-grasp issues, such as what materials to use for the staff bike-shed, while neglecting the proposed design of the plant itself, which is far more important but also a far more difficult and complex task." https://en.wikipedia.org/wiki/Law_of_triviality https://en.wikipedia.org/wiki/Law_of_triviality
- shawn42 10y ago
  I think it's important to keep in mind that the OP is a consultant not a developer at a product company. I'm sure they end up working with external development teams that can't simply be dismissed (or fired), but must be worked with for the good of the customer. Simply saying "bad management" or "bad hire" takes too narrow a view on software development. The OP is a developer trying to get work done with the team, not a manager with authority over the others.
samlikescode 10y ago
I think this is a really great article. It's unfortunate that people see a word like "battle" and assume that it is meant aggressively. It is just a theme for highlighting the reality that developers and designers disagree all the time. When you work with intelligent individuals who are passionate about what they are doing, there are going to be strong opinions. These situations can get intense, and it is exceedingly difficult when the other party thinks less of your opinion - like because you're a girl. Solid article on a tough topic.
eloycoto 10y ago
I'm in the middle of this problem and not sure If I'm doing something wrong. In the next month we are going to launch a new product, I'm full stack dev and I'm bit frustrated with my colleagues. I did all the devops and all developers(5) has his vagrant per branch, each vagrant box is deployed in one box so they can show to another colleague without trouble (I built a server with the subdomain with the $TASK-ID.subdomain) and the workflow is correct for all of them and they are happy. To deploy to staging/prod we have a full terraform + consul so we're in a happy place. In terms of code this is painful, they didn't make any test, I made around 50 test 1 month ago to show to them how to make test, but in one month, only one test was added in the project. In terms of the code-review they complain about good indention, and each time that they made a Pull-Request (pep8 and pyflakes) is not passed, and they use to complain about it. They use to mark task as resolved before code got merged, things to weird that I can't explain. I tried to explain why things need to change, I made a workflow in plantuml and they are complaining that it's too difficult. I'm the only one that made commits in the docs folder. Nowadays I'm thinking to switch to another company, but I'm happy with my manager (He is too honest), but the team is killing me, and I don't feel comfortable with them, I rarely learn from them and they don't want to do things better, they only want to work to raise money. This is a dead battle? Or can I fix this?
- jacquesm 10y ago
  You can fix it but it will take time and you will need to be very patient. (1) let go of your frustration, it is not helping you, if you can't GOTO 3. (2) pick the best of your colleagues and try to lift him/her up to your level with arguments, not with force (this will take time and oceans of patience) (3) if that does not work, start looking for other employment, no matter how much you like your boss (4) if it does work, then now you have a buddy, who already knows your method works, rinse and repeat at (2) until you've either had enough of it or you find that you now have a well oiled team. Good luck! (You'll need it, this is not an easy thing to do). And if you manage to make this work you are management material yourself.
  - TheCowboy 10y ago
    I think it's not clear if he is the project manager or not. If he has a project manager, then we have to ask why he isn't helping focus the team. Or are they are product a team that is expected to organize themselves. I agree strongly with #1. #2 I think it might be good to approach it by asking more questions. If people say it is hard, ask how can we achieve the goal of writing more tests without it being a burden? Maybe OP is perceived as pushy if he's not the manager, or he doesn't allow for enough input on how the process evolves if he is the manager.
grandalf 10y ago
Most of the tensions described in the article are things that I believe can be modeled in terms of debts. It depends on which kinds of debt your team willingly takes on. Most teams take on at least one or two types routinely, no matter how religiously they avoid the others: Technical Debt: - build it fast by any means necessary - use whatever pre-packaged library exists, and duct tape it into your existing system. Analytics Debt: - build it without any prior UX experimentation on the design. - build it without any way to measure key interactions - have no data about the status quo before you build something new, this will insure that your new feature is a success because the before numbers are unknown. Marketing Debt: - build it without knowing whether users want it (or what they want) - build it without talking to users about their problems. Spec Debt: - build it without creating a detailed spec, leaving many important decisions up to the developer, who may not know the full reasoning for what she is building. - have a print designer do the UX, so that many subtle areas of interaction, animation, and behavior are unspecified. Mental Model Debt: - build it without having a hypothesis about why it is helpful and what might need to be changed next. This helps your engineers make choices that speed up this feature but add significant complexity for the next step. - do not worry about the statistical significance of numbers. Just focus on the direction the numbers are going and be sure your CEO knows how smart you are. Credibility Debt: - Don't acknowledge things that have gone wrong (with planning or execution) before. The pretense of infallibility is helpful to creating resentment and mistrust among different divisions of your team. Kool Aid Debt: - Whatever you do, be sure it is "agile" or "scrum" because then you have done everything right and you didn't need to worry about any of the above forms of debt.
poorman 10y ago
I wish I could tag people in hacker news articles.
makecheck 10y ago
Your experience/talent should dictate how much you press on an issue, and you should do it professionally regardless (e.g. no yelling, and listen to people; calmly state your point of view). Over the years I have encountered people arguing passionately about things that, as it turns out, they did not fully understand. It is fine to not understand things but if you’re new to a language/team, you should be saying things like “shouldn’t we do X?” or “I read on [site] that X is better”, and not act like you have found the One True Way to do everything. Ultimately, you need to communicate some experience/example showing why it is important to do X, or you must be in a position of authority where you can say that you choose X because there is no clear decision among the alternatives.
dbcurtis 10y ago
The article strikes me as immature responses to immature behavior from others. It's a How-To for creating a caustic environment. Try this: def leadership(): while true: have_clear_goals() articulate_goals_clearly() There is other stuff to good management, sure. But this will go a long way. The section on "when someone makes it personal" really irks me. It should never be personal in a healthy organization. You can vigorously debate the design, the implementation, or any other issue, while keeping the focus on the issue. It never needs to be personal. If it ever gets personal, a manager must step in and immediately squash that and make it clear "That's not how we debate things here. Personal attacks are unacceptable. Focus on the issues." But, really. Just have clear goals, then most decisions will make themselves. Debates can be settled by measuring alternatives against the goals. If, when measured against the goals, there is no clearly winning solution, then which one you pick probably doesn't matter, so everyone should stop wasting energy on decisions that don't matter and focus on the ones that do.
- ryanmarsh 10y ago
  This! I have observed at least 100 teams over the last 5 years. At any given time I'm coaching 4-10 teams. Every six months or so I get new teams. The number one problem I see is a lack of clear consistent communication of leadership's intent and values. Disclaimer: I might be hypersensitive to this because of my military experience. Complex adaptive systems of humans are always searching for systems with which to signal fitness and interpret fitness signals from others. If leadership does not pound these into the organization from their unique vantage point then the system will adopt its own in the vacuum. Rarely does such a scenario turn out optimal for all participants (for reasons beyond the scope of this comment).
  - dbcurtis 10y ago
    It is interesting that you mention military experience. The best manager I ever worked for had been an Israeli commando officer during the military service portion of his life. (If you remember the rescue at Entebbe, he was in the "Plan B" unit that was staged and ready to go in without the element of surprise should Plan A fail. Happily, Plan A worked.) So what made him a great manager? 1) You never had any doubt in your mind whatsoever what he wanted and when he wanted it. 2) He then asked you if you had everything you needed to get the job done. And then he listened to what you said until he was certain that he understood, and got you what you needed or adjusted the plan. When you think about it, failure to do those two things as a commando officer means having to write unpleasant letters to parents. I mentioned this to another friend, also ex-commando (Royal Navy Special Ops Diver "We taught the SEALs how to do it.") He told me he often spent days thinking about exactly the right words to articulate the goal to his unit.
arielweisberg 10y ago
People (and I include myself) are lazy and will present that laziness via technical arguments and pretending not to understand/remember what you are saying. It's the steady string of previously debunked straw-man arguments or orthogonal unrelated objections that is the tell tale signal. If you keep pushing you are just burning relationship currency. If you dig in for every single little thing your going to be the bad guy org wide because people don't have enough context in most development workflows and aren't going to put in the effort to understand the technical or timeline issues at stake. You will just be the one who makes a fuss all the time. I've watch some solid people get pushed out due to this. As long as the harm is minimal I'll point it out and let it slide if the objections go off the rails even if the cost to do it right/better is less than the value realized from doing it right/better. Discussion isn't free. When the cost of dragging the discussion out is commensurate to the harm or value realized then that is when I will tax both myself and others involved in the discussion to address it. This is one reason to have these discussions before code is written and people are invested in not having to make changes. If you are brutal and break things down into small chunks delivered regularly the latitude for things to go sideways is reduced and discussion is more productive.
- jacquesm 10y ago
  > Discussion isn't free. Exactly, that's the key insight to have. Making the discussions more important than the project is a pretty good way to derail anything, there has to be some sense of proportionality.
boundring 10y ago
There's nothing caustic about self-censoring when your view isn't worth the headaches it might give others. In terms of development, you have to respect the views of your teammates and the effect of your position on overall workflow. Edit: for clarity, there's basically one guy here who's made it some sort of vendetta to object to the entire concept of a "battle," as though using that word for a disagreement is the issue. There's no such thing as a "perfect" team, but it seems his idea of that involves consensus. Consensus is an abstract, reality is defined by multiple viewpoints.
- mixmastamyk 10y ago
  It may be a cultural thing.
phhlho 10y ago
The hardest battles I've had are dealing with legacy code. The majority of teams want to improve the overall code base and correct past mistakes, but you can never fix everything right now. Deciding when to let the nasty thing lie and when to pay the cost of fixing something is a tough decision to make. Fixing costs are large and immediate but the cost of leaving a problem area is spread unknown across the future. Couple that with fixes that don't actually provide system value except for standardization and you can have all sorts of fun arguments.
- dclowd9901 10y ago
  This is something you have to decide organizationally. For our part as a frontend team, we've decided when we implement a new feature, it won't be in our old framework. Ever. We've built a way to integrate React into our old world areas of our code. Furthermore, the portion of the old world code that this new React code interacts with will also be converted into React. This way, our code has a sort of 100%+1% movement toward the new framework. The point is, you need to figure this out as a group and then just implement it as a rule. It can't happen during the code review.
jcadam 10y ago
At my current job we have a prima-donna software engineer who wins 90%+ of all battles simply because he throws a giant tantrum whenever a disagreement comes up. People (including the boss) usually just give in to shut him up. It's to the point people won't critique his work because he gets defensive and throws a giant hissy-fit if you suggest his explosion-at-the-pattern-factory nightmare of a module isn't just the most awesome piece of code ever created.
alarge 10y ago
This may be redundant with what others have said at this point, but I think this article is wrong-headed: it perpetuates the idea that you will/should have winners and losers. The biggest barrier I've found to helping improve an idea is that input is perceived as an attack on the author. And, far too often, engineers will say something like "that approach isn't the right one, this one is", effectively substituting their own solution wholesale for the original. If a team is ever going to be greater than the sum of its members, it must produce output that is better than any single member could produce on their own. That only happens when you move away from "your approach/my approach" to something like "here's a specific concern I have with the existing approach - how would folks suggest we address it? (here's one possibility)"
- dbcurtis 10y ago
  I think the article is looking for winners and losers in the wrong place. There will inevitably be winning and losing companies. People that put more energy into making sure that they, personally, win over other people in the organization are not focused on making sure the company wins. Asking "How do I win?" is a very different question from asking "How do we make the company win?".
  - rhizome 10y ago
    The Iron Law of Institutions: http://rationalwiki.org/wiki/Iron_law_of_institutions http://rationalwiki.org/wiki/Iron_law_of_institutions
netcan 10y ago
I've been thinking about the word "ideology" lately. What does it mean? My grandfather was imprisoned by the Nazis and later fought for a Trotskist partisan militia. He hated "communists." According to him (as far as I understood), the defining feature of "communist" was fanaticism. The communists at that time, fighting Nazi & Fascist occupations or orchestrating revolutions under their ideological flag were ideological devotees. We remember Nazism and the madness that took a hold of Germany but I think we forget the context. Other ideologies of the period were less of an evil archetype, but not less devoted ideologically. Often they were just as bloody, if not in the same cold way. The communists that played the archetype role in my grandfather's experience (I assume his comrades, but IDK) must have been very fanatical. "A communist is someone who would sacrifice his mother for the cause" was how he'd describe it. This didn't (as far as I know) have much to do with what we might call "socialist" policy now. This wasn't an opinion about economics or social policy. Anyway... in a software context, the word ideology gets thrown around, often in a derogatory way. It's surprisingly hard to define it. I think a lot of the conflict points (losing battles) alluded to here are likely to have at least one person pissed off at the other's stupid ideology. "Agile" is the obvious one to bring up. This is mostly because it has a name, it's been successful enough to have beeen bastardized and tortured many times and it has a manifesto. But there are a lot of things like that. I haven't come up with a good definition, but I think a good chunk of it has to do with this: Ideology is contextual. When you're argueing for 'X' ideologically, you can't explain your reasons without going into a lot of abstract preamble. This is annoying to the people who disagree with the background reasoning and to those that have never looked into it. To them it sounds like you're saying "just because." Ideological bullshit. In a political context, one might be a libertarian. This has implications about the legal status of recreational ketamine, minimum wages, building codes, school funding and the approval process for new pharmaceuticals. It all ties in logically to the Libertarian perspective. But, if a libertarian is trying to be centrist, pragmatic, get elected or convince others to make laws then they have a choice. They can be "ideological" and talk about non-coercion or emergence or whatever forms the base of their ideological position. This then becomes about the ideology, not the specific thing. Or, they can talk about the specific thing, the law or policy. They can point to some study on minimum wages and unemployment or innovation and regulation in the pharmaceutical sector or whatever. This often feels contrived. That study isn't what convinced the idealist, the ideology convinced him. I don't know how this gets solved. I do think that it's important to keep a record though. what ideology do I subscribe to. Realize that when you disagree for ideological reasons, that you are entering tricky territory. As a side note, common ideologies are great for cooperation.
delecti 10y ago
Most of Amazon's corporate principles are a bunch of management buzz words, but situations to apply one of them pop up fairly often in design discussions. "Disagree and Commit" You're not always going to think that the design the team settled on is the perfect, but if you've laid all your evidence on the table and the team goes the other way, then you go the other way.
pascal1usa 10y ago
At our company code reviews are my way or the highway. Raising objections only gets you negative feedback. It's mostly for coding style, spaces, variable names.
RangerScience 10y ago
I have a question, that bothers me a lot: When someone says "there's a better way to do it", aren't they actually saying "[I think that] there's a better way to do it"? I think I understand that saying, simply, "I don't like the way this is done" isn't helpful, but I don't see how it's necessarily "personal", or rather, that any critique can be anything other than personal. Anything you say is expressing a thing you think. How can it be otherwise? I have definitely fought hard-lost battles, and everyone came out the worse for them... but it's still hard for me to understand why they happen, because anything you express is, by definition, something you think is true. Leaving out the words, it seems to me, just makes your expression less genuine.
- jeanettehead17 10y ago
  Author here. I like to say 'this way would be better because...' as much as possible. Providing a business case to back up your claim makes it less personal. Receiving feedback is never fun, but IMO it's easier to weather when there's a reason for that feedback being given that's more than someone else's opinion. Also having coding guidelines/linters is important from transitioning the conversation from 'I think it should be this way' to 'our coding standards say it should be this way' and removing some ego from the conversation.
  - RangerScience 10y ago
    I am all on-board with reasons with critique. I guess I'm asking about the difference between: "I think this is good/bad because..." and "This is good/bad because...." The latter one is just dropping words; it's still a think you think, whether you acknowledge that or not.
gedrap 10y ago
Comments on this thread gave me loads of food for thoughts and I missed the thread to comment on it, so decided to write a short post: https://medium.com/@GedRap/when-working-with-other-people-you-will-have-battles-d03b04bb6705#.8ezmi3llb https://medium.com/@GedRap/when-working-with-other-people-yo... tldr: We would like to think that all disagreements can be solved by rational reasoning, comparing alternatives and coming up with the best plan of action together. In an ideal world, yes, that would be the case. True, there are teams with perfect chemistry, aligned attitudes and views, no interpersonal friction, etc, but these teams are rare. It is naive to expect that every team to be perfect. We are not robots, and we are not working on some conveyor of code, moving from one to ticket to another, coldly and indifferently. Placing yourself into a position of other person, trying to understand their sometimes irrational motivations, and combining it with assuming the best intentions will go a long long way.

190 points by philk10 10y ago

I wanted to like this article, but I feel that it focuses too much on "winning" and "losing" - building software is (mostly) a creative task, and (I think that) treating it like a series of wins and losses can be a dangerous mentality to start off with. Finding a creative equilibrium between two ideas is the key to forming the right amount of "creative abrasion", but walking away from every discussion feeling like you won or lost is not going to get you there. If you're arguing about smaller or inconsequential things like tabs vs. spaces or other stylistic items, you need to spend some time and document guidelines, which should be enforced equally on everyone. This saves tons of time down the line, and eliminates a lot (but, of course, not all) of these problems.

mknocker 10y ago
I fully agree. When working on a team, you have to think about the future not only the current moment. If every time you have a disagreement it results in a win-lose situation I can guarantee you the mood among the your team will go down quite rapidly. I would suggest 'Getting to yes' by Bruce Patton, Roger Fisher, and William Ury on this matter of negotiation.
- pjc50 10y ago
  But this is one of the things that the article sets out to define! That the work process should not be driven individual competitive arguing (which is pretty much the default mode of interaction for male technical staff), but people need to think about whether the arguments that they find themselves having are worth it for themselves and for the team. "Conversely, there are several different conditions that constitute “losing.” The team can lose if you make a teammate feel like their contributions aren’t valuable. The product itself can also lose by missing out on early critique of its features, or by missing an opportunity to have its features developed less expensively."
- mk89 10y ago
  I don't know this book - thanks for the advice. I would recommend "How to win friends and influence people", which gives also good advice and a lot of hints.
  - mknocker 10y ago
    Yes. I read it. Good book indeed :)
  - AlexCoventry 10y ago
    Getting to Yes is a far, far better book than How to Win Friends, with a much more nuanced and broadly useful perspective.
gjmulhol 10y ago
I agree -- there was also a very "product v. engineering" vibe to it also. Maybe my company is different from most they see, but we don't have product doing code reviews for developers. The place tension can arise seems to be more around the fact that product always wants to move faster and engineering expresses that they can't always do that. I don't think either side is right all the time, but the way the article starts with "Winning battle = product giving into engineering", "losing battle = product being pushed into a better decision by engineering" screams to me of a lack of understanding that in a good organization each party has the best possible information for making decisions that represent the interests of the company from different perspectives, and these meetings are to figure out how those interests align or conflict and sort them out.
Practicality 10y ago
I generally agree, although she does try to redefine winning as a discussion that results in more of a win-win for everyone and losing as an area where someone "wins" the discussion but offends the other party, so it's not quite as contrarian as it seems. So, I think she means, a win for everyone, and she has the right approach. But I also agree with you, the terminology isn't quite accurate.
bigpeopleareold 10y ago
True, but some of this rang true since, in the past, there were certain people I felt like I was competing with. Over time, of course, that gets toxic and bad for business, something which needs a long-term solution.
ams6110 10y ago
Ideally things like tabs vs. spaces, indention levels or bracket styles, etc. are checked by a pre-commit hook so there's never a person being put in the position of choosing between looking like an asshole for picking on something "trivial" vs. upholding standards.
mk89 10y ago
Either I completely misunderstood the article, or ... I also had a similar feeling, and I think it's more productive to focus on results and goals, rather than "winning" or "losing". Nobody wants to be a loser. Further, I don't like the term battle, as it has a negative connotation, and this is exactly what you need to control or even to get rid of in a team: battle, win/lose, blood, emotions, arguments. In general I find the article pretty superficial and somewhat biased. In a real work environment you might have the best idea ever that might lead the product/company towards success, however, in front of you there is a senior dev/team lead to convince, and he is defensive and negative (and who knows, maybe he is having a bad moment in his life). How do you "win" this "battle"? By rationally "showing the numbers"? If we were all robots, this approach would possibly work, but in a team of 5 people there are 5 animals with 1) emotions, 2) personal problems, 3) different personalities, with ambitions, etc etc.

deleted 10y ago

[deleted]

kendallpark 10y ago

I agree with other commenters that this is simply too combative an approach. I've personally have had better luck with negotiation and redirection. I will say, I kinda burned out with product managers that don't understand technical requirements. Or product managers that lacked vision. I'm at a point where I'm pretty much done programmer other people's (uninspired) ideas (and am fortunate enough to be in a situation that allows me this freedom). There's a huge productivity difference when I'm working on a piece of software that I'm passionate about vs an app that consider misguided.

heartsucker 10y ago

I think this article misses the point that somethings are also completely right or completely wrong. For example, using string concatenation to build HTML and SQL. This is, just about always, a very bad idea. If a team is entrenched in doing this, it's not going to be a "winning battle" to undo it. You're going to anger the devs by changing all their code or making them use new libraries or whatever, but this is the way it needs to be done. I agree that approach matters, but let's not call it "battle skills," how about "not being a dick to your coworkers" and "interpersonal skills." If software development teams really are teams, take it from sports. Sometimes the captain needs to say "this is the playbook we're using, end of story" and everyone needs to trust that they're captain for a reason.

sleepychu 10y ago
"but this is the way it needs to be done." Actually, I'd disagree. It doesn't need to be done that way and this is a good example of a battle you're likely to lose that won't really cost you anything (other than some unpleasantness hand crafting SQL queries). I'd argue that even with significant opposition, any battle that needs to be won can. "I don't think we should store all the user passwords in plaintext on the server."
- gwbas1c 10y ago
  In that situation, the correct thing to do is get 1-2 people fired, or go find another job. Life is too short to work with people that incompetent.
- heartsucker 10y ago
  Please read about SQL injection[0]. Not using a library that escapes your strings is how Bobby Tables[1] ruins your production database. [0] - https://en.wikipedia.org/wiki/SQL_injection#Incorrectly_filtered_escape_characters https://en.wikipedia.org/wiki/SQL_injection#Incorrectly_filt... [1] - https://xkcd.com/327/ https://xkcd.com/327/
  - sleepychu 10y ago

haihaibye 10y ago

Interesting article, I like the focus on interdeveloper relationships. Software is a team sport, there should be more articles on this underserved area. We probably have more text dedicated to tabs vs spaces.

whack 10y ago

I agree with the author's advice, but a part of me can't help but feel that "picking your battles" is a sign of a poorly functional team. The entire premise behind "picking your battles" is that battles are expensive, and hence, you can't afford to fight every battle. But in a highly functioning team, bringing up suggestions and points for discussion shouldn't be expensive. It should be natural and fluid, with every person in the team expected to voice suggestions and concerns whenever they see them. In a team where people aren't constantly trying to jockey for position, where people are open to discussions without getting caught up in their egos, having people bring up suggestions freely is of great benefit to the team and the project. Maybe the real question that needs to be asked isn't how to "pick your battles", but rather, how to build an organization where people can contribute suggestions and concerns, without getting themselves dragged into a battle.

nilved 10y ago
> I agree with the author's advice, but a part of me can't help but feel that "picking your battles" is a sign of a poorly functional team. This is true, but practical. Most people will never work on a functional team.
- jacquesm 10y ago
  Applying this advice could quickly turn a functional team into a non-functional one.
  - hitekker 10y ago
    Which advice are you referring to, the OP or the parent comment? Little confused.
    - jacquesm 10y ago
      OPs
  - weberc2 10y ago
    Really? It seems like picking your battles can only help make a non-functional team a little more functional.

jacquesm 10y ago

How about some good old consensus? Battles are not the way to go, regardless of the stakes. If you feel the direction a project is going in is not to your liking you can always quit. As soon as you start phrasing things in terms of battles, winning, losing and so on you're going to end up very frustrated and potentially toxic to the rest of the team. A good team member knows how to make their objections heard without engaging in confrontational tactics and will be able to present their reasoning in non-confrontational fact driven terms. And is able to accept that they do not always get what they want. If that happens too frequently then maybe ask to be transfered to another team or maybe leave for another company. But leave the war and associated terminology and attitude out of it. I've had someone in our little group at TT who would approach each and every little item like a battle and I was very glad when he moved on, it's fairly easy to destroy an otherwise winning team when someone starts to treat the process of software development as something that can be won or lost. There is work to be done, and if we do it well we all win, and if we mess up then we all lose.

redether 10y ago
> How about some good old consensus? My concern with consensus, is that most teams are comprised of a single or two senior people supported with a larger number of less senior people. If consensus is the protocol-de-jour, your service/product/offering suffers in the mid-to-long term (as well as alienation of the senior people whom you want driving).
- jacquesm 10y ago
  > If consensus is the protocol-du-jour, your service/product/offering suffers in the mid-to-long term (as well as alienation of the senior people whom you want driving). I don't believe that is true. Junior people are only junior people if you treat them like that. If you are the lead dev and you work together with people junior to you (in experience, possibly not in years) then the fastest way to get them to grow is to get them on-board with the decisions taken as a team. "Pulling rank" is an option of last resort and it is actually a management failure, far better to spend the extra time to educate your team members to the point where they start making the right decisions. This may require introduction to some of the aspects driving commercial decisions but that's fine. That's an investment, and in a job market that is overheated you might be teaching someone enough to leave and to go work elsewhere but I've found that this strategy is more often than not rewarded with loyalty. At least half of these problems boil down to effective communications.

gwbas1c 10y ago

Honestly, if there are that many battles in a developer's day, it's a sign of mismanagement. Some bad company leaders think that the right thing to do is constantly have people negotiate over silly details.

jacquesm 10y ago
> Honestly, if there are that many battles in a developer's day, it's a sign of mismanagement. Or a bad hire.
- dbcurtis 10y ago
  Maybe. The article outlines some behaviors that a good manager would immediately squash. Most people will conform themselves to the prevailing culture. When bad behavior is confronted honestly, squarely, and articulately by a manager, the offender usually conforms to the healthier cultural norms as articulated by the manager. Only if the bad behavior is confronted and still persists can you call it a truly bad hire. In which case it should be dealt with. No amount of productivity justifies being a jack-ass.
arethuza 10y ago
"He observed that a committee whose job was to approve the plans for a nuclear power plant spent the majority of its time on discussions about relatively minor but easy-to-grasp issues, such as what materials to use for the staff bike-shed, while neglecting the proposed design of the plant itself, which is far more important but also a far more difficult and complex task." https://en.wikipedia.org/wiki/Law_of_triviality https://en.wikipedia.org/wiki/Law_of_triviality
shawn42 10y ago
I think it's important to keep in mind that the OP is a consultant not a developer at a product company. I'm sure they end up working with external development teams that can't simply be dismissed (or fired), but must be worked with for the good of the customer. Simply saying "bad management" or "bad hire" takes too narrow a view on software development. The OP is a developer trying to get work done with the team, not a manager with authority over the others.

samlikescode 10y ago

I think this is a really great article. It's unfortunate that people see a word like "battle" and assume that it is meant aggressively. It is just a theme for highlighting the reality that developers and designers disagree all the time. When you work with intelligent individuals who are passionate about what they are doing, there are going to be strong opinions. These situations can get intense, and it is exceedingly difficult when the other party thinks less of your opinion - like because you're a girl. Solid article on a tough topic.

eloycoto 10y ago

I'm in the middle of this problem and not sure If I'm doing something wrong. In the next month we are going to launch a new product, I'm full stack dev and I'm bit frustrated with my colleagues. I did all the devops and all developers(5) has his vagrant per branch, each vagrant box is deployed in one box so they can show to another colleague without trouble (I built a server with the subdomain with the $TASK-ID.subdomain) and the workflow is correct for all of them and they are happy. To deploy to staging/prod we have a full terraform + consul so we're in a happy place. In terms of code this is painful, they didn't make any test, I made around 50 test 1 month ago to show to them how to make test, but in one month, only one test was added in the project. In terms of the code-review they complain about good indention, and each time that they made a Pull-Request (pep8 and pyflakes) is not passed, and they use to complain about it. They use to mark task as resolved before code got merged, things to weird that I can't explain. I tried to explain why things need to change, I made a workflow in plantuml and they are complaining that it's too difficult. I'm the only one that made commits in the docs folder. Nowadays I'm thinking to switch to another company, but I'm happy with my manager (He is too honest), but the team is killing me, and I don't feel comfortable with them, I rarely learn from them and they don't want to do things better, they only want to work to raise money. This is a dead battle? Or can I fix this?

jacquesm 10y ago
You can fix it but it will take time and you will need to be very patient. (1) let go of your frustration, it is not helping you, if you can't GOTO 3. (2) pick the best of your colleagues and try to lift him/her up to your level with arguments, not with force (this will take time and oceans of patience) (3) if that does not work, start looking for other employment, no matter how much you like your boss (4) if it does work, then now you have a buddy, who already knows your method works, rinse and repeat at (2) until you've either had enough of it or you find that you now have a well oiled team. Good luck! (You'll need it, this is not an easy thing to do). And if you manage to make this work you are management material yourself.
- TheCowboy 10y ago
  I think it's not clear if he is the project manager or not. If he has a project manager, then we have to ask why he isn't helping focus the team. Or are they are product a team that is expected to organize themselves. I agree strongly with #1. #2 I think it might be good to approach it by asking more questions. If people say it is hard, ask how can we achieve the goal of writing more tests without it being a burden? Maybe OP is perceived as pushy if he's not the manager, or he doesn't allow for enough input on how the process evolves if he is the manager.

grandalf 10y ago

Most of the tensions described in the article are things that I believe can be modeled in terms of debts. It depends on which kinds of debt your team willingly takes on. Most teams take on at least one or two types routinely, no matter how religiously they avoid the others: Technical Debt: - build it fast by any means necessary - use whatever pre-packaged library exists, and duct tape it into your existing system. Analytics Debt: - build it without any prior UX experimentation on the design. - build it without any way to measure key interactions - have no data about the status quo before you build something new, this will insure that your new feature is a success because the before numbers are unknown. Marketing Debt: - build it without knowing whether users want it (or what they want) - build it without talking to users about their problems. Spec Debt: - build it without creating a detailed spec, leaving many important decisions up to the developer, who may not know the full reasoning for what she is building. - have a print designer do the UX, so that many subtle areas of interaction, animation, and behavior are unspecified. Mental Model Debt: - build it without having a hypothesis about why it is helpful and what might need to be changed next. This helps your engineers make choices that speed up this feature but add significant complexity for the next step. - do not worry about the statistical significance of numbers. Just focus on the direction the numbers are going and be sure your CEO knows how smart you are. Credibility Debt: - Don't acknowledge things that have gone wrong (with planning or execution) before. The pretense of infallibility is helpful to creating resentment and mistrust among different divisions of your team. Kool Aid Debt: - Whatever you do, be sure it is "agile" or "scrum" because then you have done everything right and you didn't need to worry about any of the above forms of debt.

poorman 10y ago

I wish I could tag people in hacker news articles.

makecheck 10y ago

Your experience/talent should dictate how much you press on an issue, and you should do it professionally regardless (e.g. no yelling, and listen to people; calmly state your point of view). Over the years I have encountered people arguing passionately about things that, as it turns out, they did not fully understand. It is fine to not understand things but if you’re new to a language/team, you should be saying things like “shouldn’t we do X?” or “I read on [site] that X is better”, and not act like you have found the One True Way to do everything. Ultimately, you need to communicate some experience/example showing why it is important to do X, or you must be in a position of authority where you can say that you choose X because there is no clear decision among the alternatives.

dbcurtis 10y ago

The article strikes me as immature responses to immature behavior from others. It's a How-To for creating a caustic environment. Try this: def leadership(): while true: have_clear_goals() articulate_goals_clearly() There is other stuff to good management, sure. But this will go a long way. The section on "when someone makes it personal" really irks me. It should never be personal in a healthy organization. You can vigorously debate the design, the implementation, or any other issue, while keeping the focus on the issue. It never needs to be personal. If it ever gets personal, a manager must step in and immediately squash that and make it clear "That's not how we debate things here. Personal attacks are unacceptable. Focus on the issues." But, really. Just have clear goals, then most decisions will make themselves. Debates can be settled by measuring alternatives against the goals. If, when measured against the goals, there is no clearly winning solution, then which one you pick probably doesn't matter, so everyone should stop wasting energy on decisions that don't matter and focus on the ones that do.

ryanmarsh 10y ago
This! I have observed at least 100 teams over the last 5 years. At any given time I'm coaching 4-10 teams. Every six months or so I get new teams. The number one problem I see is a lack of clear consistent communication of leadership's intent and values. Disclaimer: I might be hypersensitive to this because of my military experience. Complex adaptive systems of humans are always searching for systems with which to signal fitness and interpret fitness signals from others. If leadership does not pound these into the organization from their unique vantage point then the system will adopt its own in the vacuum. Rarely does such a scenario turn out optimal for all participants (for reasons beyond the scope of this comment).
- dbcurtis 10y ago
  It is interesting that you mention military experience. The best manager I ever worked for had been an Israeli commando officer during the military service portion of his life. (If you remember the rescue at Entebbe, he was in the "Plan B" unit that was staged and ready to go in without the element of surprise should Plan A fail. Happily, Plan A worked.) So what made him a great manager? 1) You never had any doubt in your mind whatsoever what he wanted and when he wanted it. 2) He then asked you if you had everything you needed to get the job done. And then he listened to what you said until he was certain that he understood, and got you what you needed or adjusted the plan. When you think about it, failure to do those two things as a commando officer means having to write unpleasant letters to parents. I mentioned this to another friend, also ex-commando (Royal Navy Special Ops Diver "We taught the SEALs how to do it.") He told me he often spent days thinking about exactly the right words to articulate the goal to his unit.

arielweisberg 10y ago

People (and I include myself) are lazy and will present that laziness via technical arguments and pretending not to understand/remember what you are saying. It's the steady string of previously debunked straw-man arguments or orthogonal unrelated objections that is the tell tale signal. If you keep pushing you are just burning relationship currency. If you dig in for every single little thing your going to be the bad guy org wide because people don't have enough context in most development workflows and aren't going to put in the effort to understand the technical or timeline issues at stake. You will just be the one who makes a fuss all the time. I've watch some solid people get pushed out due to this. As long as the harm is minimal I'll point it out and let it slide if the objections go off the rails even if the cost to do it right/better is less than the value realized from doing it right/better. Discussion isn't free. When the cost of dragging the discussion out is commensurate to the harm or value realized then that is when I will tax both myself and others involved in the discussion to address it. This is one reason to have these discussions before code is written and people are invested in not having to make changes. If you are brutal and break things down into small chunks delivered regularly the latitude for things to go sideways is reduced and discussion is more productive.

jacquesm 10y ago
> Discussion isn't free. Exactly, that's the key insight to have. Making the discussions more important than the project is a pretty good way to derail anything, there has to be some sense of proportionality.

boundring 10y ago

There's nothing caustic about self-censoring when your view isn't worth the headaches it might give others. In terms of development, you have to respect the views of your teammates and the effect of your position on overall workflow. Edit: for clarity, there's basically one guy here who's made it some sort of vendetta to object to the entire concept of a "battle," as though using that word for a disagreement is the issue. There's no such thing as a "perfect" team, but it seems his idea of that involves consensus. Consensus is an abstract, reality is defined by multiple viewpoints.

mixmastamyk 10y ago
It may be a cultural thing.

phhlho 10y ago

The hardest battles I've had are dealing with legacy code. The majority of teams want to improve the overall code base and correct past mistakes, but you can never fix everything right now. Deciding when to let the nasty thing lie and when to pay the cost of fixing something is a tough decision to make. Fixing costs are large and immediate but the cost of leaving a problem area is spread unknown across the future. Couple that with fixes that don't actually provide system value except for standardization and you can have all sorts of fun arguments.

dclowd9901 10y ago
This is something you have to decide organizationally. For our part as a frontend team, we've decided when we implement a new feature, it won't be in our old framework. Ever. We've built a way to integrate React into our old world areas of our code. Furthermore, the portion of the old world code that this new React code interacts with will also be converted into React. This way, our code has a sort of 100%+1% movement toward the new framework. The point is, you need to figure this out as a group and then just implement it as a rule. It can't happen during the code review.

jcadam 10y ago

At my current job we have a prima-donna software engineer who wins 90%+ of all battles simply because he throws a giant tantrum whenever a disagreement comes up. People (including the boss) usually just give in to shut him up. It's to the point people won't critique his work because he gets defensive and throws a giant hissy-fit if you suggest his explosion-at-the-pattern-factory nightmare of a module isn't just the most awesome piece of code ever created.

alarge 10y ago

This may be redundant with what others have said at this point, but I think this article is wrong-headed: it perpetuates the idea that you will/should have winners and losers. The biggest barrier I've found to helping improve an idea is that input is perceived as an attack on the author. And, far too often, engineers will say something like "that approach isn't the right one, this one is", effectively substituting their own solution wholesale for the original. If a team is ever going to be greater than the sum of its members, it must produce output that is better than any single member could produce on their own. That only happens when you move away from "your approach/my approach" to something like "here's a specific concern I have with the existing approach - how would folks suggest we address it? (here's one possibility)"

dbcurtis 10y ago
I think the article is looking for winners and losers in the wrong place. There will inevitably be winning and losing companies. People that put more energy into making sure that they, personally, win over other people in the organization are not focused on making sure the company wins. Asking "How do I win?" is a very different question from asking "How do we make the company win?".
- rhizome 10y ago
  The Iron Law of Institutions: http://rationalwiki.org/wiki/Iron_law_of_institutions http://rationalwiki.org/wiki/Iron_law_of_institutions

netcan 10y ago

I've been thinking about the word "ideology" lately. What does it mean? My grandfather was imprisoned by the Nazis and later fought for a Trotskist partisan militia. He hated "communists." According to him (as far as I understood), the defining feature of "communist" was fanaticism. The communists at that time, fighting Nazi & Fascist occupations or orchestrating revolutions under their ideological flag were ideological devotees. We remember Nazism and the madness that took a hold of Germany but I think we forget the context. Other ideologies of the period were less of an evil archetype, but not less devoted ideologically. Often they were just as bloody, if not in the same cold way. The communists that played the archetype role in my grandfather's experience (I assume his comrades, but IDK) must have been very fanatical. "A communist is someone who would sacrifice his mother for the cause" was how he'd describe it. This didn't (as far as I know) have much to do with what we might call "socialist" policy now. This wasn't an opinion about economics or social policy. Anyway... in a software context, the word ideology gets thrown around, often in a derogatory way. It's surprisingly hard to define it. I think a lot of the conflict points (losing battles) alluded to here are likely to have at least one person pissed off at the other's stupid ideology. "Agile" is the obvious one to bring up. This is mostly because it has a name, it's been successful enough to have beeen bastardized and tortured many times and it has a manifesto. But there are a lot of things like that. I haven't come up with a good definition, but I think a good chunk of it has to do with this: Ideology is contextual. When you're argueing for 'X' ideologically, you can't explain your reasons without going into a lot of abstract preamble. This is annoying to the people who disagree with the background reasoning and to those that have never looked into it. To them it sounds like you're saying "just because." Ideological bullshit. In a political context, one might be a libertarian. This has implications about the legal status of recreational ketamine, minimum wages, building codes, school funding and the approval process for new pharmaceuticals. It all ties in logically to the Libertarian perspective. But, if a libertarian is trying to be centrist, pragmatic, get elected or convince others to make laws then they have a choice. They can be "ideological" and talk about non-coercion or emergence or whatever forms the base of their ideological position. This then becomes about the ideology, not the specific thing. Or, they can talk about the specific thing, the law or policy. They can point to some study on minimum wages and unemployment or innovation and regulation in the pharmaceutical sector or whatever. This often feels contrived. That study isn't what convinced the idealist, the ideology convinced him. I don't know how this gets solved. I do think that it's important to keep a record though. what ideology do I subscribe to. Realize that when you disagree for ideological reasons, that you are entering tricky territory. As a side note, common ideologies are great for cooperation.

delecti 10y ago

Most of Amazon's corporate principles are a bunch of management buzz words, but situations to apply one of them pop up fairly often in design discussions. "Disagree and Commit" You're not always going to think that the design the team settled on is the perfect, but if you've laid all your evidence on the table and the team goes the other way, then you go the other way.

pascal1usa 10y ago

At our company code reviews are my way or the highway. Raising objections only gets you negative feedback. It's mostly for coding style, spaces, variable names.

RangerScience 10y ago

I have a question, that bothers me a lot: When someone says "there's a better way to do it", aren't they actually saying "[I think that] there's a better way to do it"? I think I understand that saying, simply, "I don't like the way this is done" isn't helpful, but I don't see how it's necessarily "personal", or rather, that any critique can be anything other than personal. Anything you say is expressing a thing you think. How can it be otherwise? I have definitely fought hard-lost battles, and everyone came out the worse for them... but it's still hard for me to understand why they happen, because anything you express is, by definition, something you think is true. Leaving out the words, it seems to me, just makes your expression less genuine.

jeanettehead17 10y ago
Author here. I like to say 'this way would be better because...' as much as possible. Providing a business case to back up your claim makes it less personal. Receiving feedback is never fun, but IMO it's easier to weather when there's a reason for that feedback being given that's more than someone else's opinion. Also having coding guidelines/linters is important from transitioning the conversation from 'I think it should be this way' to 'our coding standards say it should be this way' and removing some ego from the conversation.
- RangerScience 10y ago
  I am all on-board with reasons with critique. I guess I'm asking about the difference between: "I think this is good/bad because..." and "This is good/bad because...." The latter one is just dropping words; it's still a think you think, whether you acknowledge that or not.

gedrap 10y ago

Comments on this thread gave me loads of food for thoughts and I missed the thread to comment on it, so decided to write a short post: https://medium.com/@GedRap/when-working-with-other-people-you-will-have-battles-d03b04bb6705#.8ezmi3llb https://medium.com/@GedRap/when-working-with-other-people-yo... tldr: We would like to think that all disagreements can be solved by rational reasoning, comparing alternatives and coming up with the best plan of action together. In an ideal world, yes, that would be the case. True, there are teams with perfect chemistry, aligned attitudes and views, no interpersonal friction, etc, but these teams are rare. It is naive to expect that every team to be perfect. We are not robots, and we are not working on some conveyor of code, moving from one to ticket to another, coldly and indifferently. Placing yourself into a position of other person, trying to understand their sometimes irrational motivations, and combining it with assuming the best intentions will go a long long way.