In my opinion somebody doing such stupid things as you have described above can't be a star developer! To me it seems like he intentionally makes things more complicated as they are, so that nobody else than himself can maintain the code. This makes himself more important than he really is! Talk to him. He has to change it! If he doesn't, replace him with a real star-developer!
I promise you, in even half a year he will not know how his own code works! Fire him and you can save a lot of time and money.
The CVS part is easy - an "accidental" hard drive failure will teach him a lesson for a life (make sure you have a backup though so you won't actually lose code)
Personally, I would let him go. He may be a star developer, but he isn't a team player. And you need to have a cohesive team that can work together if you want to make a good product.
播放您在电影中看到的坏警察/好警察小品。 让管理层当坏警察，你当好警察。 让管理层要求他提供过多的文档和每分钟的 ZIP 备份。 但是你为他提供了适度的文档（例如 doxygen 提供的）和通常的源代码控制检查......
Play the bad cop/good cop sketch you have seen from the movies. Let the management be the bad cop and you be the good cop. Let the managament ask for over-kill documentation and per-minute ZIP backups of his work. But you offer him moderate documentation (by doxygen for example) and usual source control check-ins...
If he really is a "star developer" he'll take note of what you say.
It may not change him overnight but it might be that he is just completely unaware that other people dont get it quite like he does.
Edit:
It's probably a bit late to change now, but more information is needed in working out a solution. It's impossible for anyone here to actually suggest letting the guy go based on these points alone. If you've been telling the guy every day for the last year that he needs to change or he's out of here, then you can let him go. However, I see no evidence of that.
A brilliant developer can be taught to use source control, comment and document. If you spend the effort here then you truly will have a star developer.
You might be focusing on the wrong area here, you are being provided with an opportunity to see some weaknesses in your process.
works in his own little area of his home directory rather than in the common CVS repository
A simple chat will probably suffice here, the benefits of version control speak for themselves and any "bright" person would likely be enthusiastic about those benefits. However it may also be a good chance to look into alternative version control systems that allow greater ease of use and flexibility (take a look at bzr and git). Better yet, get him involved in the selection process, if he really is a "star" he'll probably have good input and be more vested in its use.
doesn't document his code
It doesn't sound like documentation is part of your process. People are going to resist having to do extra work and if there isn't a defined process then you're talking about a lot of extra work. Is documentation really needed? If so, is there a process defined for creating it? should you have someone entirely dedicated to it? Should you at least have a tool to facilitate it (maybe something as simple as mediawiki)?
doesn't comment his code, e.g. 3,500 SLOC of C with no comments and no blank lines to beak things up
Three words: peer code review. Outside of obvious error-catching benefits, this also can provide some peer pressure, which is a strong force and can be a good thing. Wanting to be perceived well by your peers self-generates ownership and quality.
often overcomplicates things, e.g. uses three shell scripts that call one another to do the work that one simple shell script could do.
Again, peer code review. You mention that management knows about this programmer's deficiencies. Does he? It's rather difficult for people to change and improve if they don't recognize the problems with the way they're doing things.
And, perhaps best of all, by coming up with plans to improve your development process (which will likely improve not only your "star" but everyone else on the team) you can probably earn some gold stars for yourself from management.
Doesn't sound like much of a star programmer to me. All the good programmers know that code formatting and use of source control matters. Sounds like although he makes good progress by himself, he's obstructing the progress of the other team members, which might have a net negative effect on the work getting done. Talk to him, and if he refuses to change his practices, let him go.
If he really is that bright and you cannot change his ways, nor do you want to lose him but you still want your code to be documented and commented then my suggestion would be to let a less experienced developer do the documenting and commenting for him. Personally if I were a star developer I would feel prettiy foolish if someone else was made to comment my code and I would start to do it myself eventually. In the meantime while that does not happen the less experienced developer may learn a thing or two.
There's more to being a star developer than just being an excellent programmer. If he doesn't have team skills and is purposefully ignoring team standards it needs to be brought up to him. If he refuses to adhere to them after talking with management, perhaps he's not the right fit for your company.
This question makes me nervous, because while the person you're describing sounds egregious, I can see a little bit of myself in him.
I think I'm a pretty good team player, and I'm lucky to be on a very good team. However, I do use methods that my colleagues don't understand, though I've tried pretty hard to explain them. There just is a pretty large experience gap, which is no reflection on any of us.
Documentation is a broad and tricky subject. I try to follow the DRY (don't repeat yourself) maxim. Documentation that is separate from the code can amount to repeating yourself, so it is liable to get out of date unless you slow yourself down to keep it up to date. My usual approach is to touch it up afterward.
Often the problem I'm working on is so tricky that I can advance plan and document all I want, but when it comes to the code I often discover that I was wrong and have to re-think it. So the idea that you can document stuff in advance, and just follow that, only works for pretty straightforward problems, it seems to me.
Anyway, I think this is an excellent question, and the answer is not at all simple.
Is the guy really a rock star? Seriously? Think about it for a second. Is he smart, but doesn't get things done, or is he both smart and able to get things done?
Think about it really hard.
If he really is a rock star, then maybe you shouldn't mess with him. He's producing incredibly awesome things using his own process. Just because there's a different way of doing things that works best for you, doesn't mean that's going to enable him to produce his best work. Instead of trying to get him to bend to your process, which very well could kill all of his awesomeness, you should try and find a way to accommodate the way he works.
If he really is as good as you say, you shouldn't mind doing that. If it isn't worth the effort to do that, then he really isn't that good. In that case, you don't have a rock star, you just have a mediocre programmer that doesn't like to play be the rules. Those guys, you should just get rid of. A temperamental rock star is usually worth the pain, though, because of the quality of what he or she can produce. Those people, you should go to great lengths to keep.
Sounds like a star programmer who's bored of his job and is over complicating things to make it more of a challenge. He'll find something better soon enough.
Trying to change things? What do you prefer, a poorly documented working piece of software or a well documented junk? Some people is capable of writing software that requires little to no comments, that is not a reliable indicator of quality.
just a little informal heads-up to tell you that from next week, we'll be requiring documentation of code, and helpful commenting in the code - it's going to be company policy, and there'll be no exceptions"
From then on, you just deal with that failure the same as you would deal with a failure to turn up on time, a failure to stop goofing off during work, etc. Bottom line is if the boss says document, you document or you're not doing your job properly.
If he is working like this, he is not a star developer - great software developers understand that maintainability is extremely important. You will probably pay dearly for this in the long run, I would be very direct with him about how serious this is and let him go if he can't start to adjust. I have seen this plenty of times before and it is a ticking time bomb.
To be perfectly honest, I have seen plenty of developers like this and, unless they are just out of school, they won't change. I say cut your lossless now, its only going to get harder to fire him as he continues to spew out more unmaintainable code :)
It's very unlikely that management will get rid of him if he is really bright.
The whole project may be closed, of course, but there will be no use in CVS and documentation then, anyway.
No management will fire a good programmer only to hire a bad one.
Tell him that it will help him to get rid of management whenever he wants to.
What is he wants to change job? He can tell management: "OK, people, everything's just like you asked me: checked in, documented and under you control. I'm done with my part, I pack and leave".
Can the team be successful with out him? If so push the issue and refuse to accept any code that isn’t properly documented or doesn’t meet other standards. Hopefully this will get the point across but it might just make him angry and cause him to quit. If the team can’t be successful with out him then you’re out of luck until you can train a replacement up to his skill level which may not be worth the time and effort.
+1 to ocdecio - if he is a star developer, then his code should be based on such a high-quality design that it documents itself.
Having said that, the frustration could be that although he's excellent in technically-demanding areas which are interesting to him, he doesn't muck-in with the delivery of features - only you will know whether this is a problem for your organisation.
Having a "guru" available can be an absolute life-saver - or at least it used to be, or has StackOverflow made that role redundant?
Don't let the code be released until it has passed code review and only allow it to pass if there are enough comments and/or documentation for the code which he has written for the current feature/project.
Edit Bring it up in his appraisal. Documentation / commenting code can be given to him for his "Areas of improvement".
There's a lot of folks here on the "no comments, so what?" bandwagon here. Literate code without comments is perfectly possible, but just because someone is smart and doesn't comment doesn't necessarily mean that they are writing literate code.
So let's clarify. You already said he doesn't document his code at all, either in comments or separate documents, and he doesn't use any source control. How about:
Is his code understandable despite the lack of comments?
Does your team use any kind of issue tracking (e.g. FogBugz, Bugzilla, etc) which he participates in?
Is his code under test?
Is there anyone else on the team who actually is at least somewhat familiar with how his code works?
Is he willing to at least acknowledge that he could stand to make some changes in the way he works with the rest of the team?
If the answer to all of these questions is "no", you have a big problem. Just being smart doesn't necessarily make someone an asset. Do you have any guarantee that he won't leave your company tomorrow, or get hit by a bus? How screwed would you be if that happened? Is it worth the risk?
I think this is pretty typical in any environment. How do you get someone to do what you want? This is exactly what "How to win friends and influence people" is all about. Dale Carnegie was not about manipulation, but managing people.
It sounds to me like he's just inexperienced and needs some experience and guidance.
Do you think you can sit down and talk to him about these issues? Telling someone they're doing something wrong often seems like the wrong thing to do (especially in today's western society where we don't want to hurt other people's feelings) but I think you can get very far by calmly and honestly explaining the issues and talking them through. It helps if the person respects you and your opinion, which is a whole other issue and is talked about in the book mentioned above. Make sure he understands that these are serious issues. Also, that in any future development jobs he'll be expected to do these things too so it's a good idea to practice them now.
I don't think waiting until the next performance review is a good idea. Piling up a bunch of negative feedback and delivering it all at once is just a bad idea and I really disliked it when that was done to me.
If he overcomplicates and does not use SCC, he is not an excellent developer -- these things are important parts of software engineering.
In the very unlikely event that he has some irreplaceable brilliance in areas like algorithms, assign him to work in that area, e.g., defining algorithms, and get a real programmer to do the coding.
Use static analysis code to understand and clean up his code.
Pair programming. Find hima pair that will "complete" him for requirements you just listed. You will solve a problem will source control, documentation, question every his action, etc. You also train other guy by using first guy strength
From what you describe, this fellow is distinctly not a star developer. Programming is a team sport, and those who do not play well with others do not add much value to a project.
Personally, I might not remember code I wrote 6 months or more ago, and very much value a history of the changes in some sort of Source Control.
If you had regular code reviews with this guy I think you would see that he's not as stellar of a developer as you think he is.
I agree with most people on this thread. One way to put him on the hot spot is to have Team Code Reviews.
For the first code review meeting choose code from a team member that is open and will accept the recommendations. The "star" developer will have the chance to see how the code review works and then you can schedule his code to be reviewed next. Give him some time to prepare for the next meeting and by then he should be at least commenting his code.
The intention of code reviews is not to put shame on people but rather to collaboratively identify issues and places for improvement, but it will be a good way to put the star developer on the hot seat.
In my opinion, you need to drop this guy. It sounds like his code is unreadable and he is definitely not a team, nor a safe, player.
It is also a very bad practice to allow someone to see themselves as indispensible. If you let him keep this up, his practices will get worse, not better. When he leaves, for everyone does, you will be left with an enormous headache of tangled code. You need to cut your losses now if he will not shape up.
Finally, keeping this developer without reigning him in sets a poor example from junior developers. If you force them to work correctly, you risk resentment from the "why him and not me" crowd. If you don't, you get a bunch of hacks who work like your "star."
In short, unless he shapes up very, very quickly, it's time to drop him, for the health and sanity of your entire development staff.
We had a similar problem when I started my current job a little over 3 years ago, our lead developer was a cowboy. He was really smart but very erratic, some of his stuff was very well documented, but so overly complicated it was imposable to maintain, or code first and figure out what he was building later, he would throw out code to see what would stick.
He left about 2 1/2 years ago, and it's still haunting us when we find some of his old code, and in his defense that's how the development shop here was run back then, in the last 3 years I have been on a crusade to change that mentality.
When you become a star developer it stops being so much about how well you know the system, code, framework, architecture, etc. and more about
Working with the rest of the team: using source control, leading by example, etc.
Documenting what each method, class, object, etc is doing
Researching new and better ways to do things for yourself, and your team
if your not following all four of these at some level your not a star developer, more so if you refuse to try/learn to use them then it's time that that should find other employment opportunities one way or another, I hear starving artist is popular with this time of person (the whole misunderstand genius thing)
发布评论
评论（30）
在我看来，做你上面描述的愚蠢事情的人不可能成为明星开发人员！ 在我看来，他似乎故意让事情变得更加复杂，这样除了他自己之外没有人可以维护代码。 这让他自己变得比他真正的自己更重要！
跟他说话。 他必须改变！ 如果他不这样做，就用真正的明星开发者取代他！
我向你保证，半年之内他都不会知道自己的代码是如何工作的！ 解雇他，你可以节省大量时间和金钱。
In my opinion somebody doing such stupid things as you have described above can't be a star developer! To me it seems like he intentionally makes things more complicated as they are, so that nobody else than himself can maintain the code. This makes himself more important than he really is!
Talk to him. He has to change it! If he doesn't, replace him with a real star-developer!
I promise you, in even half a year he will not know how his own code works! Fire him and you can save a lot of time and money.
CVS 部分很简单 - 一次“意外”硬盘故障会给他一个终生难忘的教训（但要确保你有备份，这样你就不会真正丢失代码）
The CVS part is easy - an "accidental" hard drive failure will teach him a lesson for a life (make sure you have a backup though so you won't actually lose code)
这听起来是一个艰难的处境。
就我个人而言，我会让他走。 他可能是一名明星开发人员，但他不是一名团队合作者。 如果你想做出好的产品，你需要有一个有凝聚力的团队，可以一起工作。
That sounds like a tough situation.
Personally, I would let him go. He may be a star developer, but he isn't a team player. And you need to have a cohesive team that can work together if you want to make a good product.
不记录是确保工作安全的一种（非常糟糕的）方法。
您可以采取多种措施来解决这个问题：
Failing to document is a (very bad) way to ensure job security.
You can do several things to counter this:
播放您在电影中看到的坏警察/好警察小品。 让管理层当坏警察，你当好警察。 让管理层要求他提供过多的文档和每分钟的 ZIP 备份。 但是你为他提供了适度的文档（例如 doxygen 提供的）和通常的源代码控制检查......
Play the bad cop/good cop sketch you have seen from the movies. Let the management be the bad cop and you be the good cop. Let the managament ask for over-kill documentation and per-minute ZIP backups of his work. But you offer him moderate documentation (by doxygen for example) and usual source control check-ins...
跟他说话？
如果他真的是“明星开发者”，他会注意到你说的话。
这可能不会在一夜之间改变他，但他可能完全没有意识到其他人并不像他那样理解它。
编辑：
现在改变可能有点晚了，但在制定解决方案时需要更多信息。 这里的任何人都不可能仅仅根据这些点就真正建议让这个人走。 如果你在过去的一年里每天都告诉这个人他需要改变或者他离开这里，那么你可以让他走。 然而，我没有看到任何证据。
优秀的开发人员可以学会使用源代码控制、注释和文档。 如果您在这里付出努力，那么您将真正拥有一位明星开发人员。
Talk to him?
If he really is a "star developer" he'll take note of what you say.
It may not change him overnight but it might be that he is just completely unaware that other people dont get it quite like he does.
Edit:
It's probably a bit late to change now, but more information is needed in working out a solution. It's impossible for anyone here to actually suggest letting the guy go based on these points alone. If you've been telling the guy every day for the last year that he needs to change or he's out of here, then you can let him go. However, I see no evidence of that.
A brilliant developer can be taught to use source control, comment and document. If you spend the effort here then you truly will have a star developer.
您可能在这里关注了错误的领域，您有机会看到流程中的一些弱点。
在这里，简单的聊天可能就足够了，版本控制的好处不言而喻，任何“聪明”的人都可能会很热心关于这些好处。 然而，这也可能是研究替代版本控制系统的好机会，这些系统可以提供更大的易用性和灵活性（看看 bzr 和 git）。 更好的是，让他参与选择过程，如果他真的是一个“明星”，他可能会有很好的投入，并且会更倾向于它的使用。
听起来文档不是您流程的一部分。 人们会抵制做额外的工作，如果没有明确的流程，那么你就会谈论大量的额外工作。 真的需要文档吗？ 如果是，是否定义了创建它的流程？ 你应该有一个人完全致力于它吗？ 您至少应该有一个工具来促进它（也许像 mediawiki 这样简单的东西）？
三个词：同行代码审查。 除了明显的错误捕获好处之外，这还可以提供一些同行压力，这是一种强大的力量，并且可能是一件好事。 希望得到同事的认可，就会产生主人翁意识和品质。
再次强调，同行代码审查。 您提到管理层知道该程序员的缺陷。 他有吗？ 如果人们不认识到自己做事方式中存在的问题，那么他们就很难改变和改进。
而且，也许最重要的是，通过提出改进开发流程的计划（这可能不仅会改善您的“明星”，还会改善团队中的其他所有人），您可能可以从管理层那里为自己赢得一些金星。
You might be focusing on the wrong area here, you are being provided with an opportunity to see some weaknesses in your process.
A simple chat will probably suffice here, the benefits of version control speak for themselves and any "bright" person would likely be enthusiastic about those benefits. However it may also be a good chance to look into alternative version control systems that allow greater ease of use and flexibility (take a look at bzr and git). Better yet, get him involved in the selection process, if he really is a "star" he'll probably have good input and be more vested in its use.
It doesn't sound like documentation is part of your process. People are going to resist having to do extra work and if there isn't a defined process then you're talking about a lot of extra work. Is documentation really needed? If so, is there a process defined for creating it? should you have someone entirely dedicated to it? Should you at least have a tool to facilitate it (maybe something as simple as mediawiki)?
Three words: peer code review. Outside of obvious error-catching benefits, this also can provide some peer pressure, which is a strong force and can be a good thing. Wanting to be perceived well by your peers self-generates ownership and quality.
Again, peer code review. You mention that management knows about this programmer's deficiencies. Does he? It's rather difficult for people to change and improve if they don't recognize the problems with the way they're doing things.
And, perhaps best of all, by coming up with plans to improve your development process (which will likely improve not only your "star" but everyone else on the team) you can probably earn some gold stars for yourself from management.
对我来说听起来不太像明星程序员。 所有优秀的程序员都知道代码格式化和源代码管理的使用很重要。 听起来虽然他自己取得了良好的进展，但他阻碍了其他团队成员的进展，这可能会对完成工作产生净负面影响。 和他谈谈，如果他拒绝改变他的做法，就让他走。
Doesn't sound like much of a star programmer to me. All the good programmers know that code formatting and use of source control matters. Sounds like although he makes good progress by himself, he's obstructing the progress of the other team members, which might have a net negative effect on the work getting done. Talk to him, and if he refuses to change his practices, let him go.
如果他真的那么聪明，你无法改变他的方式，也不想失去他，但你仍然希望你的代码被记录和评论，那么我的建议是让经验不足的开发人员为他做记录和评论。
就我个人而言，如果我是一名明星开发人员，如果让其他人评论我的代码，我会觉得很愚蠢，而我最终会开始自己做。 与此同时，虽然这种情况不会发生，但经验不足的开发人员可能会学到一两件事。
If he really is that bright and you cannot change his ways, nor do you want to lose him but you still want your code to be documented and commented then my suggestion would be to let a less experienced developer do the documenting and commenting for him.
Personally if I were a star developer I would feel prettiy foolish if someone else was made to comment my code and I would start to do it myself eventually. In the meantime while that does not happen the less experienced developer may learn a thing or two.
成为明星开发人员不仅仅只是成为一名优秀的程序员。 如果他不具备团队技能并且故意忽视团队标准，则需要向他提出这一问题。 如果他在与管理层交谈后拒绝遵守这些规定，也许他不适合你的公司。
There's more to being a star developer than just being an excellent programmer. If he doesn't have team skills and is purposefully ignoring team standards it needs to be brought up to him. If he refuses to adhere to them after talking with management, perhaps he's not the right fit for your company.
这个问题让我很紧张，因为虽然你所描述的这个人听起来很令人震惊，但我可以在他身上看到一点我自己的影子。
我认为我是一个非常好的团队合作者，而且我很幸运能够加入一支非常好的团队。 然而，我确实使用了同事们不理解的方法，尽管我已经尽力解释它们。 只是存在相当大的经验差距，这对我们任何人来说都没有反映。
文档是一个广泛而棘手的主题。 我尝试遵循 DRY（不要重复自己）的格言。 与代码分离的文档可能相当于重复自己，因此它很可能会过时，除非您放慢速度以使其保持最新状态。 我通常的做法是事后修饰。
通常我正在处理的问题非常棘手，我可以提前计划并记录我想要的一切，但当涉及到代码时，我经常发现我错了，必须重新思考。 因此，在我看来，可以提前记录内容并遵循它的想法只适用于非常简单的问题。
无论如何，我认为这是一个很好的问题，而且答案一点也不简单。
This question makes me nervous, because while the person you're describing sounds egregious, I can see a little bit of myself in him.
I think I'm a pretty good team player, and I'm lucky to be on a very good team. However, I do use methods that my colleagues don't understand, though I've tried pretty hard to explain them. There just is a pretty large experience gap, which is no reflection on any of us.
Documentation is a broad and tricky subject. I try to follow the DRY (don't repeat yourself) maxim. Documentation that is separate from the code can amount to repeating yourself, so it is liable to get out of date unless you slow yourself down to keep it up to date. My usual approach is to touch it up afterward.
Often the problem I'm working on is so tricky that I can advance plan and document all I want, but when it comes to the code I often discover that I was wrong and have to re-think it. So the idea that you can document stuff in advance, and just follow that, only works for pretty straightforward problems, it seems to me.
Anyway, I think this is an excellent question, and the answer is not at all simple.
这家伙真的是摇滚明星吗？ 严重地？ 想一想。 是他很聪明，但没有把事情做好，还是他既聪明又能把事情做好？
想想真的很难。
如果他真的是摇滚明星，那么也许你不应该惹他。 他使用自己的流程生产出令人难以置信的出色产品。 仅仅因为有一种最适合你的不同的做事方式，并不意味着这将使他能够创作出最好的作品。 不要试图让他屈服于你的流程，这很可能会扼杀他所有的魅力，你应该尝试找到一种方法来适应他的工作方式。
如果他真的像你说的那么好，你不应该介意这样做。 如果不值得为此付出努力，那么他真的没那么好。 在这种情况下，你没有一个摇滚明星，你只是一个平庸的程序员，不喜欢遵守规则。 这些家伙，你应该摆脱掉。 不过，脾气暴躁的摇滚明星通常值得承受痛苦，因为他或她能创作出高质量的作品。 那些人，你应该想尽办法去挽留。
Is the guy really a rock star? Seriously? Think about it for a second. Is he smart, but doesn't get things done, or is he both smart and able to get things done?
Think about it really hard.
If he really is a rock star, then maybe you shouldn't mess with him. He's producing incredibly awesome things using his own process. Just because there's a different way of doing things that works best for you, doesn't mean that's going to enable him to produce his best work. Instead of trying to get him to bend to your process, which very well could kill all of his awesomeness, you should try and find a way to accommodate the way he works.
If he really is as good as you say, you shouldn't mind doing that. If it isn't worth the effort to do that, then he really isn't that good. In that case, you don't have a rock star, you just have a mediocre programmer that doesn't like to play be the rules. Those guys, you should just get rid of. A temperamental rock star is usually worth the pain, though, because of the quality of what he or she can produce. Those people, you should go to great lengths to keep.
听起来像是一个明星程序员，他对自己的工作感到厌倦，并且让事情变得过于复杂，使其更具挑战性。 他很快就会找到更好的东西。
Sounds like a star programmer who's bored of his job and is over complicating things to make it more of a challenge. He'll find something better soon enough.
试图改变一些事情？ 您更喜欢哪个，一个文档不完整的工作软件还是一个文档良好的垃圾？ 有些人能够编写几乎不需要注释的软件，这并不是可靠的质量指标。
我担心你会失去一个优秀的开发人员。
Trying to change things? What do you prefer, a poorly documented working piece of software or a well documented junk? Some people is capable of writing software that requires little to no comments, that is not a reliable indicator of quality.
I'm afraid you're going to lose a good developer.
“嗨，明星开发人员，
只是一个非正式的提醒，告诉您从下周开始，我们将要求提供代码文档，并在代码中提供有用的注释 - 这将是公司政策，没有例外“
从那时起，你就可以像处理未能准时上班、未能停止工作中偷懒等问题一样处理失败。最重要的是，如果老板说文件，你就文件或你没有做好你的工作。
"Hi Star Developer,
just a little informal heads-up to tell you that from next week, we'll be requiring documentation of code, and helpful commenting in the code - it's going to be company policy, and there'll be no exceptions"
From then on, you just deal with that failure the same as you would deal with a failure to turn up on time, a failure to stop goofing off during work, etc. Bottom line is if the boss says document, you document or you're not doing your job properly.
如果他这样工作，他就不是明星开发人员——伟大的软件开发人员都明白可维护性极其重要。 从长远来看，你可能会为此付出高昂的代价，我会非常直接地告诉他这件事有多严重，如果他无法开始适应，就让他走。 我以前已经见过很多次了，这是一个定时炸弹。
说实话，我见过很多这样的开发人员，除非他们刚刚走出学校，否则他们不会改变。 我说现在就砍掉你的无损，因为他继续吐出更多难以维护的代码，解雇他只会变得更加困难:)
If he is working like this, he is not a star developer - great software developers understand that maintainability is extremely important. You will probably pay dearly for this in the long run, I would be very direct with him about how serious this is and let him go if he can't start to adjust. I have seen this plenty of times before and it is a ticking time bomb.
To be perfectly honest, I have seen plenty of developers like this and, unless they are just out of school, they won't change. I say cut your lossless now, its only going to get harder to fire him as he continues to spew out more unmaintainable code :)
如果他真的很聪明，管理层不太可能解雇他。
当然，整个项目可能会被关闭，但无论如何，CVS 和文档将没有用处。
没有哪个管理层会解雇一名优秀的程序员而只雇用一名糟糕的程序员。
告诉他，只要他愿意，这将帮助他摆脱管理。
他想换什么工作？ 他可以告诉管理层：“好吧，大家，一切都像你们要求的那样：登记、记录并在你们的控制之下。我完成了我的部分，我收拾行李离开”。
It's very unlikely that management will get rid of him if he is really bright.
The whole project may be closed, of course, but there will be no use in CVS and documentation then, anyway.
No management will fire a good programmer only to hire a bad one.
Tell him that it will help him to get rid of management whenever he wants to.
What is he wants to change job? He can tell management: "OK, people, everything's just like you asked me: checked in, documented and under you control. I'm done with my part, I pack and leave".
如果没有他，球队能取得成功吗？ 如果是这样，请推动该问题并拒绝接受任何未正确记录或不符合其他标准的代码。 希望这能让他明白这一点，但这可能只会让他生气并导致他放弃。 如果球队在没有他的情况下无法取得成功，那么你就运气不好了，除非你能训练出一个达到他技术水平的替代者，而这可能不值得花费时间和精力。
Can the team be successful with out him? If so push the issue and refuse to accept any code that isn’t properly documented or doesn’t meet other standards. Hopefully this will get the point across but it might just make him angry and cause him to quit. If the team can’t be successful with out him then you’re out of luck until you can train a replacement up to his skill level which may not be worth the time and effort.
+1 ocdecio - 如果他是明星开发人员，那么他的代码应该基于如此高质量的设计，并且可以记录自身。
话虽如此，令人沮丧的可能是，尽管他在他感兴趣的技术要求高的领域表现出色，但他并没有在功能交付上搞砸——只有你知道这对你的组织来说是否是一个问题。
拥有一个可用的“大师”绝对是一个救星——或者至少在过去是这样，还是 StackOverflow 已经让这个角色变得多余了？
+1 to ocdecio - if he is a star developer, then his code should be based on such a high-quality design that it documents itself.
Having said that, the frustration could be that although he's excellent in technically-demanding areas which are interesting to him, he doesn't muck-in with the delivery of features - only you will know whether this is a problem for your organisation.
Having a "guru" available can be an absolute life-saver - or at least it used to be, or has StackOverflow made that role redundant?
在通过代码审查之前不要发布代码，并且仅当他为当前功能/项目编写的代码有足够的注释和/或文档时才允许其通过。
编辑在他的评估中提出来。 可以向他提供文档/注释代码以供他“改进的领域”。
:-)
Don't let the code be released until it has passed code review and only allow it to pass if there are enough comments and/or documentation for the code which he has written for the current feature/project.
Edit Bring it up in his appraisal. Documentation / commenting code can be given to him for his "Areas of improvement".
:-)
您还可以添加自动质量检查，以防止他签入代码，直到代码得到充分记录。
前提是你能首先说服他入住！ （这是必要的，我认为）
You could also add automated quality checks that would prevent him checking-in his code until it was sufficiently documented.
That is if you can persuade him to check-in in the first place! (Which is ESSENTIAL, imo)
这里有很多人说“没有评论，那又怎样？” 这里的潮流。 没有注释的文字代码是完全可能的，但是仅仅因为某人很聪明并且不注释并不一定意味着他们正在编写文字代码。
那么让我们澄清一下。 您已经说过他根本不记录他的代码，无论是在注释中还是在单独的文档中，并且他不使用任何源代码控制。 怎么样：
如果所有这些问题的答案都是“否”，那么你就有大问题了。 仅仅聪明并不一定能让某人成为资产。 你能保证他明天不会离开你的公司，也不会被公交车撞到吗？ 如果发生这种事，你会有多糟糕？ 值得冒这个风险吗？
There's a lot of folks here on the "no comments, so what?" bandwagon here. Literate code without comments is perfectly possible, but just because someone is smart and doesn't comment doesn't necessarily mean that they are writing literate code.
So let's clarify. You already said he doesn't document his code at all, either in comments or separate documents, and he doesn't use any source control. How about:
If the answer to all of these questions is "no", you have a big problem. Just being smart doesn't necessarily make someone an asset. Do you have any guarantee that he won't leave your company tomorrow, or get hit by a bus? How screwed would you be if that happened? Is it worth the risk?
我认为这在任何环境中都是非常典型的。 你如何让别人做你想做的事？ 这正是“如何赢得朋友并影响别人”的意义所在。 戴尔·卡内基关心的不是操纵，而是管理人。
在我看来，他只是缺乏经验，需要一些经验和指导。
你认为你可以坐下来和他谈谈这些问题吗？ 告诉某人他们做错了事通常看起来是错误的事情（特别是在当今的西方社会，我们不想伤害别人的感情），但我认为通过冷静和诚实地解释问题和解决问题，你可以走得更远。与他们交谈。 如果这个人尊重你和你的意见，这会有所帮助，这是一个完全不同的问题，并且在上面提到的书中讨论过。 确保他明白这些都是严重的问题。 此外，在未来的任何开发工作中，他也将被期望做这些事情，所以现在就练习它们是个好主意。
我认为等到下一次绩效评估不是一个好主意。 堆积一堆负面反馈并一次性交付只是一个坏主意，我真的不喜欢这样做。
I think this is pretty typical in any environment. How do you get someone to do what you want? This is exactly what "How to win friends and influence people" is all about. Dale Carnegie was not about manipulation, but managing people.
It sounds to me like he's just inexperienced and needs some experience and guidance.
Do you think you can sit down and talk to him about these issues? Telling someone they're doing something wrong often seems like the wrong thing to do (especially in today's western society where we don't want to hurt other people's feelings) but I think you can get very far by calmly and honestly explaining the issues and talking them through. It helps if the person respects you and your opinion, which is a whole other issue and is talked about in the book mentioned above. Make sure he understands that these are serious issues. Also, that in any future development jobs he'll be expected to do these things too so it's a good idea to practice them now.
I don't think waiting until the next performance review is a good idea. Piling up a bunch of negative feedback and delivering it all at once is just a bad idea and I really disliked it when that was done to me.
代码文档被高估了。 CVS 培训很简单。
一个好的类应该通过它的方法和属性来揭示它的用途。
在应用程序外部记录模型也更容易流动和理解。
我会提请他注意，如果你不能解决这个问题，看起来你将失去一位明星开发人员。
编辑：
哎呀 - 使用 CSV 而不是 CVS，对于许多导入，我使用 svn 呵呵。
Code documentation is over-rated. CVS training is easy.
A good class should reveal its purpose through its methods and properties.
Documenting the model outside of the application is also easier to flow and comprehend.
I would bring it to his attention, if you can't get it resolved looks like you will be losing a star developer.
Edit:
Oops - used CSV instead of CVS, to many imports and i use svn heh.
让他使用自动执行验证工具。 （请参阅我的回答“如何向阻碍者提问？ ")
使用静态分析代码来理解和清理他的代码。
Get him to use automated execution-verification tools. (See my answer at "How to ask questions to an obsructionist?")
If he overcomplicates and does not use SCC, he is not an excellent developer -- these things are important parts of software engineering.
In the very unlikely event that he has some irreplaceable brilliance in areas like algorithms, assign him to work in that area, e.g., defining algorithms, and get a real programmer to do the coding.
Use static analysis code to understand and clean up his code.
结对编程。 找到一对能够“完善”他以满足您刚才列出的要求的人。 你将通过源代码控制、文档、质疑他的每一个行为等来解决问题。你还可以利用第一个人的力量来训练其他人
Pair programming. Find hima pair that will "complete" him for requirements you just listed. You will solve a problem will source control, documentation, question every his action, etc. You also train other guy by using first guy strength
根据您的描述，这个人显然不是明星开发人员。 编程是一项团队运动，那些不能与他人合作的人不会为项目增加太多价值。
就我个人而言，我可能不记得 6 个月或更长时间前编写的代码，并且非常重视某种源代码控制中的更改历史记录。
如果您定期与这个人进行代码审查，我想您会发现他并不像您想象的那样是一位出色的开发人员。
From what you describe, this fellow is distinctly not a star developer. Programming is a team sport, and those who do not play well with others do not add much value to a project.
Personally, I might not remember code I wrote 6 months or more ago, and very much value a history of the changes in some sort of Source Control.
If you had regular code reviews with this guy I think you would see that he's not as stellar of a developer as you think he is.
我同意大多数人的观点。 让他成为焦点的一种方法是进行团队代码审查。
对于第一次代码审查会议，请从开放并接受建议的团队成员中选择代码。 “明星”开发人员将有机会了解代码审查的工作原理，然后您可以安排接下来审查他的代码。 给他一些时间准备下一次会议，到那时他至少应该评论他的代码。
代码审查的目的不是要让人们感到羞耻，而是要共同找出问题和需要改进的地方，但这将是让明星开发人员处于困境的好方法。
I agree with most people on this thread. One way to put him on the hot spot is to have Team Code Reviews.
For the first code review meeting choose code from a team member that is open and will accept the recommendations. The "star" developer will have the chance to see how the code review works and then you can schedule his code to be reviewed next. Give him some time to prepare for the next meeting and by then he should be at least commenting his code.
The intention of code reviews is not to put shame on people but rather to collaboratively identify issues and places for improvement, but it will be a good way to put the star developer on the hot seat.
在我看来，你需要放弃这个人。 听起来他的代码不可读，他绝对不是一个团队，也不是一个安全的玩家。
让某人认为自己是不可或缺的也是一种非常糟糕的做法。 如果你让他继续这样，他的练习会变得更糟，而不是更好。 当他离开时，就像每个人都会离开的那样，你将会因混乱的代码而感到非常头疼。 如果他不恢复正常，你现在就需要减少损失。
最后，保留这位开发人员而不控制他，给初级开发人员树立了一个不好的榜样。 如果你强迫它们正确工作，你可能会遭到“为什么是他而不是我”人群的不满。 如果你不这样做，你就会遇到一群像你的“明星”一样工作的黑客。
简而言之，除非他恢复得非常非常快，否则是时候放弃他了，为了整个开发人员的健康和理智。
In my opinion, you need to drop this guy. It sounds like his code is unreadable and he is definitely not a team, nor a safe, player.
It is also a very bad practice to allow someone to see themselves as indispensible. If you let him keep this up, his practices will get worse, not better. When he leaves, for everyone does, you will be left with an enormous headache of tangled code. You need to cut your losses now if he will not shape up.
Finally, keeping this developer without reigning him in sets a poor example from junior developers. If you force them to work correctly, you risk resentment from the "why him and not me" crowd. If you don't, you get a bunch of hacks who work like your "star."
In short, unless he shapes up very, very quickly, it's time to drop him, for the health and sanity of your entire development staff.
三年多前，当我开始现在的工作时，我们也遇到了类似的问题，我们的首席开发人员是一名牛仔。 他真的很聪明，但很不稳定，他的一些东西有很好的文档记录，但过于复杂，无法维护，或者先编码，然后再弄清楚他要构建什么，他会扔掉代码，看看哪些可以坚持下去。
他大约 2 1/2 年前离开了，当我们发现他的一些旧代码时，它仍然困扰着我们，在他的辩护中，这就是这里的开发商店当时的运作方式，在过去的 3 年里，我一直在进行十字军东征来改变这种心态。
当你成为明星开发人员时，你不再关心你对系统、代码、框架、架构等的了解程度，而是更多地关注
如果你在某种程度上没有遵循所有这四个方法，你就不是明星开发人员，更重要的是，如果你拒绝尝试/学习使用它们，那么是时候以某种方式找到其他就业机会了，我听说饥饿的艺术家很受这个时代的人的欢迎（整个误解天才的事情）
We had a similar problem when I started my current job a little over 3 years ago, our lead developer was a cowboy. He was really smart but very erratic, some of his stuff was very well documented, but so overly complicated it was imposable to maintain, or code first and figure out what he was building later, he would throw out code to see what would stick.
He left about 2 1/2 years ago, and it's still haunting us when we find some of his old code, and in his defense that's how the development shop here was run back then, in the last 3 years I have been on a crusade to change that mentality.
When you become a star developer it stops being so much about how well you know the system, code, framework, architecture, etc. and more about
if your not following all four of these at some level your not a star developer, more so if you refuse to try/learn to use them then it's time that that should find other employment opportunities one way or another, I hear starving artist is popular with this time of person (the whole misunderstand genius thing)