12 programmer career, 12 lessons-programmers-IT information

I have worked for 12 years at ThoughtWorks. Isn't it strange? Looking back at my career, I wanted to write about my experiences in these years of difficulties, and the conclusion drawn on 12 very important lessons. Although I selected only 12, but there is far more than the numbers, but I think the 12 year 12 lessons more flavor.

1. the tool cannot substitute for thought

In my years of consulting work and work with many organizations and managers in the common routine I found to fix the problem, it's managers believe that tools can "solve" the problems are given. When the problem domain is well understood, and there can be many exceptions, and everyone acts the same way when this approach works. Unfortunately, many practical problems is not the case.

Too many times I have seen administrators using the tool lock to the organization-specific way of working. Naturally, the tool does not resolve the problem, and blocking the work of truly complete. Tools should be used to help to help protect against known errors, and helps us remember repetitive tasks, not replace thinking.

2. unless the management team to understand agile "change" values, otherwise it cannot play a role

Many managers have made such a mistake, it is that other parts of the Organization to make changes at the same time, only those involved in the work of the people need to "accept quick." Do in the enterprise and manpower needed to spend a lot of time and skill, because you have to focus on synchronized at different levels of the organization.

Accepted as part of an agile organization who want to organizations facing real threats. As the words said, "or change the Organization, either to change the way organizations. ”

3. learning needs a secure environment

Learning is necessary after making mistakes. In the Dreyfus model, which means that, especially in the higher primary stage, people need to learn by making mistakes. However, when people make a mistake will cause bad effects to work will lose the respect of colleagues, or hurting others in the process, so that they will not offend the wrong risks.

Because I'm passionate about teaching and learning, so I failed while trying to create a safe space where fails, you can make some basic mistakes to learn.

4. everyone can be a leader

I've written about this topic, because this is a very important observation. I saw a common mindset of pitfall is that people feel like a leader, you need to take the leading positions. But people can show their leadership, irrespective of its title, and can be done in many different ways to do this, just not clear on what is expected or required to take action.

5. the architects write code can often make the best decisions

The Tech Lead in the courses I run, I'm an advocate of technology leaders at least 30% them to write code. Spend time on coding helps to build trust, respect and understanding of the current system. When making architectural decisions, does not take into account the constraints of the current system often leads to wrong decisions.

6. change takes courage

I remember someone talking about XP values, there is courage. Courage is necessary for leadership, because you have to take the risk of failure, risk/return and try some new things. No risk, often will not have a great deal of reward.

7. confidence-building is the key word

There is an old proverb, "according to his words, and acted, not their deeds imitated. "In reality, no matter what you say, people first and foremost will remember how you act. You have to always remember to do as we say. Inconsistent behavior could undermine mutual trust. Say "no" or "not now" rather than promise to do one thing didn't do much better.

8. successful pairing with good collaboration

Although not all of the programming environment is healthy, but I believe that, when pair programming work, when teams tend to have a better culture of collaboration. Many developers prefer the (long-term) branch-based development anti-pattern because it delayed feedback and potential sources of conflict.

I (navigation), a healthy sign of conflict as a collaborative team. Delay feedback, such as long branch code review often leads to more discontent because it was delivered so late.

9. mode of thinking and allow for more powerful results

One of my most favorite subject in University introduction to philosophy, in the semester we will study the different philosophers. In the course of my career, I gradually learnt the value of diversity, and through more than one perspective. Systems thinking also recognizes that fact can be explained in a different way, so as to facilitate the emergence of new ideas or solutions.

10. recognizes that everyone has different strengths

Everyone is unique, and each has its own strengths and weaknesses. Although we tend to find like-minded people, but has a wide advantage teams can go better. Advantage in this area may be vulnerable in the context of a, so that when team members have a wide range of advantages, the team will become more powerful. Although the advantage of differences can lead to conflict, but health teams will accept each other's differences, rather than hate differences.

11. lifelong learning

The world changes, we always have the opportunity to learn new skills, techniques and tools. We can even learn how to learn, there are many books, such as the Apprenticeship Patterns and The First 20 Hours can teach you how to do this.

12. the positive effects of sudden happiness

Of the Drive, a popular book, talking about how people by one goal and give birth to a sense of well-being. In my experience, help others find a solution, have a positive impact on them, is a source of happiness.

Conclusion

Above 12 points not in 12 years of ThoughtWorks, I learned all of the lessons, but they are really helping me to customer service more important lessons.

12年程序员职业生涯，12个经验教训 - 程序员 - IT资讯

我已经在ThoughtWorks工作了12年。是不是有点不可思议？回首我的职业生涯，我想写一写我在这些年中经历的困难，以及总结得到的12个非常重要的经验教训。虽然我只选择了12个，但其实远远不止这个数字，但是我觉得12年12个经验教训更有韵味。

1.工具不能代替思考

在我多年的咨询工作和与许多组织和管理者的共事中，我发现了修复问题的共同套路，那就是管理人员相信工具可以“解决”给出的问题。当问题域被理解透彻，并且不可能有很多例外，以及每个人的行为方式相同的时候，这样的做法很管用。不幸的是，很多现实问题并非如此。

太多次我目睹管理者使用组织范围的工具锁定到特定的工作方式。自然，该工具未能解决问题，并且阻塞了工作的真正完成。工具应该是用来提供帮助的，用来帮助防止已知错误的，并帮助我们记住重复的任务，而不是取代思考。

2.除非管理小组能够真正懂得敏捷“转变”的价值，否则它就不能发挥作用

许多管理者都犯过这样的错误，那就是认为组织的其他部分在做出改变的同时，只有那些参与工作的人才需要“接受敏捷”。在企业中做这样的统筹需要花费大量的时间和技能，因为你要关注于同步组织在不同水平的变化。

那些想要组织的一部分接受敏捷的组织面临着真正的威胁。正如有句话所说，“要么改变组织，要么改变组织的方式。”

3.学习需要一个安全的环境

学习的必要经过是犯错误。在德雷福斯模型中，这意味着，特别是位于高级初级阶段，人需要通过犯错误来学习。但是，当人们觉得犯错会对工作造成坏的影响，会失去同事的尊重或在过程中会伤害到其他人时，那么他们就不会冒犯错的风险。

因为我热衷于教和学，所以我想办法创造了一个安全的失败空间，在这里失败的话，可以通过犯一些基本的错误来学习。

4.每个人都可以成为领导者

我以前写过这个话题的内容，因为这是一个非常重要的观察结果。我看到的一个常见的思维模式陷阱是，人们觉得为了像一个领导，你需要去担任领导的职位。但其实人们可以展示他们的领导力而不论其头衔如何，并且可以通过很多不同的方式做到这一点，只需在没有明确期望或要求的事情上采取行动。

5.架构师去写代码往往能作出最佳决策

在我运行的Tech Lead courses中，我提倡技术领导者至少将他们30%的时间用来写代码。花时间于编码上有助于建立信任，尊重和理解当前的系统。在做架构决策时，不考虑到当前系统的约束条件往往会造成错误的决定。

6.改变需要勇气

我记得曾有人谈论过XP values，其中有一点就是勇气。勇气是领导时所必须的，因为你要冒失败的风险，以及尝试一些新事物的风险/回报。没有风险，往往就不会有很大的回报。

7.建立信任的关键是言行一致

有这么一条古老的箴言，“依其言而行事，勿观其行而仿之。”在现实中，不管你说什么，人们首要的是会记住你是如何行动的。你得始终记得要言行一致。不一致的言行会损害相互之间的信任。说“no”或“现在不行”比答应做一件事却没有办到要好得多。

8.成功的结对编程与良好的协作相关

虽然不是所有的结对编程环境都是健康的，但是我相信，当结对编程有效工作的时候，团队往往具备一种更好的协作文化。许多开发人员更喜欢（长期）branch-based development的反模式，因为它推迟了反馈和潜在的冲突来源。

我把（可导航的）冲突当作协作团队的一个健康标志。推迟反馈，例如长期分支代码审查的情况往往会导致更多的不满，因为它交付得这么晚。

9.多模式思维促进更强大的结果

我在大学中最喜欢的科目之一是哲学概论，在那个学期中我们每周都会研究不同的哲学家。在我职业生涯的过程中，我渐渐体悟到多样性的价值，并且开始通过多个角度来看问题。系统思想还认识到，事实可以用不同的方式来解释，从而促进产生新的想法或解决方案。

10.认识到每个人都有不同的优势

每个人都是独一无二的，每个人都有自己的长处和短处。虽然我们倾向于寻找志同道合的人，但是拥有广泛优势的团队才能走得更好。这一区域中的优势可能会成为某个上下文中的弱势，所以当团队成员拥有更广泛的优势时，团队会变得更强大。虽然优势的差异可能会导致冲突，但健康的团队会接受彼此之间的差异，而不是憎恶差异。

11.终身制学习

世界在不断的变化，我们总有机会去学习一些新的技能、技术和工具。我们甚至可以去学习如何善于学习，有很多书籍，例如《Apprenticeship Patterns》和《The First 20 Hours》可以教你怎么做好这些。

12.积极的影响迸发幸福感

《Drive》，一本脍炙人口的书，谈论了人们如何通过朝某一目标前进而生出幸福感。根据我的经验，帮助别人找到解决方法，对他们产生积极的影响，才是幸福的源泉。

结论

以上这十二个要点并非我在ThoughtWorks的12年时间里所学到的全部经验教训，但它们确确实实是帮助我为客户服务的比较重要的经验教训。