嘀嗒嘀嗒按：说说今天这篇文章的由来吧。这其实是一位同事一次发给组里的 email。当时觉得很受启发，所以就问他能不能翻译或者通过自己的语言重新组织分享给大家。他也知道我写公众号的事，所以很 nice 也很 happy 的就同意了。并且说：“Show me after you post it, I really want to see it.”
昨天在朋友圈发了一条：“如果发一篇纯英文的文章，会怎样？” 没想到得到很多朋友的支持。还有人说：“可以通过阅读量和赞赏看出本号订阅者的质量”。 池哥也说：“公众号这块别太看重阅读量，就可以做很多好玩的实验。”
When evaluating someone's technical proposal (in conversation, design doc or PR review) or making your own proposal, strive to provide technical options. The idea is to provide more information to the group, which can lead to a better tradeoff between time, features and quality.
I've recently come across several instances where people jump to conclusions without proper consideration for the bigger picture. I was reminded of the saying "Provide options, not excuses", and wanted to provide some more context around it.
It is a common saying that in software engineering projects you can choose any two of time, features and quality. One way to interpret this is: there is a constant balance between what you will do (features), how well you will do it (quality) and how quickly (time).
In a tech company, PMs (product managers) are usually the most opinionated as to the features of a project. Eng managers typically have the most context as to the timeline and its impact on the overall roadmap. Engineers are typically the most invested in the quality of their code and technical debt.
This is not a strict separation, rather an attempt to highlight where each group has the most vested interest. It is perfectly reasonable for an engineer to have product opinions, or for a manger to have technical ones.
When evaluating a technical proposal, you can say "This code is hard to read" or "I hate it when people do deeply nested if-s" or "we don't have time to build this new system this quarter". When you do, you are closing the conversation, and essentially making the technical tradeoff yourself, not taking into account input that might provide different perspective on the "time, features, quality" equation.
In contrast, you should always try to provide options:
"This code is hard to read. You might consider doing X or doing Y which will make it easier to read." (X and Y can have different quality/time aspects)
"This new system looks great, it will certainly make a positive difference in our technical stack. But option X, while not as clean from a technical perspective, is still a step forward and would require less eng time."
When you provide options, you are encouraging everyone to think about the time, features and quality tradeoff and making it more explicit. You will also prepare everyone for pushback that might be presented by others in the organization, showing that you've considered the alternatives and tried to make a good tradeoff.
This is yet another reason why it is so important to write your proposal before you jump into the code. A design doc or a whiteboard are much better places to evaluate options and make tradeoffs. By the time a PR is in review, it is much more costly from both a time and an emotional perspective to make changes.
NOTE: PR (pull request, a set of changes someone tries to push to a GitHub repository. Once a PR is sent, interested parties (peer engineers) can review the set of changes, discuss potential modifications, and even push follow-up commits if necessary.