软件工程师的职业发展是有不少版本的，据书中介绍，证明个人能力的方法和模型有以下几种：
职业发展--考级之路
职业成长--Steve McConnell版本
职业成长--大公司版本
职业成长--自我评估
版本有很多，关键是能找到合适自己的职业成长之路。所谓的版本也只是给我们提供一个借鉴的机会而已。
巴克斯顿说技能的反面是“解决问题”。在学习算法技能的过程中，如果真想提高自己的技能的话，首先应该把基础打好，通过不断地练习，把低层次的问题都解决掉，这样你才能有时间去解决较高层次的问题。
知道理论的人实践能力并不一定就好，往往需要我们把理论放到实际运用中来使理论更加鲜活，更加明朗，这时候也才能体现出理论知识的作用。书中说练习之后，如果真想把模仿的产品推向市场，有两个问题。口诀是公开的，你可以抄，别人也可以抄。这时候就需要建立起自己的优势，通过自己的能力来使这个口诀的运用更加简单易懂，最好可以使复杂的问题简单化，当然这个同时也要注意不要丢失了该有的部分。既然老师说的是魔方的例子，我就想到了之前看的一档综艺节目，那里面的魔方选手除了比速拧外，还有盲拧，前者考虑到的更多是大脑运转速度，手指灵活程度，对公式的用法等，而后者首先很考察选手的记忆能力，然后就是运用公式的能力了，有些人的速拧很好，盲拧却不一定很好，有些则相反。运用到我们软件工程上来说可以是程序的运行速度和内存等性质。书中的第二个问题是各地市场和用户需求往往不一样，按口诀执行之后，会出现一定的偏差。这时的确是需要灵活应用的能力，而这个能力自然是需要我们一遍遍的练习的。
软件工程师的工作就是写代码，相关专业的练习也是以阅读代码，写代码为主，但是我们并不是盲目地以写代码而写，在这其中还需要考虑代码的构造之类的。
接下来我想谈谈对书中的P70页的案例的看法。
我先简单说明一下案例过程。程序员小飞原计划三天时间来完成某一个任务。在第三天下午的时候，在这个项目已经快完成的情况下，他意识到之前设计中的弱点，他应该采取另一种办法，才能避免后面集成阶段的额外工作。但是如果现在改弦更张的话，自己的能力会被老板和同事们怀疑，而如果继续下去的话，那么后面团队必将花更多的额外的时间在后续集成上。
我个人是支持第一种做法的。首先，一个项目的开始构思是很重要的，案例中的小飞在这方面还是有点缺陷的。然后，既然感觉“错”了，那就没必要继续下去，因为这关乎整个工程的实现，尽管后续集成可以花时间来解决，但是，后续集成所花的时间在本来计划里应该是没有的，我们不能因为个人原因而使得别人的工作量增大。案例中说的会让老板同事们看不起这种事，个人认为自己的能力就摆在哪，别人并不就会因为一次失误儿怀疑你的能力。怕怀疑的人只能说是自身能力不足，或者是不够自信。跟老板说明原因后，相信开明的老板会体谅你的失误的，毕竟谁没个犯错误的时候。