A neat article. I particularly liked the humming strategy. Buried in that section is the fact that the Internet Engineering Task Force uses humming for establishing consensus, as described in the...
A neat article. I particularly liked the humming strategy. Buried in that section is the fact that the Internet Engineering Task Force uses humming for establishing consensus, as described in the RFC linked from the original article.
However, the RFC is about the process of reaching rough consensus which is much more than just humming. I'm very glad to have found it, because I think it describes strategies that could be useful even in small teams when it comes to establishing technical direction or making decisions.
Generally speaking the choice between several courses of action is probably a trade-off between avoiding certain kinds of risks. We know from research that people tend to underestimate risks they haven't seen and overestimate risks that they have seen.
Putting that in concrete terms: if you've run into difficulties scaling relational databases you might argue strongly for NoSQL type storage, and if you run into problems with data schema consistency you might argue strongly for relational databases. The reality is that most problems can be solved with either option, and the talent or art of engineering is figuring out the best one for the constraints of the problem at hand.
Of course everyone has a subjective bias based on their experiences. But I've seen engineers in particular have a blind spot where they see their opinions as objective and have difficulty hearing or believing something that conflicts with their experience or their biases.
The art of building consensus is necessary for something like the IETF or the United Nations but I feel like it's undervalued and the corporate world. Of course we do reach consensus or perhaps a decision-maker has "final say". But many of the design meetings that I've been in would have benefited from everyone on the team thinking about the problem and this way.
Not a teacher and I can't guess how well it would work, but the "classroom tips" look pretty interesting.
A neat article. I particularly liked the humming strategy. Buried in that section is the fact that the Internet Engineering Task Force uses humming for establishing consensus, as described in the RFC linked from the original article.
However, the RFC is about the process of reaching rough consensus which is much more than just humming. I'm very glad to have found it, because I think it describes strategies that could be useful even in small teams when it comes to establishing technical direction or making decisions.
Generally speaking the choice between several courses of action is probably a trade-off between avoiding certain kinds of risks. We know from research that people tend to underestimate risks they haven't seen and overestimate risks that they have seen.
Putting that in concrete terms: if you've run into difficulties scaling relational databases you might argue strongly for NoSQL type storage, and if you run into problems with data schema consistency you might argue strongly for relational databases. The reality is that most problems can be solved with either option, and the talent or art of engineering is figuring out the best one for the constraints of the problem at hand.
Of course everyone has a subjective bias based on their experiences. But I've seen engineers in particular have a blind spot where they see their opinions as objective and have difficulty hearing or believing something that conflicts with their experience or their biases.
The art of building consensus is necessary for something like the IETF or the United Nations but I feel like it's undervalued and the corporate world. Of course we do reach consensus or perhaps a decision-maker has "final say". But many of the design meetings that I've been in would have benefited from everyone on the team thinking about the problem and this way.
Interesting even to a non-teacher.