I'm really intrigued by the whole process of being a better, self reflective team - and in doing so, I'd be really keen to hear what different practices your team does - things that aren't necessarily standard across the industry - that you've found have been really helpful and you ultimately wish more tech teams did?
Ask HN: What non-standard practices do your team do that you wish more did?
1–6 of 6 posts
Re: Ask HN: What non-standard practices do your team do that you wish more did?
#2I feel like some people groan when they hear “pair programming” but I really do find it invaluable for knowledge sharing and making sure any member of the team can support many pieces of the system. It also helps devs get a clearer, shared unified vision of the direction of the code that they’re collaborating on and bought in to.
I don’t think it needs to be religiously followed, but it’s something we do a fair amount. It’s probably the best general practice that at least feels controversial.
Re: Ask HN: What non-standard practices do your team do that you wish more did?
#3I feel like some people groan when they hear “pair programming” but I really do find it invaluable for knowledge sharing and making sure any member of the team can support many pieces of the system. It also helps devs get a clearer, shared unified vision of the direction of the code that they’re collaborating on and bought in to. I don’t think it needs to be religiously followed, but it’s something we do a fair amoun…
There's definitely benefits to having a tightly integrated team with plenty of knowledge sharing. My problem with pair programming is that it is frequently an attempt to create those benefits via force.
Also, with traditional pair programming (one driver, one navigator) you're allocating two programmers on a single task, meaning that pair will need to generate at minimum the equivalent work of two programmers operating independently. I've never seen that work out to be true.
The only argument for pair programming I've ever subscribed to is that it can be used to more rapidly educate inexperienced programmers. If you compared the relative costs of inexperienced vs experienced programmers that math might pan out. Of course, then you have skilled programmers you're potentially underpaying, which is a problem in and of itself.
Re: Ask HN: What non-standard practices do your team do that you wish more did?
#4Our team does a 10 minute meditation together after standup. Totally optional, of course. Seems like most people really enjoy it.
Re: Ask HN: What non-standard practices do your team do that you wish more did?
#5I feel like some people groan when they hear “pair programming” but I really do find it invaluable for knowledge sharing and making sure any member of the team can support many pieces of the system. It also helps devs get a clearer, shared unified vision of the direction of the code that they’re collaborating on and bought in to. I don’t think it needs to be religiously followed, but it’s something we do a fair amoun…
I try to pair program with others any chance I get. It depends on the person, but usually I feel like we are being more productive than two individuals. Problems are solved faster, decisions are easier and we are also knowledge sharing and learning at the same time.
I do say it depends though, I think that if the skill level is too far apart it becomes more like a knowledge transfer or teaching, which feels way less productive (even if it is productive). I am also not advocating for this full time.
Some people hate it, I would love to hear some arguments against it.
Re: Ask HN: What non-standard practices do your team do that you wish more did?
#6I feel like some people groan when they hear “pair programming” but I really do find it invaluable for knowledge sharing and making sure any member of the team can support many pieces of the system. It also helps devs get a clearer, shared unified vision of the direction of the code that they’re collaborating on and bought in to. I don’t think it needs to be religiously followed, but it’s something we do a fair amoun…
There's definitely benefits to having a tightly integrated team with plenty of knowledge sharing. My problem with pair programming is that it is frequently an attempt to create those benefits via force. Also, with traditional pair programming (one driver, one navigator) you're allocating two programmers on a single task, meaning that pair will need to generate at minimum the equivalent work of two programmers operati…
I think other arguments are
- senior people sharing their practices and knowledge with each other
- senior people collaborating on a solution have shared sense of ownership on the direction they arrive at together, and working in code is more "real" than whiteboarding
- stronger relationships with coworkers, which is harder to come by in a remote setup