Ask HN: What non-standard practices do your team do that you wish more did?
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?
5 comments
[ 3.8 ms ] story [ 20.8 ms ] threadI 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.
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.
- 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
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.