(The English version follows)
如果你想更好地管理时间，并且减轻自己的压力，不妨试试 BRNR List
如果你也想成为更高效的人，欢迎加入我们的 TG group
如果大家使用邮件订阅，请把 firstname.lastname@example.org 添加为邮箱联系人，避免邮箱过滤的误伤，谢谢:)
Many programmers spend a lot of money to optimize their work equipment, such as high-resolution monitors, noise-canceling headphones, mechanical keyboards, elevated tables, and so on. Definitely, these can greatly improve productivity, but there is something more implicit that needs our attention: how to optimize our thinking process?
In today's sharing, the author introduces:
various forms of discussions (e.g. brainstorming/meetings, etc.) as a real-time exchange of ideas.
various forms of documentation (e.g. emails, working documents) are non-real-time thinking exchanges.
We need to optimize these two parts of communication to optimize our thinking. Although this sounds like a very simple truth, it is a truth that we may have missed. And these are not only useful for programmers, but also for other industries, right?
For example, the upstream engineer I worked with only told me the database permissions, but not how to store the data inside and whether there was missing data, so I needed to spend time to understand it myself. Of course I can understand his work is very busy (to maintain hundreds of crawlers), but every time the data had problem I have to go back to him to confirm whether it is a crawl failure, parsing failure, or my side of the processing problem. The whole feedback cycle was ineffectively long. If he delivered the data with a brief explanation, it would not only reduce my doubts, but also help him reduce his own burden. It's just a pity that he has been unable to understand this.
Welcome to repost, thanks for sharing :)
Try our sustainable productivity tool BRNR List
Please add email@example.com as your contact to avoid mislabeling the newsletter as spam.
Developers over-optimise for the ergonomics of typing and not enough for the ergonomics of thinking.
When people are too busy or just too shy to talk, the lack of high-bandwidth communication can make it hard to tease out requirements and unpack poorly explained business problems.
So for most cases: talking is critical, but in the right amount.
Writing code of course! But also… READMEs, comments, inline documentation, PR descriptions, code reviews, git commits; this is all part of the core work.
Much more importantly though, in my experience the best communication is written.
Having just extolled the virtues of writing READMEs, commit messages, PR descriptions, etc, I should obviously encourage you to read them.
Yet if I had a dollar for every time someone asked me a question that was already answered in the README I would have three dollars. 💰
When people don’t update the commentary, people become trained to ignore it, so people don’t update it, etc.
just find the authoritative document and slurp it into your brain.
The people I value working with most aren’t accurate typists, they’re clear thinkists.
Talking and listening; the verbal discussions. Most of the time we need a small but critical amount of high bandwidth synchronous comms.
Typing code commentary: READMEs, code reviews, PR descriptions; and all asynchronous communication: project updates, technical overviews, emails with next steps; These are all an essential part of the job and not just ancillary or busywork.