我最近和一个程序员晚辈聊天，他问了我一个很好的问题。这个问题非常好，让我停下来开始思考对学习的看法。这个问题是：

"我怎么知道我擅长编程?"

我常常会被问道和这方面类似的问题"我是怎么变得擅长编程的？"或者"我怎样才能变得擅长编程".这类回答就是结合你的工程实践，上课，看书，和优秀的程序员工作，贡献开源项目。但如果你把问题的角度转变为"我怎么知道我很擅长?"那就变成需要用工程的方式。你需要有个指标，进行优化。
除了实践之外，最重要的改进就是良好的反馈。当我们开启一个新的领域，没有一个好的导师，好的反馈就会变得很困难。课程通过考试或者工程实践来得到反馈。但是当你完成了课程之后，你怎样得到更高级别的反馈来全面提升呢？如果有一个好的反馈机制，那下面的事就变得简单了。
因此，我怎么知道我擅长编程？最好从询问："什么是好代码"开始。如果一个程序员不能写出好的代码，那他就不是一个好的程序员。

什么是好代码？

所有的代码都是为了完成任务存在的。首先好的代码要完成预期任务。任务的复杂程度可能非常高，但是代码不能超出他的要完成的任务。单间的反馈就是，"代码是否完成了预期目标"。代码只需要完成预期任务，不应该有其他没有设定效果。写好单元测试，能作为一个成功的衡量。
如果你不能成功的完成任务，那你首先得到的反馈就是，是否需要进一步的学习。确定你知识的欠缺并查找相关资料。系统理论告诉我们，如果你没有优化你的短板，你就是在浪费你的能力。这就是你从你短板上学到的东西。

代码是否可读？

好的代码能简洁的表达你的思路。别的程序员很容易理解它。熟悉你的语言风格和语法糖。3行代码可能被一行好的方式代替，但任然有高可读性。确保你的代码注释，解释好代码为什么这样写。如果你没有朋友帮你检查代码，你可以把代码发布到https://codereview.stackexchange.com/ 或者类似的网站。你未来半年别人能很好的接替你的工作。

是否容易拓展和修改？

很多程序员喜欢抱怨："需求又改了".事实是，你没有从产品特色和目的来考虑你的程序。需求常变是好事，如果你都做了3个月了需求还没有更改未必是一份好的工作。更多的时间应该带来更多的信息和需求。
在面试的时候我喜欢让面试者完成一个相对简单的编程任务，比如一个电梯系统。当他们完成后，我会让他们实现一个没有想到过的疯狂的功能。他们就会从社交和专业角度反馈出大量的技能信息。
一个好的程序员应该对这方面有规划。如果你完成了任务x,那就看看当条件k到q没触发时，是否很容修改x来完成任务x和y（不管是k和m发没发生这个时候只执行y而不执行x）.CS 101思想-就像多态性、继承和构成之间的区别-当时看起来没有意思，但现在感觉很有趣了。
改变代码能让你感受到更多的经验，但不要很快就添加过多的抽象层。过早的抽象就会变得跟Enterprise FizzBuzz 一样了(https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition)。

代码是否有效率?

效率从不同方面组成，完成速度和不同的资源组合，比方说内存使用，CPU使用情况等。幸运的是，每种语言都有他的分析工具告诉你程序运行时间和资源使用情况，这方面很容易追踪。熟悉这些工具，并看看你能把这些指标降低多少。如果你要重构一个已知问题，比如你自己写本地缓存，那就拿来和之前的对比谁更好。这样你可能开始从一个大角度来审视你的代码了，大体了解下不同的运行时间是很有用的。

你能写的很快吗？

在早期学习的时候，速度不是重点。编程速度竞赛让人敬佩，但从编程工艺来讲，那是很糟糕的学习方式。速度不是目的，更多的只是对进步的衡量。如果你已掌握了一个领域，你因该能高效的、高可读的完成你的代码，并且更短的时间进行扩展。
衡量任务完成时间很容易，但这个标准很难。你可能花费了大量时间在研究很多子任务上。这些是否是你需要深入理解的地方呢？可能你花费很多时间做手动代码测试，是否有更效率的自动化软件代替呢？看看你现在用的工具。你的IDE有很多快捷键来提升速度了，把你的大脑从机械化任务中解放出来，去考虑更高级的东西吧。

结束

如果你的代码都高标准的完成了，那么你就擅长编写这个任务了。如果你已经不知道该从哪方面提升了。你可以从复杂性上考虑，或者看看你希望提升的其他领域。
我想再加一件事来结束这篇文章。鉴于每天时间和生产时间的限制，只有一个人能做到这点。Elon Musk是一个出了名的有效率的人，但如果PayPal公司只有他一个工程师，他就不会走得这么远了。在一定程度上说，如果你想做一件大事，就要在团队中工作。此刻编程就是了群体活动。编程不仅要通过手和大脑还要有你和整个团队的配合。因此，好的程序员不仅仅是你自己编程有多棒，好要看和你配合的程序员有多棒。
有很多方式获得反馈。你对同事的代码审查之后他是否会做的更好？接下来的问题是他只改进了你检查的代码还是所有的代码？这仅仅是机械化的让人改进而非技术上的。你能不能让他们对这个任务充满激情明白改进方法的重要性呢。你是否提高了周围人的整体技能？著名的27x研究表明，最好的程序员是最差的程序员的27倍。如果你是一个7x的程序员，你帮助4个人从1x提升到7x，那么你就比一个27x的人产出的还要多。
对我来说，这些就是一个好的程序员的本质，如果你做到了任何一点，你就可以安慰的睡觉了，你是一个好的程序员。