5 ms·

Can be a tough act to balance in reality: "assuming the team feels comfortable with criticism" is where this well-meaning process falls over in most shops.

lfowles 3y ago
I've observed it used as a great way to shut down projects that don't immediately have demonstrable results
ska 3y ago
> is where this well-meaning process falls over in most shops I would argue that if you have this problem, it is fundamental, and your team will never be firing on all cylinders until you fix it. Admit it is not easy if the dysfunction is well set in.
- saulpw 3y ago
  Great, but then how do you fix it, how long will that take, and how do you get any work done until then?
  - RoyalHenOil 3y ago
    I have a job where we all check each other's work as a routine part of the process. Most of our work undergoes five official rounds of double-checking/feedback, and we often do a couple more unofficial rounds of testing just to be sure. Every round of testing always finds at least a couple of issues (often many more) and so we're all very used to getting feedback. Testing takes time, but we factor it into our schedule. When new people join the team, they make more mistakes than experienced people, which can be very demoralizing for them. There are a couple of things that I find helpful for this: 1, I warn them during training that they will make a lot of mistakes, but it will get better as they get practice, and I ask them to be patient with themselves. You can only learn one thing at a time, so some of the training won't click right away. 2, I tell them that even those of us who are experienced make mistakes; that's whole reason we have this feedback process. I ask them not to shy away from pointing out issues if they notice anything in anyone else's work, even if that person is much more experienced than them. 3, I make sure they see other people's mistakes before they start making their own; once they are out of the training period, their first tasks are to check other people's work, rather than do their own work. After that, they may be tasked with fixing other people's mistakes (which also helps them understand the sorts of mistakes to watch for in their own work later). Only then do they start their own work.
    - wiml 3y ago
      That sounds fascinatingly different from how most teams I know of operate. If you don't mind talking about it a bit more, what application domain do you work in? Do you know how this work style arose in your team?
      - kridsdale3 3y ago
        I hope its spacecraft design. 5 reviews!
  - ska 3y ago
    Incrementally is the answer to most of your concerns, but the specifics will depend a lot on context. More concretely, this is bread and butter stuff for engineering leadership. I mean that in the broad (including experienced staff) sense, not hierarchically.
yndoendo 3y ago
One of the best design evaluation methods I found was to teach and train others on the products. Occasionally doing onsite project installations was a good feedback loop. I wouldn't let them know I was a principal designer. Would sit back and see how well they grasped the design and constantly take notes on how to improve it. I want criticism about the designs. Tell me where you think the product is junk and why. There is not one user but many users you are designing for in a single product. Each has an unique take and requirements. Features to sell it, those that write the checks, and those that use it daily must both be met.
Exoristos 3y ago
If your shop is full of grown children, like this, then, face it, you're doomed regardless.
- convolvatron 3y ago
  so much discussion around software engineering these days is based on infantilization and making sure you get _something_ out of your fundamentally dysfunctional team. its pretty disheartening.
  - anotherhue 3y ago
    I keep waiting for the O’Reilly book “Agile: Managing Mediocrity”.
  - Pannoniae 3y ago
    Isn't what agile/scrum literally is? Or "equaliser" languages like Go? Both a trained monkey and a senior engineer will be equally mediocre in using it. Zero room for improvement.
    - lmm 3y ago
      I'd say that's backwards. Agile is all about having a lighter and more flexible process that allows skilled developers (very little correlation with "senior" IME) to go faster than something more rigid like RUP or Six Sigma. Agree about Go though.
      - Pannoniae 3y ago
        I am not talking about actual Agile (as in the Agile Manifesto), I am talking about the actual "business" bastardisation of it. Otherwise, I 100% agree with you :)
    - mattgreenrocks 3y ago
      Individual programmer skill is seen as taboo to discuss despite it having a huge impact on project outcomes.

lfowles 3y ago

I've observed it used as a great way to shut down projects that don't immediately have demonstrable results

ska 3y ago

> is where this well-meaning process falls over in most shops I would argue that if you have this problem, it is fundamental, and your team will never be firing on all cylinders until you fix it. Admit it is not easy if the dysfunction is well set in.

saulpw 3y ago
Great, but then how do you fix it, how long will that take, and how do you get any work done until then?
- RoyalHenOil 3y ago
  I have a job where we all check each other's work as a routine part of the process. Most of our work undergoes five official rounds of double-checking/feedback, and we often do a couple more unofficial rounds of testing just to be sure. Every round of testing always finds at least a couple of issues (often many more) and so we're all very used to getting feedback. Testing takes time, but we factor it into our schedule. When new people join the team, they make more mistakes than experienced people, which can be very demoralizing for them. There are a couple of things that I find helpful for this: 1, I warn them during training that they will make a lot of mistakes, but it will get better as they get practice, and I ask them to be patient with themselves. You can only learn one thing at a time, so some of the training won't click right away. 2, I tell them that even those of us who are experienced make mistakes; that's whole reason we have this feedback process. I ask them not to shy away from pointing out issues if they notice anything in anyone else's work, even if that person is much more experienced than them. 3, I make sure they see other people's mistakes before they start making their own; once they are out of the training period, their first tasks are to check other people's work, rather than do their own work. After that, they may be tasked with fixing other people's mistakes (which also helps them understand the sorts of mistakes to watch for in their own work later). Only then do they start their own work.
  - wiml 3y ago
    That sounds fascinatingly different from how most teams I know of operate. If you don't mind talking about it a bit more, what application domain do you work in? Do you know how this work style arose in your team?
    - kridsdale3 3y ago
      I hope its spacecraft design. 5 reviews!
- ska 3y ago
  Incrementally is the answer to most of your concerns, but the specifics will depend a lot on context. More concretely, this is bread and butter stuff for engineering leadership. I mean that in the broad (including experienced staff) sense, not hierarchically.

yndoendo 3y ago

One of the best design evaluation methods I found was to teach and train others on the products. Occasionally doing onsite project installations was a good feedback loop. I wouldn't let them know I was a principal designer. Would sit back and see how well they grasped the design and constantly take notes on how to improve it. I want criticism about the designs. Tell me where you think the product is junk and why. There is not one user but many users you are designing for in a single product. Each has an unique take and requirements. Features to sell it, those that write the checks, and those that use it daily must both be met.

Exoristos 3y ago

If your shop is full of grown children, like this, then, face it, you're doomed regardless.

convolvatron 3y ago
so much discussion around software engineering these days is based on infantilization and making sure you get _something_ out of your fundamentally dysfunctional team. its pretty disheartening.
- anotherhue 3y ago
  I keep waiting for the O’Reilly book “Agile: Managing Mediocrity”.
- Pannoniae 3y ago
  Isn't what agile/scrum literally is? Or "equaliser" languages like Go? Both a trained monkey and a senior engineer will be equally mediocre in using it. Zero room for improvement.
  - lmm 3y ago
    I'd say that's backwards. Agile is all about having a lighter and more flexible process that allows skilled developers (very little correlation with "senior" IME) to go faster than something more rigid like RUP or Six Sigma. Agree about Go though.
    - Pannoniae 3y ago
      I am not talking about actual Agile (as in the Agile Manifesto), I am talking about the actual "business" bastardisation of it. Otherwise, I 100% agree with you :)
  - mattgreenrocks 3y ago
    Individual programmer skill is seen as taboo to discuss despite it having a huge impact on project outcomes.