Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How to Pick Your Battles on a Software Team

spin.atomicobject.com

Post reply on HN
Print view View original

21–30 of 141 posts

Re: How to Pick Your Battles on a Software Team

#21

Post by gwbas1c »

sleepychu wrote: post #15
heartsucker wrote: post #12

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…

"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…

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.

Re: How to Pick Your Battles on a Software Team

#23

Post by heartsucker »

sleepychu wrote: post #15
heartsucker wrote: post #12

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…

"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…

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

[1] - https://xkcd.com/327/

Re: How to Pick Your Battles on a Software Team

#24

Post by samlikescode »

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.

Re: How to Pick Your Battles on a Software Team

#25

Post by redether »

jacquesm wrote: post #19

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…

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

Re: How to Pick Your Battles on a Software Team

#26

Post by samlikescode »

nilved wrote: post #18
whack wrote: post #17

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…

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

Even a great team can be dysfunctional. It's crazy to pretend like a software team will not have disagreements from time-to-time.

Re: How to Pick Your Battles on a Software Team

#27

Post by sleepychu »

heartsucker wrote: post #23
sleepychu wrote: post #15

Earlier quoted context omitted.

"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…

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_filt... [1] - https://xkcd.com/327/

Love that XKCD :-)

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.

Re: How to Pick Your Battles on a Software Team

#28

Post by Klinky »

heartsucker wrote: post #12

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…

What if the captain is the one who says you have to use string concatenation for HTML and SQL?

Re: How to Pick Your Battles on a Software Team

#29

Post by jacquesm »

redether wrote: post #25
jacquesm wrote: post #19

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…

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

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

Re: How to Pick Your Battles on a Software Team

#30

Post by jacquesm »

heartsucker wrote: post #23
sleepychu wrote: post #15

Earlier quoted context omitted.

"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…

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_filt... [1] - https://xkcd.com/327/

And this is exactly how one would deal with such a situation.
Post reply on HN