中国古时候，有些手工作坊因生产人手不够，需要额外招收若干学徒帮忙。学徒报酬低廉，但很多人愿意去做学徒，因为做活期间，有机会向导师学到独门手艺与技巧。
学徒最终能到达怎样的高度，取决于导师能够并愿意拿出手多少干货，也取决于学徒有多资质聪颖，勤学好问。
战国时期的扁鹊，师从医术高明的长桑君，成就一代神医。
春秋末期，成语“有眼不识泰山”中叫做“泰山”的人，师从木工祖师鲁班，自身勤勉好学，成为根雕绝艺的发源人。
互联网行业也有导师与学徒之说。
现在很多互联网公司，新人刚刚入组，就会被指派一位导师，帮助新人渡过前三个月。
这三个月里，导师会有针对性地给新人提供阅读材料清单，布置合适的任务，估算合理的任务天数。新组员常针对技术栈和组内业务（business logic）向导师提问，往往能得到及时有效的帮助。
有时候，虽然你并非新人，也建议找一位或几位导师，这样你可以在技术、职业发展方面得到宝贵的指点。
与古代学徒制或者学校内的博士生导师不同，公司内部，导师不会由于帮助你，而直接收到经济回报，相应地，他们也并无真正的义务要帮助指点你。
所以，为了得到更好的帮助，学徒要注意以下几点：
第一，高效利用导师的时间。
在请教导师前，先自己阅读文档，在代码库中阅读相关代码，在谷歌或百度等搜索引擎搜索答案，尝试自己回答这个问题。百分之九十的问题，都可以自己解决。
但也不宜花费太长时间在一些细节问题上。有些问题，及早向导师请教会更好，很多时候，你花一小时才能搞明白的内容，导师花一分钟就能为你指明方向。
这个平衡点要自己把握，在高效解决问题的目标下，尊重彼此时间。
这条注意事项不仅适用于导师-学徒的场景，也适用于请教任何人任何问题的场景。
第二，学徒可以请求设置周期性的一对一会议（one on one）并自己准备议程（agenda），高效学习导师的经验。
周期性一对一会议的频率要随实际需要而调整。刚加入公司时，疑惑较多，可以是一周一次。后期取决于不同需要，可以改成两周或者一个月一次。
另外，每次的一对一会议（one on one）最好都有议程（agenda），比如“（1) 想学大数据, 问导师推荐哪些资源；（2）提升领导力的建议” 就可以成为一次半小时一对一的议程。
拿我自己举例，我尝试过和同一个人开有议程和无议程的一对一会议。相比无议程，有议程的会议，从效率上来看，无论从讨论事项数目还是质量，都要比无议程的一对一要高50%以上。
制定会议日程，虽然刚开始做的时候，会略感繁琐，但这会“强迫”学徒提前想好话题，问出有价值的问题。
有些导师有提前几小时看议程的习惯，就会对其中一些疑问提前做准备，到时，学徒在会议上得到的回复，很可能比导师即兴发挥更加详尽、精准。
第三，建立正确的期望（expection）。
按照大多互联网公司的规定，导师职责主要就是头三个月的帮助新组员熟悉组内工作（onboard and ramp up）。之后，大多数情况下，这份指导关系就自然解散了。
所以，要建立正确的期望。软件工程师职场上导师的责任，和其他上下文中的导师的责任（比如学校）并不一样。
不过，在这头三个月中，假如你通过自己的工作态度、工作成果，与导师建立了互相信任的基础， 你就有了与导师建立长期良好关系的可能。维持这样的关系，可以让你之后持续地获得宝贵的指导和帮助。
第四，严重不平衡的关系，是无法长期维持的。导师虽不求回报，但你要主动贡献自己的价值。
导师为你答疑解惑，让你在技术和职场上加速成长。那你怎样为导师贡献自己的价值？
如果导师与你在同一个组，你很好的一种回馈，就是在组内快速成长，分担更多组内责任，在自己所涉及的领域内能够为导师提供有价值的建议，快速回答相关问题，不掉链子。
这样，你在组内某一领域成为导师能依赖信任的人。导师也能够解放出来，去做更高层次更大维度的事而没有后顾之忧。
如果导师与你不在同一个组，那你可以做的，就是自然地与导师交流自己在组内的发现、感悟，期待其中有一部分能够扩充导师的见解，从而反哺。
第五，薪火相传，你应当时刻找寻机会成为他人的导师。
要承认，无论你怎样主动贡献自己的价值，都很难完全偿还导师的指点之恩。我们应当找寻做他人导师的机会，将这份“恩情”传递下去。
这是对学徒制度的维护，也是扩大影响力的方式。
另一方面，如果你作为他人的导师，设身处地，就更能体会出自己的导师需要什么，从而有针对性地更好地给予回报。
总结下来，作为学徒，应当高效利用导师的时间，在导师的帮助下尽快独当一面，努力回馈导师，也要记得，将这份感恩通过教导新人的方式不断传递下去。
