I’ll add: Pronouns like “it” are a common source of ambiguity in technical discussions. Avoid shortcuts in speech about a complex subject. Your audiences will more reliably understand you.
Don’t take this to mean that a wall of text is good. You want high signal and low noise.
This problem applies to all human communication, as does the advice given. There is one piece of advice which is missing however:
Define your terms: In programming most terminology is more clearly defined than in many other situations, but there is still plenty of room for ambiguity. When you say the software is laggy, do you mean there is a network latency problem, a rendering frame-rate problem or an interaction responsiveness problem? When you say back-end do you mean the non-UI client logic or the server logic? When you say crash, do you mean it hangs, crashes to desktop, resets itself to an earlier state, shows an exception report? When you say freedom do you mean (insert any samples of the 7 billion existing definitions of freedom here).
This is partly covered by “Make the sure ‘who’ and what are ‘clear’”, but not completely. There may be ambiguous terms outside of those areas.
On a higher level, there is two main questions in discussions:
What exactly do we have to decide? This is the difference between “which framework is best?” and “we are about to create a new service, should we use the same framework as we usually do?” This puts the discussion into a context. Without context you can argue past each other forever because everybody assumes a different context with lots of hidden assumptions.
What are the relevant aspects for the decision? You can compare web frameworks according to their parts and how mature/builtin/supported they are. These are usually not the decisive aspects though. Programming language matters though because your team usually is only really competent in one or two of them, so every other language would come with a big risk and learning effort. Sometimes you want to pick the long-term best option. Sometimes the next deadline is more important.
Without answering these two questions, precision in your discussions will be in vain. If you know the answer, then this article has good tactical advice.
I’ll add: Pronouns like “it” are a common source of ambiguity in technical discussions. Avoid shortcuts in speech about a complex subject. Your audiences will more reliably understand you.
Don’t take this to mean that a wall of text is good. You want high signal and low noise.
This problem applies to all human communication, as does the advice given. There is one piece of advice which is missing however:
Define your terms: In programming most terminology is more clearly defined than in many other situations, but there is still plenty of room for ambiguity. When you say the software is laggy, do you mean there is a network latency problem, a rendering frame-rate problem or an interaction responsiveness problem? When you say back-end do you mean the non-UI client logic or the server logic? When you say crash, do you mean it hangs, crashes to desktop, resets itself to an earlier state, shows an exception report? When you say freedom do you mean (insert any samples of the 7 billion existing definitions of freedom here).
This is partly covered by “Make the sure ‘who’ and what are ‘clear’”, but not completely. There may be ambiguous terms outside of those areas.
On a higher level, there is two main questions in discussions:
What exactly do we have to decide? This is the difference between “which framework is best?” and “we are about to create a new service, should we use the same framework as we usually do?” This puts the discussion into a context. Without context you can argue past each other forever because everybody assumes a different context with lots of hidden assumptions.
What are the relevant aspects for the decision? You can compare web frameworks according to their parts and how mature/builtin/supported they are. These are usually not the decisive aspects though. Programming language matters though because your team usually is only really competent in one or two of them, so every other language would come with a big risk and learning effort. Sometimes you want to pick the long-term best option. Sometimes the next deadline is more important.
Without answering these two questions, precision in your discussions will be in vain. If you know the answer, then this article has good tactical advice.