你的老板或许真的很棒。我在我自己的编程生计中就遇到过几个诚意棒的老板，但即使是最棒的老板如同也常常老是不能了解软件开发。
事实上，我想说的是当触及到不止编程的几个元素时，大多数软件开发司理都有点目光短浅。
所以，我编译了一个简略的清单，用来说明关于编程一些最使你老板、开发司理、技能大咖等等误解的方面。
1.技能债务最会拖累项目
工作在一个满是技能债务的代码库上，就像是在烂泥堆中奔跑。起先，在泥浆还不是很厚的时分，勉勉强强走以前还没疑问，但当有个1米深的时分，你就步履维艰了。
我最喜欢的作家之一，《7 Habits of Highly Effective People》的作者，Steven Covey，称之为“P/PC平衡”或“产量vs产能。”
一般，管理人员和其他非技能性人员在推动生产力的时分，甘心牺牲质量——就像杀掉了下金蛋的鹅一样——然后导致技能债务。
当然，通过绞拧这只鹅的脖子，挟制它，你或许暂时可以得到更多的蛋，但用不了多少时间，死去的鹅就持久不会再产蛋了。
假设你的老板正遭受着不明白技能债务的痛苦，不知道技能债务是怎样正在拖累你的，那么建议你可以给他讲讲《7 Habits of Highly Effective People》中关于P/PC平衡中技能债务的条款。
大多数管理人员或许都会看过这本经典的书，所以比起你说写新功能很难是因为代码库太差劲，还不如说说书中的观念，更简略被他们所了解。
2.预估大多是废话
软件开发中的预估大多是废话。
这一点，你知我知，甚至团队意外的项目司理也知——当然，也有或许他不知道，但是他应当知道。
预估软件开发中的任何工作都是非常非常困难的，因为各种意外会让你防不胜防。
每一个软件项目，每一项任务都是新的。每次你坐下来写代码，总有一些意想不到的狗屎工作发生。
但工作便是这么。没有人应当为此担任。不是你的错，也不是我的错，不是任何人的错。它便是要发生。
但是，我们仍然情不自禁地会去玩这个“预估”游戏。
“Joe，你建立客户登录页面需要多久?”
“哦……呃……”随意想了个时间，“2天……哦等等——”忘了CYA加倍。 “——要4天。”
“好吧，那我给你5天”。
“好，那就5天。”
还有一个极好的处理办法是把任务分解到满足小的程度，将悉数的预估控制在4小时以内。
阅历告诉我，半天时间内的预估，一般能让你体面地结束工作。逾越这个点，那你便是废话了。
3.可以立刻或快速结束
敦促专业人士一般是一个差劲的主见。
我用我从写代码到现在逾越15年的时间里，学到了这个道理，所以我知道当我招聘别人做一些工作的时分，假设我敦促他们，没准他们会按时结束，但效果将是无用功。
意外的是，我发现很多软件开发司理如同不知道这个普遍真理。不知怎的，他们认为代码可以得既快又好。
可不要误解我的意思，我也承认是有破例的。有时，你的确可以快速地写出好的代码，但一般而言老是慢工出细活。
一样意外的是，大多数程序员，当被奉告要快点结束任务的时分，一般会选择走捷径，通过牺牲质量来加快进程。
更意外的是，这么的“代码快手”经常被当作英雄称赞，因为他们可以更快地结束任务，因为他们从不推迟或恳求更多的时间。
但是，这些“代码快手”一般会将代码写得乱七八糟，给其别人留下一连串的技能债务。
假设你正在打交道的开发司理不明白，快与好之间的联络，那么你最佳拿出一些统计数据，以说明后期批改bug比前期避免要耗费更高的本钱。
安排越大，以及触及的公事程序越繁琐，那么快速结束任务比精确结束任务的毕竟本钱就会越高。
(关于这个疑问的经典书本——《人月神话》。)
4.有的开发人员实践上是在帮倒忙
有一个事实是，我们都碰到过那种对团队弊大于利的程序员。
不一样的程序员，他们的软件开发领域才干和技能水平有着无量的差异。
事实上，有些软件开发人员差劲到他们在工作中写的每行代码都是在浪费公司的时间和本钱。
这种类型的开发人员或许应当付钱给公司，而不是公司交给他钱。
这对你而言或许是明白明晰的，但对老板却不尽然。比如说，在你看来，或许Joe是一个完全的失败者，是需要被解雇的，因为他只会干些“点金成石”的蠢事。悉数他接触的东西都成为了没用的“石头”。
但是假设你的老板不明白团队中有这些人比没有更糟，那你能做些啥?
好吧，大多数软件开发人员都怕自己被认为是一个爱搬弄是非打小陈说的人——我完全了解。
但是……你有必要这么做。这是对的。假设或人的确是团队中的害虫，那么让管理人员知道这一点也是你的份内事。
我知道这将会令你堕入不舒服的境况，但是假设你不陈说，那你就不是担任的程序员。你会成为杀死项目的喽啰。
至于所谓的陈说，只需稳重措辞和给一些提示就可以。
比如你可以这么说：
“嘿，我不喜欢做这种工作，但我觉得，假设我是你的话，我会想知道是不是有人直接阻止了团队。所以，我觉得这是我的责任来告诉你一些我一直在查询的东西。
……
当然，这些都只是我的查询，所以请和其他团队成员商量一下，根据你自己的阅向来区分。”
或许，假设你也可以运用这种不那么动听的办法：
“嘿!Joe很菜。他写代码实在是太慢了。事实上，他仅有可取之处便是他的慢，因为自从他来了今后，项目就基本上只能以蜗牛的速度跋涉。你再不精确了解他就晚了。”
5.非常好的设备是你可以出资的最便宜的生产力之一
我非常厌烦程序员告诉我——他们的小气鬼老板不给他们装备第二个显示器，或许让他们用的是现已5岁高龄的电脑。
老实说，我诚意不了解为何有的软件开发司理不一样意为那些8k+美元的程序员花费2k美元改善硬件——这是很合算的出资。
老旧的硬件装备让程序员诚意很懊丧，很烦躁!
每当有程序员抱怨这种工作情况时，我一般会建议他们另谋高就，因为这种老板的愚笨恐怕无药可治。
啥都别说，我告诉你：
好的设备能让软件开发人员一天多干一小时的活，让开发人员更有生产力。即使只需我说的数值一半的量，加起来的总时间也不会少。
假设算一年250个工作日，那么便是250×$35美元=$8750。即使你砍去一半或四分之一，这仍然是个不错的出资。
假设你的老板不明白这个道理，那么老实说，我不认为你能有啥办法。假设你诚意喜欢你现在的工作，那么就只能自己给自己出资了。
6.新技能的危险正本没你认为得那么高
没啥比提及.NET最新最棒的JavaScript构造版别更让软件开发司理感触惊骇的了。
这已然成为了我们心照不宣的雷区。
曾几何时，每隔一年支配软件供货商才发布构造或补丁的新版别，因此，差错的价值会恰当高。
曾几何时，大多数源代码是封印在“墓穴”中的，不允许其他任何人访问的，所以一旦该公司不再支持它，你就会骑虎难下。
但是现在，情况有所不一样。
现在的构造，有时甚至是在每天的基础上发布补丁，并且大多数盛行构造都是开源的，所以危险并不高。
当然，你也可以破罐子破摔，但这种情况不多，并且只需要稍作批改即可，而不是大刀一挥，好的坏的都割掉。
所以，假设编程司理仍然还活在1980年，那么你或许需要为他指出工作发生了啥改动，以及为何停留在构造或库的旧版别比晋级它更危险。
惊骇战略中的安全漏洞便是一个极好的突破口。
7.画蛇添足的业务分析师和项目司理
我知道接下来我或许会开脱不少人，但我不在乎。我在这里说的都是真话，我是那种看到啥就说啥的人。
当然，首先要声明的是，仍是有一些好的业务分析师和项目司理的——但说实话，大多数的业务分析师和项目司理毫无价值。
早年一度这些人物是开发项目所必要的。
但是现在，在大多数情况下，我们不再需要他们了。
软件开发人员应当直接与客户对话，以便于让他们自己搞明白客户的需要。所以我们不需要业务分析师。
这是一个残疾岗位，因为他们做的是软件开发人员应当做的工作的一半，却对另一半工作无济于事。
而项目司理更独特，他的政策如同便是奔着阻止我们开发，将悉数搞得一团乱而来的。
我知道他们是好心，但在其时的活络世界，项目司理现已体现不了作用了，所以还要他们干啥呢?他们四处走动妄图让自己显得首要，妄图找出他们可以做的工作，毕竟却只会阻止我们。
很多软件开发司理的主见仍然停留在以前，停留在那个职位更有意义的年代，他们信任了世界500强咨询公司的所谓的“潮流”——据这些公司所言，很多软件公司需要更多的高薪顾问人员来满足这些工作岗位。
假设你的司理仍是不明白，那么仅有的处理办法便是接受活络教育。
我不建议你直接告诉你的老板说“业务分析师和项目司理纯粹是在浪费氧气”——这或许也不那么简略被接受——所以，相反的，我会专注于说明一支活络团队应当怎样工作以及需要哪些人物。
然后很明显在一个实在的活络环境中，是没有业务分析师和项目司理的，他们或许更适合作为Scrum管理员或产品悉数者。
活泼自动
当然，上面我说的这些东西，有的我或许会用一种恶作剧的口吻说。但在实践中，软件开发司理和软件开发人员之间关于软件开发的了解常常是脱节的。
我敢肯定，软件开发司答理抱怨说，软件开发人员不明白业务方面，不知道安排会议安排的难点——但那是另一回事了。
不管怎样，要害点是：这不是一个仇视的形势，而是一个可以处理的关于沟通不畅的疑问——至少在一定程度上——可以通过合理的沟通沟通处理。
采用活泼而不是敌对的的办法，一般才是处理这些疑问的最佳途径。
你有啥主见吗?等待同享。
