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

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

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

什么是好代码?

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

代码是否可读?

好的代码能简洁的表达你的思路。别的程序员很容易理解它。熟悉你的语言风格和语法糖。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的人产出的还要多。
对我来说,这些就是一个好的程序员的本质,如果你做到了任何一点,你就可以安慰的睡觉了,你是一个好的程序员。