How to Pick Your Battles on a Software Team
spin.atomicobject.com
spin.atomicobject.com
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.
This is true, but practical. Most people will never work on a functional team.
Little confused.
If you have issues with how the team makes the decisions you have to tackle the problem at the root, rather than to make each and every decision a point of conflict.
"The more stressful a situation is, the more I find pragmatism is the best tool for improving the product and the team. What are your strategies for choosing when to push back and when to let it be?"
As soon as you start phrasing things in these terms everybody loses.
You're against someone being open when they disagree with something, whether or not their position is valid?
That's a little ridiculous. Being Taoist in withdrawal from conflict is one thing, but being a responsible member of a group is another.
Jacques appears to take a view that disagreement (or "picking battles") is tantamount to a fist fight, which obviously should be avoided. But, I think the OP and others discussing here rather think of of it as merely a difference of opinion, to be noted and moved past. In that sense, "avoiding disagreement" is not helpful because they are not noted, but buried.
By definition it can't.
> It's crazy to pretend like a software team will not have disagreements from time-to-time.
Sure you can have disagreements. So then you all present your arguments figure out which way forward is the best with as little ego thrown in as possible and move on.
Right now I'm involved on the side with a project where a ton of decisions have already made. I can choose to (1) accept this and be of help as good as I can or (2) revisit every decision already made and to argue about them.
My attitude is to choose (1) wholeheartedly because that's much more useful than (2) even if I might be right about some of those decisions.
If a choice is an existential one (as in, the company depends critically on the right choice in the longer term) then by all means, spend a great deal of time on the decision. But don't turn each and every choice into a 'my way or your way' discussion. It's pointless, it takes up way too much time and in the end a way is usually far more important than the way.
If you're dealing with people, then you are going to have problems with ego. Sure, it'd be great if everyone could lay down rational arguments, then come to a rational decision and rationally agree to move forward. It'd also be great if the unicorn færies showed up to take us all to Neverland. People have emotions; they hold grudges; they feel that fairness demands that if they yielded last time then someone else should yield next time; they have genuine differences in opinion and perspective.
A lot of software is art: there's no mathematically correct answer, just æsthetics or style or simply choice. People will disagree about which choice to take; they will feel ignored if they don't receive validation from time to time.
Now, an individual can choose to swallow his ego, but it's not pleasant — and frankly sometimes it's bad for the product to be quiet and let poor decisions move forward.
So yes, you have to pick your battles.
If you feel that 'software is art', that 'you are going to have problems with ego' then probably your view is that of the solist, and likely not of someone who would be happy in a team unless they get to call the shots and impose their will on others.
Good teams simply follow the leader and take their paycheck. Great teams cause the team members to grow and will produce work that none of the members individually could aspire to. Great teams know the strengths and the weaknesses of the members, and they themselves know these too.
If you want to phrase working together in terms of 'battles' then you've already lost.
And if you feel that if there is no mathematically correct answer about something, just aestetics or simply choice and the end result is less important than whether or not it was your way or the other persons way then I again conclude that you are most likely not a team player.
And there is nothing bad in that, there is definitely room for solists. But if you are part of a team then you have to play by team rules, otherwise it becomes a war zone with bad results for the project and the health and well-being of the rest of the team.
Nobody needs to 'swallow their ego' in order to present an option, the worst that can happen is that a particular road isn't taken, as long as you don't identify with the road as yours you'll do just fine. But as soon as you see the roads taken as validation of your ego then you are on very dangerous ground.
I think you're trying to fit human beings, which are extremely complex creatures, into an artificial black-or-white definition. I would even argue that no one in the world is exclusively a soloist or a team player. Most people, if not everyone, adjust their attitude to who they are dealing with.
For example, a given individual may be a soloist on one team, but a team player on another team, based on the experiences they have had on said teams. They also may be a soloist when dealing with someone they don't respect, or a team player when dealing with their boss. Just examples.
You say "best opportunities". If you're looking to earn a good living, that's hard to do solo. Very few people are good at all of the tasks that go into software development (and I'm including the non-development tasks, like sales and marketing of both the product and your development skills here). Also very few people manage to create a runaway viral hit on a small application (like Flappy Bird), where your solo work can earn enough so that you don't need to worry about making a good living on the other solo projects you choose to work on. For most developers, learning to work on teams with others is a crucial development skill.
This is where I've ended up due after many years as a software developer at start-ups because you can land a more stable job that pays better while not being driven crazy by micro-management.
Please, we should not be so dismissive. "Great team" commonly refers to output, not internal organization. (At least if we use a charitable interpretation. And if we don't, we're in the uncomfortable position of demoting many teams from "great" once we learn of their internal dynamics.) Many teams even often seem unaware of their dysfunctions.
Even if we don't use the charitable interpretation, then perhaps a "great team" would act on the assumption that it is almost certainly dysfunctional, as part of ongoing processes of self-improvement. After all, once you think you're perfect, you're in trouble. (http://model-view-culture.myshopify.com/products/your-startu...)
And teams aren't "closed". Outsiders (like that contractor or executive from another department) interact with the team and are momentarily part of it. Interactions with them may be dysfunctional, due to culture clashes, inevitable bumps as people learn to cooperate, etc.
I'd love to see an example of a team that is internally dysfunctional but that still manages to produce. I've been in this industry for 3 decades and yet I've never seen such a beast, on the other hand - and in the spirit of the argument - I'd love to see examples of this.
> Many teams even often seem unaware of their dysfunctions.
A dysfunctional team means: a team that does not perform (or at least, that's my reading of the word, it does not 'function').
To have some issues that could be improved on does not immediately qualify a team as dysfunctional, that's a pretty heavy term.
> Even if we don't use the charitable interpretation, then perhaps a "great team" would act on the assumption that it is almost certainly dysfunctional, as part of ongoing processes of self-improvement.
Yes, great teams tend to strive to become better (and they usually do). They also tend to leave companies as a unit and move on if they feel they are not appreciated, so for companies there is actually some risk to having a 'great' team, great teams tend to negotiate as one and team members will look out for each others interests.
> After all, once you think you're perfect, you're in trouble.
Agreed.
> And teams aren't "closed". Outsiders (like that contractor or executive from another department) interact with the team and are momentarily part of it. Interactions with them may be dysfunctional, due to culture clashes, inevitable bumps as people learn to cooperate, etc.
That's not how I would define a team but you are welcome to your interpretation and within that interpretation I'd agree with you.
In fact, I think that 'work / life balance' is precisely there, because teamwork costs energy and spending time away from each other is as important as spending time together, and there is more to life than code.
A couple of years ago I spent some time re-factoring a huge code-base that had totally gone off the rails. The guy that ran the project and I clashed quite badly when it came to the code and our approach to it (but since he asked me to help it was fairly clear that he was out of his depth from a programming perspective). When I got there there was no version control, the code was a giant hairball and literally nothing worked.
We spent the better part of two years untangling the mess and at each and every turn he'd dig in and make progress just about impossible. I tried very hard to keep my cool in all this and to just resort to facts rather than ego and I think that's the only reason that we did not end up in an actual fight.
Being a team player can be super hard, especially when everything is phrased in terms of 'your way or my way'. It eats up a huge amount of energy that could be used more productively and it tends to make it hard to leave the job without taking it home every day.
The hardest person I had to work with was someone who was super picky about using the right words for all social situations. If you referred to something as "your way" They would make a rather large deal of it. Most of the time, I was just trying to identify one of the two choices.
I mean, uh, the person in question was certainly worth working with, in spite of their social issues, and certainly, learning less confrontational language, you know, language less likely to set off other people is a worthwhile goal, but my point is just that if you spend too much time concentrating on the connotations of the words, rather than on the denotations, well, you can become pretty difficult to deal with for anyone who isn't used to walking on your particular brand of eggshells. Yeah, if you are good enough, we'll deal with it, but don't pretend that making a big deal out of connotations rather than denotations makes you easier to work with. It's quite the opposite.
I mean, I totally agree that minimizing ego should be a goal... but I also think it's disingenuous to pretend we don't have ego at all. We all have ego. It sucks. but it is. lying about it won't help. Acknowledging it and trying to move past it might.
Before that it was a bit of a madhouse, but they got a ton done. Which I guess confirms your point.
The whole article is about making a way more important, but also recognizing that valid concerns deserve to be addressed.
Balance.
That's because this is the best way to contribute to a team effort that is already underway. If and when my expertise is required for something I'm quite sure the other team members will know how to reach me.
I'm not sure what you intend to gain with misinterpreting what I wrote but it makes no sense to me. Enjoy HN.
The irony, here, is that you continue to explain your position as different from the article's author, then upon elaboration it's clear that you're disagreeing with her terms by some strange default.
You're not bonkers, but jayzus you're weird.
> By definition it can't.
Only if you assume that dysfunction is either a steady state and does not fluctuate, or that there exists two binary states of function and dysfunction, and nothing in between, or both.
If either of those are true, then it's possible to be on a great team (which is itself relative), and still either have aspects that are dysfunctional, or periods where it goes into dysfunction.
> Sure you can have disagreements. So then you all present your arguments figure out which way forward is the best with as little ego thrown in as possible and move on.
Sometimes, when that decision keeps coming back to bite you, and possibly you in particular, you feel the need to keep bringing it up, so others know it's an ongoing problem. That can be seen by others as someone not letting a decision go.
Does that engineering choice that resulted in a somewhat frail system keep coming back to bite you? Congratulations, now you're presented with keeping your mouth shut and just fixing it every time it breaks, or speaking up when it breaks so that people know it's a continual problem, and risk others thinking you are just complaining more, and promoting team dysfunction, or some happy medium, but where is that medium?
Re. whether teams are steady state or not:
I don't think every team can be fixed and I'm pretty sure that a single toxic new hire can potentially derail any successful and well oiled team.
Even so, many teams that do not perform well can usually be salvaged and teams that already work well are best left alone (and should do their own hiring if the org allows it).
I disagree with this logic. Teams are great if their functionality ratio (functional/dysfunctional) is high and the results are good.
Teams change/vary over time, and therefore you need to have some aggregated evaluation of overall effectiveness.
Also, on another note, what constitutes "conflict" varies from team to team. What looks like heated debate to some might feel like healthy discussion to another. It is relative to people's perceptions.
Much can be, has been said about team formation, I only have two contributions.
Empowering individuals is magic. When every team member is emotionally invested, committed to the shared success, great things can happen. I tried to accomplish that thru building trust.
I've sought to do this thru democracy in the workplace. Most of my team's decisions have been done via voting. Roman Evaluation for hiring, go/no go decisions. Approval voting for bug triage. JADs for project scope. Averaging everyone's estimates for schedule. Individual essays then shared with the whole team for post mortems. Etc.
Basically, I did whatever I could to build trust within the team(s) and beyond. For my role, that mostly meant honoring, enforcing the team's decision making (vs pulling rank).
Re-evaluate after a month to see if the chosen strategy works.
Building things when those important elements are missing will translate into building things of low quality and with potentially large problems, which may require costly re-work in the future. In a situation like that it is more often than not more productive not to build anything at all until those issues are resolved.
Crappy teams build crappy products.
Patrick Lencioni has a few great of books on this. If you like narratives or "buisiness parables" then read The Five Dysfunctions of a Team. If you prefer a more direct/didactic style, then read The Advantage.
Difficult Conversations from the Harvard Negotiation Project is also a useful read.
If you have an environment where everyone is just getting along and there's no conflict at all over major decisions, either no work is getting done, or the observer is blissfully ignorant of the conflict going on. Part of being a "highly functioning team" is that people pick their battles and don't bicker over unimportant things. "Battle" doesn't mean a screaming match -- just a disagreement that needs to be resolved in one way or another.
If you look at really poisonous workplaces, you'll usually find that there's alot of micro-management/supervisory control over all decisions, and the minions adapt by fighting over bullshit to "look good" in front of the micro-manager and ultimately get their way. Also, bike shedding (aka Parkinson's law of triviality) is a handy technique for concealing bad news.
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.
"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."
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.
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.
Try this:
def leadership():
while true:
have_clear_goals()
articulate_goals_clearly()
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.
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).
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.
Here's the mission, what do you need for the mission, and if all else fails here's my intent.
People think the military is full of mindless robots but in reality that's just how you're treated during indoctrination. Combat leaders must enable their people to thrive in chaos.
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.
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.
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.
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).
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.
People who enjoy having authority for its own sake are usually not good at this, since they think they have earned the right to be authoritative, and resist the dialog necessary to achieve true consensus.
Nothing makes me bristle more than having to clean up after mistake that I warned the team not to make in the first place.
I call those learning moments. Then I engage the people that made or caused the mistake and I'll help them clean up, rather than that I'll clean up for them. That way the lesson gets learned and the next time around it will be easier, and works a lot better than 'I told you so'.
It's usually thursday or friday evening that my team will pop some beers and talk conceptuals. In those informal discussions information just flows, sentiments are shared and fruitful decisions are reached.
Winning and losing battles implies that battles exist. That's bad enough for me.
How about it? What do you do when there is no consensus, because people genuinely, honestly disagree? Sometimes consensus is impossible.
And then you move on.
I have never myself seen true consensus work anywhere. It ends with a) one person caving and being resentful, or b) abandoning consensus because everyone realized for important things that it took too long or it never got done.
Even on small teams, it's been a goal, but often we have to say "ok, well you're outnumbered, so unfortunately we aren't taking that direction."
The machinery of consensus forming requires that people know what they know, and more critically, what they don't know. If a team is unable to determine the strengths and weaknesses of the constituent members then that's a recipe for trouble and this will lead to the frustrations that you outlined.
Let me give you one example of such a situation:
A while ago the front-end of an aging website had to be re-built, it's days were numbered but there were many good reasons to invest some time, money and effort into it but not to go overboard. The programmer hired wanted to do a 'good job' and came up with a whole raft of changes that were totally out of scope for the size change we had in mind.
Instead of forcing the issue I opened the books, calculated roughly how much it would require to do it the 'right' way and how much it would cost if we just did what was needed. In the end the decision was mine but I felt confident that we had achieved enough common ground that to do things 'wrong' no longer felt as bad as if it had felt if I had just told him that since I'm paying this is how we do it.
The project finished on budget, on time and was a pretty good success financially and we both benefited from that.
So yes, it is possible, but it will require an investment in time to educate your team members rather than to 'cause people to cave and become resentful' or to 'abandon consensus'.
I don't think you're describing consensus. I think you're describing the benevolent dictator who listens to his peers and subordinates.
Or maybe we're using different definitions of consensus here. As the OWS and anarchist groups I've come into contact with used it, consensus means 100% agreement for something to move forward.
Sorry but that is terrible advice. Most people would be out of a job with that kind of attitude.
>But leave the war and associated terminology and attitude out of it.
Nobody brought it in in the first place. The terminology was in quotes, to explicitly indicate that its not used in the dictionary meaning of the term.
> 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.
Sure, that looks excellent on paper, but I have found that it doesn't work with actual humans who are actually very _human_ with all of the associated (incl. negative) traits that humans have in varying amounts including pride, pettiness, jealousy, egotism and others. It has very hard to pickup on those because not everyone will display these traits overtly. They will mask it under other rationalizations or explanations or "objective arguments", or what have you. Many people are just sensitive like that. You can try telling them that their work needs fixing in the most gentle, objective way possible, but all they will hear is "XYZ thinks I suck".
>If that happens too frequently then maybe ask to be transfered to another team or maybe leave for another company.
Wow. Much of your comment reads like this to me - "This what a good team looks like, if you aren't on one, find another team or quit your job"
Yes, the dictionary term is related to armed conflict and it clearly wasn't in that sense.
> Wow. Much of your comment reads like this to me - "This what a good team looks like, if you aren't on one, find another team or quit your job"
You could also interpret it as 'this is what a good team should look like, try to steer your team in this direction or alternatively, build your own'.
Leaving is a last option, but it is much better for your health in the longer term if you are happy at what you do and being part of teams that approach their work in the manner described is a great recipe for either a burn out or other serious problems.
See the advice I gave another poster elsewhere in this thread.
I agree, and I've had to learn this the hard way after leaving 4-5 separate gigs that went fine for several months until someone new came on, or until an issue came to a head, etc. As software engineers, we have a lot of mobility and it's almost too easy to throw in the towel and move on; in any career, there are going to be conflicts, and you have to learn to confront and neutralize them in a positive way that doesn't involve the departure of yourself or the person with whom you're conflicting. "I'll quit" is too often the go-to and can stifle the development of individual professional conflict resolution skills. That option should stay off the table practically up until the point of complete collapse.
>Sure, that looks excellent on paper, but I have found that it doesn't work with actual humans who are actually very _human_ with all of the associated (incl. negative) traits that humans have in varying amounts including pride, pettiness, jealousy, egotism and others.
Right on again. This is another thing that I had to learn in the crucible after years of reading idealistic navel-gazing in trade outlets and message boards. There was a time I believed that while it required being highly selective, you could get a team together that would hold these values and function without pettiness. I now believe that's not really possible long-term and we must accept the petty and political nature of man as a fact of life (and we should be aware of this nature within ourselves as well, instead of naively claiming that we are above all of it; only regular rigorous self-analysis can reveal the influence of these natural tendencies). Not only is that political nature a fact of life, but it is exacerbated and brought to the forefront by the economic structure and corporate culture that we've developed in the West (which is not to say those things are necessarily bad).
I'd really like to see more content about coping with the reality of what we have in the real world, instead of the fantastic idealistic drivel that makes some tech writers popular.
That's not true.
The article is unfortunately ambiguous. It's pretty clear from the comments here that there are two different camps in terms of how people interpreted it.
However, it's quite clear to me that the author defines 'winning' as reaching a consensus on one person or the other's point of view, and 'losing' as battling to a stalemate or having one person impose their solution on the other. It's about the team winning or losing (or, to put it in other words, "if we do it well we all win, and if we mess up then we all lose"). 'Picking your battles' is an English idiom that means avoiding confrontations.
It's a little light on specifics, but it's not terrible advice. In fact, it's the exact same advice you are trying to impart here.
Even if you don't agree with that interpretation, I think it behooves you as a HN-famous person to at least consider the more charitable interpretation before publicly branding the author as someone whose "advice could quickly turn a functional team into a non-functional one."
Please consider re-reading the article with a view to trying to understand how other people may have interpreted it, and the author may have intended it, differently. Failing that, at least take some of your own advice and give up your scorched-earth battle to the death with the author and every commenter who read it differently. We're all losing right now.
It's terrible when this happens in person, such a painful way to agree and yet become separate.
I don't think we all lose, though. I think these situations result in someone hurting themself more than they realize. I've been there, but I failed to frame things properly.
In person, it's about being as honest as possible, if quiet when there's a complicated issue. Being honest, you can learn in-situ when issues arise, which is very much what Jaquesm supported.
I've felt terrible seeing great engineers leave meetings upset over minor issues.
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.
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.
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.
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."
[0] - https://en.wikipedia.org/wiki/SQL_injection#Incorrectly_filt...
[1] - https://xkcd.com/327/
Maybe I misunderstood what you had in mind when you wrote string concatenation but concatenating untrusted raw strings and using a library to construct SQL queries are not the only two ways to produce a SQL query.
The reality is that most people do not make value judgments based on objective criteria of any kind. This is true even among technical people, who rapidly build religious precepts around their nearly-arbitrarily-chosen pet technologies and then discard anyone who doesn't present with the tokens and signs of their adopted technical religion, regardless of that person's true technical ability.
People make judgments based on the amount of personal trust and goodwill they have toward the person making the argument. That's the natural status. With a lot of exercise, people can partially limit the effects of this impulse, but very few train at this in any significant way.
The moral of the story is that the way to win arguments is to be well-liked. It's a popularity contest. If you want people to let you do what you want, you have to make them like you. The objective merits of whatever you're arguing about are practically irrelevant.
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)"
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.
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?
(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.
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.
Not I'm not project manager, I'm single remote dev. My manager try to the other devs write test, but they said to him that is impossible or too complex. So at that time I spend 2 days and I wrote the test and I wrote a long email with links, howtos, benefits, etc.. Nowadays they still say that it's too complex and no value added. My manager can't say test in all places: they complain about it and I tried the #2 but it didn't work.
#2 worked well with the vagrant box, at first days was too complex, now they loved.. but with test and pep8 code style is a long battle. I think that I'm trying to change how they use to work, and they don't want to change how they work.
I always use to explain that, as a friend, is good for all, but I can't get it.
#1 Yes, me too, but when you reviewed 18 PR in 2 days without good code indention, half of them didn't work and 70% was mark as resolved in the task-manager I need to run a marathon every morning to keep away my frustration. Maybe was that last week I was on holidays and these days I only fixed problems.
An email with links and explanations might just fly over the head of a lot of people. One approach I used when working remotely is making short videos, or walking people through things using something like TeamViewer.
Tools are an important part to help a team execute a process, and you even seem to have devised processes ("a workflow"), but obviously you've got no buy-in from the team.
Aim lower. Take your colleagues with you. Step by step. And yes, at first it won't be all "good" in your opinion, simply "a little bit better".
But it seems to me you're trying to impose your ideas in a dictatorial style on everyone else, and at that point you'll meet lots of (ultimately unnecessary) resistance, just because they are uncomfortable with you bossing them around.
It's probably easiest to start with your manager and talk over these problems. Consider how your manager works:
Is he a data kind of guy? Show him how writing tests reduces bugs in the future and speeds development time. How will your changes allow you to ship more features or fix more bugs in the future?
Is he trying to make everybody on the team happy? Ok, see if you can get a few of the more senior people together on the team and talk over the problem in meeting and get everyone to agree on an incremental plan moving forward.
Is your team the kind that tends to hang out together after work? Go out with them once a week, see if you can bring this up in the group casually.
Maybe your boss thinks everything is fine and will only listen if you make more noise? Go into his office and be more direct about the problems you're having.
This also applies to the rest of the team. Consider that they may not see the problems with the project in the same way as you. That's not a bad or good thing, it's just that all people are different. You sound like you're frustrated because it's clear from the facts that there are not enough tests and your team's processes are not being followed. The rest of the team might think that "good enough" is all that is required, and adding more work (even if it reduces workload down the road) isn't a "nice" thing to do.
> I rarely learn from them and they don't want to do things better, they only want to work to raise money.
This is an opportunity for you to learn from them! It's just in areas that you may not be thinking about.
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.
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.
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.
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.
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.
The latter one is just dropping words; it's still a think you think, whether you acknowledge that or not.
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.
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.
Or a bad hire.
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.
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.