职业与工作方法plumshell.com
作为独立开发者，我决定提供电话支持，结果……
As a solo developer, I decided to offer phone support
2017 — 2021，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
一位独立开发者分享自己决定为应用提供电话客服支持的经历与收获：直接与用户通话让他更了解真实需求，也带来意想不到的反馈。文章引发了关于独立开发者是否该亲自做支持工作的广泛讨论。
为什么经久不衰：它触及独立开发者永恒的两难——写代码还是直接面对用户——不同开发者的真实经验对比至今仍有参考价值。
HN 评论精选
电话支持会打断开发者的心流，独立开发者难以兼顾两种角色
我做了10年电话支持，但后来逐渐放弃或转交他人。主要原因是我是独立开发者，写代码和做客服需要完全不同的思维模式。哪怕白天接一个电话，也会把我从专注编程的心流状态拉出来，切换到倾听共情的模式，就像让赛车手每次进站都得先织一条围巾才能再上场。有计划好修五六个bug的日子，结果被一连串电话占满，一行代码没写。我其实喜欢做支持，但最终必须权衡哪部分更能推动业务，纯开发胜出了。
cyberferret查看英文原文
I did it for 10 years, but more recently have moved away from phone support as much as possible (or delegated to others to do). The main reason - I am a solo developer. And the brain mode for 'developer' is VERY different from the brain mode for 'support agent'. It was basically impossible for me to get into 'flow' state during a normal working day. Even one phone call during the day took me away from my creative, programming mindset and into an empathetic, listening mindset. And the transition between the two were very different. It's like asking a racing driver to knit a scarf each time he came into the pits, before he could go out on the track to drive at high speed again. It also made it hard to plan blocks of work. Most times it was OK, but there were days where I would plan to do about 5 or 6 bug fixes, but I would get a slew of phone calls that meant I got 0 programming done that day, and would have to move other plans. I actually enjoyed support, but in the end I had to decide which of the two parts of the job was moving the business ahead more than the other, and pure development work won out.
亲自接触用户能让人更全面，是工程师成长的必修课
在苹果零售店做销售的经历对我的职业生涯帮助巨大。我参与的第一家创业公司里，三个人的团队每个人都亲自给教师用户做邮件支持。去做吧，每个人都需要做这种事，它会让你脚踏实地。如果你把自己框在“我是工程师”的角落里，觉得和客户说话有失身份，那是在限制自己。去和用户交谈、理解他们、共情他们，这会让你成为更好的工程师。对独立创始人或小团队来说，这更是至关重要。
whalesalad查看英文原文
Working at the Apple Store as a sales person has helped me IMMENSELY in my career, not only in terms of understanding how human beings approach technology but from a sales standpoint as well. In the first startup I was a part of, every single member of the 3 person team did email support for our school teacher userbase. Do it. Everyone needs to do it. Doing this kind of work is very grounding and humbling. When you box yourself into the "But, I'm an engineer" corner and decide it's beneath you to talk to customers, you limit yourself. Don't do that. Become a more well-rounded person. Talk to your users. Understand them. Empathize with them. It will make you a better engineer. And if you're a solo founder or part of a small team, it's even more critical that you do this.
电话支持是改进产品的宝贵信息来源，做好设计后需求自然减少
我做一款开票应用15年多了，通过电话认识了很多用户。我的原则是永远不怪用户，我会告诉他们：如果哪里不好用，那是我的错，我会修好，还会问他们觉得应该怎么设计。90年代我读过苹果的人机界面指南，深受启发，目标是做出用户无需学习就能使用的应用。15年过去，我几乎不再接到电话，感觉自己有点像那个“五月tag维修工”了。
oblib查看英文原文
I've been doing this for over 15 years with an invoicing app I have and I've got to know a lot users pretty well over that time. My app is simple and easy to use, and I've made "Training Videos" for just about everything you can do with, and I've had years to work out any bugs that have popped up, so I don't get a lot of calls anymore. But every call is a chance to learn something and improve the app and I pay very close attention to those who call. My approach is that it's never the user's fault, and I tell them that. I work click by click with them to show them how to do something and I tell them if something doesn't work it's my fault and I will fix it. And I also ask them how they think it should work. Before I made my first app back in the `90s I read a book Apple put out called something like "Apple Human Interface Guidelines". At first glance I thought it was a waste of money, but since I'd spent it I decided to read it all. It explained some of the history of the Apple GUI and how and why things were designed the way they were, which was basically on things people were familiar with, like "Radio Buttons" and "Checkboxes", etc. By the time I was done I realized the genius in the approach. I'm still impressed with it. My goal has been to make web apps that the user doesn't have to learn anything to use. That it all works like they expect it should. After 15+ years I've got pretty close now. I rarely get any calls or emails. Kind of feel like the "Maytag Man" now.
用户的初始表述往往不是真实需求，支持工作需要追问式沟通
多年前我拿了图书馆学学位，记得培训中有一点：读者来提“参考咨询”问题时，他们最初说的需求往往不是真正想要的。这是一个你来我往的“参考访谈”过程，需要协作式地弄清他们真正在找什么。这对任何技术支持工作都非常适用——顺便说一句，对任何利益相关者表达需求/规格的场景也同样适用。
jrochkind1查看英文原文
Some years ago I got a librarian (MLIS) degree, and one of the things I remember from the training was that when a patron comes to you with a "reference" question (you know, the kind of thing that doesn't happen anymore, before there was google when they'd ask a librarian what they now ask google)... what they initially tell you they are looking for (or at least what you initially hear/think they are telling you), is usually not actually what they want. The process is a give-and-take "reference interview" where you collaboratively get to the bottom of what they are actually looking for, not just a simple process where they explain what they need and you find it. This has been very useful and applicable to any kind of tech support, and this account reminded me of it. (Also, btw, applicable to any kind of stakeholder expressing requirements/specs too...)
历次讨论
同类还值得读
用十年时间自学编程（1998）
Teach Yourself Programming in Ten Years (1998)
Peter Norvig 1998 年的经典文章，回应“21天/24小时学会编程”一类速成书，主张真正精通编程需要约十年持续、有意识的练习。
职业与工作方法上首页 11 次 · 2007–2025norvig.com编辑精选如何成为一名程序员：简短、全面而个人的总结
How to be a Programmer: A Short, Comprehensive, and Personal Summary
一篇广为流传的程序员成长指南，作者以个人经验系统总结了成为优秀程序员所需的各项技能——从调试、测试、沟通到团队协作与身心健康。
职业与工作方法上首页 6 次 · 2008–2015samizdat.mines.edu编辑精选不要自称程序员
Don't Call Yourself a Programmer
经典职业建议文章劝软件工程师不要把自己局限在“程序员”这个标签上，而要从公司业务角度说明自己创造的价值；文中讨论了成本中心与利润中心、头衔、求职与职业选择，也顺带批评了学术界的价…
职业与工作方法上首页 5 次 · 2011–2021kalzumeus.com编辑精选创作者的日程与经理的日程
Maker's Schedule, Manager's Schedule (2009)
Paul Graham 在这篇文章里把时间表分成两类：管理者的日程以小时为单位，会议可以填满一天；创作者（程序员、写作者等）的日程则以半天为单位，需要长时间不被打断的连续块。
职业与工作方法上首页 5 次 · 2009–2021paulgraham.com编辑精选为什么程序员的薪酬不与生产力成正比
Why programmers are not paid in proportion to their productivity
讨论为什么程序员的薪酬往往不随其生产力成比例增长：生产力难以客观量化，薪酬更多受组织预算、岗位定价和个人议价能力影响。
职业与工作方法上首页 5 次 · 2009–2022johndcook.com