Daily Productive Sharing 114 - How to Optimise Your Thinking?
Daily Productive Sharing 114 - How to Optimise Your Thinking?
One helpful tip per day:)
(The English version follows)
#career_tips
很多程序员都会花重金优化自己的工作设备，比如高分辨率显示器，降噪耳机，机械键盘，升降桌等等。这些当然可以极大地提高工作效率，不过还有一些更隐性的东西需要我们关注：如何优化我们的思考过程？
今天的分享中，作者介绍了：
各种讨论（比如头脑风暴/开会等等）是实时的思考交流；
各种形式的文档（比如邮件，工作文档）是非实时的思考交流；
我们需要优化这两部分的交流来优化我们的思考。尽管听起来是很浅显的道理，但可能是我们忽略的道理。而且这些不仅仅对程序员有用，对于其他行业也有借鉴意义吧？
举个例子，之前和我配合的上游工程师只把数据库权限告诉了我，至于里面数据怎么存，有没有缺失都没有告知，需要我自己花时间去理解。当然我可以理解他的工作很忙（要维护上百个爬虫），但是每次数据异常我都要回去找他确认，到底是抓取失败，解析失败，还是我这边的处理问题。整个反馈周期非常长。如果他在交付数据的时候，同时提供一个简要说明，不仅能减少我的疑问，也帮他自己减轻负担。只可惜，他一直无法明白这些。
欢迎转发，感谢分享:)
原链
Talking, Typing, Thinking: Software Is Not a Desk Job
如果你想更好地管理时间，并且减轻自己的压力，不妨试试 BRNR List
如果你也想成为更高效的人，欢迎加入我们的 TG group
如果大家使用邮件订阅，请把 acacess@substack.com 添加为邮箱联系人，避免邮箱过滤的误伤，谢谢:)
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 :)
Link
Talking, Typing, Thinking: Software Is Not a Desk Job
Try our sustainable productivity tool BRNR List
Please add acacess@substack.com as your contact to avoid mislabeling the newsletter as spam.
Excerpt
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.