初出茅庐的时候把事情做完
This site is supposed to be about software management. But sometimes you don't have the power to create change in your organization by executive fiat. Obviously, if you're just a grunt programmer at the bottom of the , you can't exactly order people to start creating schedules or bug databases. And in fact even if you're a manager, you've probably discovered that managing developers is a lot like herding cats, only not as fun. Merely saying "make it so" doesn't make it so.
这个网站本应该是谈论软件管理的。但是有的时候你没有权利独裁似的通过命令在你的公司里面来发起一些改变。很明显，如果你只是一个处于通天图腾的初级程序员，那么你没办法命令其他人制定进度，创建错误追踪数据库。即使你是一个经理，你可能也已经发现了管理程序猿更像是统领猫群。只不过没那么有意思罢了。仅仅说“去这样做”是没办法达成这样做的效果的。
It can be frustrating when you're working in an organization that scores low on The Joel Test. No matter how good your code is, your coworkers write such bad code that you're embarassed to be associated with the project. Or management is making bad decisions about what code to write, so you're forced to waste your talent debugging the AS/400 version of a retirement-planning game for kids.
当你在一个Joel测试里面得分很低的企业里面工作的时候会倍感挫折。不管你的代码写得有多好，你的同事们写的代码是如此的糟，以至于你都耻于把自己跟这个项目联系起来。或者说管理层对于写什么代码通常会做出错误的决断。所以你就浪费你宝贵才能去调试一个AS/400版本小朋友玩的退休计划游戏。
You could just leave, I suppose. But presumably, there's some reason you're stuck there. The stock options haven't quite vested, there's nobetter place to work in Podunk, or perhaps your boss is holding someone you love hostage. In any case, dealing with life on a bad team can be infuriating. But there are strategies for improving your team from the bottom, and I'd like to share a few of them.
你当然可以选择离开，我觉得。如果你还是卡在那里，总归是有些原因：股票期权还没办法兑现；没有更好的地方工作了；或者你老板劫持你的爱人做为人质。不管怎么说，跟一个糟糕的团队生活肯定会很吓人。但还是有一些策略是能够从底端开始改善你的团队的。我想跟你分享其中的一些。
Strategy 1 Just Do It
策略一 着手去做
A lot can be done to improve the project just by one person doing it. Don't have a daily build server? Make one. Set your own machine up with a scheduled job to make builds at night and send out email results. Does it take too many steps to make the build? Write the makefile. Nobody does usability tests? Do your own hallway usability tests on the mailroom folks with a piece of paper or a VB prototype.
通过一个人着手去做就能够改变一个项目的很大一部分。没有一个每日构建服务器？自己动手搭建一个。给你自己的机器配置一个计划任务，在晚上来运行构建并且通过电子邮件分发构建结果。搭建这个构建服务器会需要很多步骤？就写一个makefile。没有人使用可用性测试？那就跟收发室的那些家伙用纸或者是一个vb的原型自己来进行走廊可用性测试。
Strategy 2 Harness the Power of Viral Marketing
策略二 正视曲线市场营销的力量
Many of the Joel Test strategies can be implemented by a single person on an uncooperative team. Some of them, if done well, will spread to the rest of the team.
大部分的Joel测试策略都能够通过一个人在一个并不合作的团队里面实现。但是如果做的好的话，可以通过其中的一些人进而扩展到组里面的其他人。
For example, suppose nobody on your team can be persuaded to use abug database. Don't let it bother you. Just keep your own. Enter bugs that you find in your own code. If you find a bug that somebody else really should fix, assign the bug to them using the bug database. If you have good bug tracking software, this will send them an email. But now, you can keep sending them emails if they don't fix the bug. Eventually, they'll see the value of bug tracking and start to use the system as it was intended. If the QA team refuses to input bugs to the bug tracking system, simply refuse to listen to bug reports through any other channel. About the three-thousdandth time that you say to people, "listen, I'd love to fix that, but I'm going to forget. Can you enter a bug in the system?" they'll start using the database.
例如，假设你组里面没有人愿意接受使用一个错误追踪数据库。那就不要让它困扰你，你就自己使用自己的，输入那些你自己代码里面的错误。如果有其他人必须要修正的错误，那么你就通过你的错误跟踪数据库把这个错误分派给他们。如果你有很好的错误追踪软件的话，就会给他们发一封电子邮件。但是，如果他们不去修复那个错误的话你就可以一直向他们发送电子邮件。最终它们会发现错误追踪数据库最终的价值，然后开始使用这种系统。正中下怀。如果QA团队拒绝把错误输入到错误追踪系统中去的话，那你就拒绝从其他渠道来接受这些错误报告。直到大约第三千次的时候你跟别人说：听着我是想修复那个错误，但是我会忘记，你能够帮我把那个错误输入到系统里面去吗？这样他们就会开始使用错误追踪数据库。
Nobody on your team wants to use source control? Create your own CVS repository, on your own hard drive if necessary. Even without cooperation, you can check your code in independently from everybody else's. Then when they have problems that source control can solve (someone accidentally types rm ~ instead of rm ~), they'll come to you for help. Eventually, people will realize that they can have their own checkouts, too.
你的团队里面没有人使用源代码控制。你就创建自己的CVS仓库。如果必要的话就放在自己的硬盘上。哪怕没有合作你可以把自己的代码而不是别人放在自己的CVS系统中去。这样当他们遇到一些代码管理能够解决的问题时（例如某人不小心输入了rm ~ 而不是 rm ~ ）。他们会来找你寻求帮助。最终人们还是会意识到他们也要有自己的代码管理。
Strategy 3 Create a Pocket of Excellence
策略三 创建一些优秀案例。
The team won't make schedules? Or specs? Write your own. Nobody's going to complain if you take a day or two to write a minimal spec and schedule for the work you're about to do.
你的团队不肯制定进度计划？不肯写规范？那你就写自己的。如果你花个一两天写一个迷你规范，并且为你要做的事情制定一个计划。没有人会抱怨的。
Get better people into the team. Get involved in hiring andinterviewing, and recruit good candidates to join the team.
把更好的人招徕进团队里面。参与到雇人和面试中来，把更好的候选者招徕进团队里面来。
Find the people who are willing to improve and capable of it, and get them on your side. Even on poor teams, you're likely to have some smart people who just don't have the experience to create great code. Help them out. Set them up to learn. Read their code checkins. If they do something stupid, don't send them a snooty email explaining what's stupid about their checkins. That will just make them angry and defensive. Instead, innocently report the bug that you know is the result of the checkin. Let them figure out what's causing it. When they find the bug for themselves, they'll remember that lesson a lot better.
寻找那些愿意改进并且能够改进的人。把他们拉到你这边。哪怕是在很糟糕的团队里面也还是能发现一些很聪明的人。他们只是没有经验来创建伟大的代码。帮助他们，帮他们准备好去学，阅读他们提交的代码，如果他们做了一些蠢事情，不要鲁莽地给他们发一封电子邮件解释说他们的代码提交错误地方在哪？让他们自己去搞清楚。那样做只会让他们很生气，很有抵触情绪。相反故作无辜地报告这次题代码提交会造成的错误。当他们自己找出这个错误的时候，他们能够更好地记住这一课。
Strategy 4 Neutralize The Bozos
策略四 抵消笨蛋的影响。
Even the best teams can have a bozo or two. The frustrating part about having bad programmers on your team is when their bad code breaks your good code, or good programmers have to spend time cleaning up after the bad programmers.
哪怕是最好的团队都可能有一两个笨蛋。团队里面有糟糕的程序员的时候最让人感到挫折的部分就是：当他们的糟糕的代码，打断了你的良好的代码的时候。或者说好程序员得花上一段时间来清理这些糟糕的程序员留下的错误。
As a grunt, your goal is damage-minimization, a.k.a. containment. At some point, one of these geniuses will spend two weeks writing a bit of code that is so unbelievably bad that it can never work. You're tempted to spend the fifteen minutes that it takes to rewrite the thing correctly from scratch. Resist the temptation. You've got a perfect opportunity to neutralize this moron for several months. Just keep reporting bugs against their code. They will have no choice but to keep slogging away at it for months until you can't find any more bugs. Those are months in which they can't do any damage anywhere else.
作为一个初级程序员。你的目标就是最小化破坏。就是说限制破坏。某个时候，这些天才中的某一位。总会花上两个礼拜写一段让你难以置信的糟糕并且永远无法工作的代码。你可能想花上十五分钟，从头开始重新写这段代码。要抵制这种冲动，你获得了一个绝佳的时机来抵消这些傻蛋几个月可能造成的破坏。你只需要一直不停的对他们提交的这段代码报告错误就可以了。他们除了在这段代码上面努力折腾上几个月之外也别无选择。然后你就发现其他的错误。这些时间，就是他们没办法在其他地方造成破坏的时候。
Strategy 5 Get Away From Interruptions
策略五 远离打扰。
All happy work environments are alike (private offices, quiet working conditions, excellent tools, few interruptions and even fewer large meetings). All unhappy work environments are unhappy in their own way.
所有开心的工作环境都是一样的。私人办公室；幽静的工作场所；一流的办公工具；极少的打扰；甚至很少有大型的会议。而所有不开心的工作环境却各有各的不开心之处。
The bad news is that changing the working environment is almost impossible in virtually any company. Long term leases may mean that even the CEO can't do anything about it. That's why so few software developers get private offices. This hurts their companies in at least two ways. First, it makes it harder to recruit top notch developers, who will prefer the firm that gives them cushier conditions (all else being equal). Second, the level of interruptions can dramatically reduce the productivity of developers, who find it impossible to get into the zone and stay in it for any length of time.
坏消息是：改变工作环境在任何公司几乎都是不可能的。如果是长期的租赁合约的话，可能意味着哪怕是CEO都做不了什么事情。这也是为什么很少有软件公司为软件开发者配置私人办公室。这种情况至少从两个方面影响一个公司。首先，在这种情况下想要雇到最顶端的开发者就很难了。（在所有情况都相同的情况下）他们会选择那些给他们更轻松工作环境的公司。其次，打扰出现的程度和频度会极大地影响开发者的工作效率。在那种情况下，开发者很难进入高效状态并且在维持这种高效状态。
Look for ways to get out of this environment. Take a laptop to the company cafeteria, where there are lots of tables that are empty most of the day (and nobody can find you). Book a conference room for the whole day and write code there, and make it clear through the preponderance of checkins just how much more work you get done when you're in a room by yourself. The next time there's a crunch on and your manager asks you what you need to Get This Done By Tomorrow, you know what to say. They'll find you an office for the day. And pretty soon they'll start wondering what they can do to keep that productive thing going year round.
寻找离开这种环境的方法：带着笔记本到公司的咖啡厅。那有大量一整天几乎都是空着的桌子。而且没有人能找到你。或者是订下一个会议室一天，然后在那儿写代码。然后通过所提交代码的优势来清楚地表明这种状况。即：当你一个人在房间里工作的时候你能够多产出多少工作。这样下次你的老板碾压你，问你如果要把这件事情明天做完的时候你需要什么的时候，你就知道要说什么了。 他们就会帮你找一个能呆一天的办公室。然后不久他们就开始思考他们应该做什么来让开发人员一整年都保持这种高效的工作状态。
Come into work late and leave late. Those hours after the rest of the company goes home can be the most productive. Or, if you're on a team of developers who regularly come in late, get into work at 9 am. You'll do more work in the two hours before other people come in and start bothering you than you do in the rest of the day.
晚点上班，然后晚点走。那些公司其他人都已经回家的时间可能是你最具生产效率的时间。或者如果你在一个经常晚来的开发团队中。你就九点钟到公司，在其他人来上班并且开始打扰你之前的这两个小时你会产出。一天中剩余时间更多的工作。
Don't keep your email or IM client running. Check your email every hour, if you want, but don't keep it running.
不要总是开着你邮箱或者即时通讯工具。如果需要，每小时检查一下你的邮件。但是不要让不要让他们总是开着。
Strategy 6 Become Invaluable
策略六 变得珍贵。
None of these strategies work if you're not really an excellent contributor. If you don't write good code, and lots of it, you're just going to be resented for messing around with bug databases when you "should be" writing code. There's nothing more deadly to your career than having a reputation of being so concerned with process that you don't accomplish anything.
如果你在团队中不是一个优秀的贡献者的话，那么以上所有的策略都不会奏效。如果你不写大量的优秀的代码，你就会被别人憎恨。说你应该要写代码的时候，你却在搞什么错误追踪数据库。没什么能够比这更能够影响你的职业生涯声誉了。他们会有这样的印象就是：你不会实际完成任何事情只会如此专注于形式和过程。
Once, when I started a new job as a grunt programmer at a new company, I discovered that the company was running somewhere around 2 on the Joel Test, and I was determined to fix it. But I also knew that making a good first impression was crucial. So I allocated the first seven hours of every day to just writing code, as was expected of me. There's nothing like a flurry of checkins to make you look good to the rest of the development team. But I reserved another hour every afternoon before going home to improving the process. I used that time to fix things that made it hard to debug our product. I set up a daily build and a bug database. I fixed all the longstanding annoyances that made development difficult. I wrote specs for the work that I was doing during the day. I wrote a document explaining step-by-step how to create a development machine from scratch. I thoroughly documented an important internal language which had been undocumented. Slowly, the process got better and better. Nobody but me (and my team, when I was put in charge of one) ever did schedules or specs, but other than that we hit about 10 on the Joel Test.
有一次到我刚到一个新公司开始做一个初级程序员的时候。我发现这个公司。用Joel测试大概能打两分左右。于是我决定要纠正这种状况。但是我也知道一个好的第一印象是至关重要的。 所以我分配我每天的头七个小时都用来写代码。如我所料，我没有手忙脚乱地紧急提交代码。 这样就给整个开发团队留下了一个好的印象。 我订了另外一个小时，在每天下午回家之前来改善整个过程。我用那段时间来修正那些让我们调试产品变得更加困难的问题。我搭建了一个每日构建系统和一个错误追踪数据库。我修正了所有那些已经出现了很长时间的令人厌烦的让开发变得更困难的过程。我为我每天所做的工作都订下规范。我写下文档来解释如何从头开始一步一步的搭建一个开发机。我为一个原来没有文档的内部使用语言做了详细文档。慢慢地整个过程变得越来越好。除了我还有我的团队（当我被任命负责一个团队的时候）没有做过进度控制或者不写规范之外。我们在Joel测试现在大概能达到十分了。
You can make things better, even when you're not in charge, but you have to be Caesar's Wife: above suspicion. Otherwise you'll make enemies as you go along.
你可以让事情变得更好。哪怕你没有被任命来负责这件事情的时候。但是你就得像凯撒大帝的夫人那样兢兢业业 。 否则，你只会结交越来越多的敌人。
Any other ideas?
你还有些什么其他主意吗？