What to do with star developers who do not document their work?

Question

There is a colleague who knows his things seriously, he is one of the most striking that I have ever worked with, but he:

• works in its own small area of ​​its home directory, and not in the general CVS repository
• don't document his code
• no comment on his code, for example. 3,500 SLOC C with no comments and no empty lines to break things.
• often exaggerating everything, for example. uses three shell scripts that call each other to do the work that one simple shell script can do.

Perhaps this is perhaps one of those people who think: "If I am the only person who knows this, they cannot get rid of me"?

Any suggestions on what to do?

BTW Management is aware of the situation and is trying to make a difference.

Answer 1

In my opinion, someone who does such stupid things as you described above cannot be a star developer! It seems to me that he intentionally makes things more complicated as they are, so that no one except him can support the code. This makes him more important than he really is! Talk to him. He must change that! If he doesn’t, replace him with a real star developer!

I promise that even after six months he will not know how his own code works! Fire it and you can save a lot of time and money.

Answer 2

Part of CVS is simple - a “random” hard drive crash will teach it a lesson for life (make sure you have a backup, so you won’t actually lose the code)

Answer 3

It sounds like a difficult situation.

Personally, I let him go. He may be a star developer, but he is not a player on the team. And you need to have a close-knit team that can work together if you want to make a good product.

Answer 4

Impossibility of a document is a (very bad) way to ensure security.

You can take several actions to meet this:

• Add documentation as a requirement for a personal performance review.
• Do not accept software that is not documented.
• talk with the developer and find out why he is not documenting.
• Buy a cool documentation tool.

Answer 5

Reproduce the bad cop / good cop sketch you saw from the movies. Let management be a bad cop and you be a good cop. Allow management to request excess killing documentation and instant zip backups of its operation. But you offer him moderate documentation (e.g. using doxygen) and regular version control checks ...

Answer 6

Talk to him?

If he is truly a “star developer,” he will take note of what you say.

Perhaps he will not change him in one night, but it may be that he simply does not realize at all that other people do not receive him at all like him.

---

Edit:

It's probably a little late to change, but more information is needed to develop a solution. It is impossible for any of us to actually offer the guy to go on the basis of these issues. If you told the guy every day for the last year that he needs to change, or he left here, you can let him go. However, I do not see any evidence of this.

You can teach a brilliant developer how to use source control, comment, and document. If you make the effort here, then you really will have a star developer.

Answer 7

I don't like most of the star programmer. All good programmers know that formatting code and using version control issues. It seems that although he himself is moving forward, he impedes the progress of other team members, which may have a negative effect on the work. Talk to him, and if he refuses to change his practice, let him go.

Answer 8

You can focus on the wrong place here, you are given the opportunity to see some flaws in your process.

• It works in its small area of ​​its home directory, and not in the general CVS repository.

A simple chat is likely to be enough here, the benefits of version control speak for themselves, and any “bright” person is likely to be delighted with these benefits. However, this may also be a good chance to look at alternative version control systems that provide greater ease of use and flexibility (look at bzr and git). It is even better to involve him in the selection process, if he is really a “star”, he will probably have a good contribution and hope more for its use.

• does not document its code

The documentation does not seem to be part of your process. People will resist doing extra work, and if there is no specific process, then you are talking about a lot of extra work. Is documentation necessary? If so, is there a process to create it? if you have someone entirely dedicated to this? If you have at least a tool to make it easier (maybe something as simple as a mediawiki)?

• does not comment on its code, for example. 3500 SLOC of C with no comments and no empty lines to wrap things around.

Three words: view peer code. Besides the obvious benefits of failure, it can also exert some peer pressure, which is a strong force and can be good. Desiring that your colleagues are well received by your peers, spontaneously generates ownership and quality.

• often exaggerating everything, for example. uses three shell scripts that call each other to do the work that one simple shell script can do.

Again, peer code viewing. You mentioned that management knows about this flaw in the programmer. Is he? It is quite difficult for people to change and improve if they do not recognize problems with the way they do things.

And perhaps best of all, having come up with plans to improve your development process (which is likely to improve not only your “star”, but everyone else in the team), you can probably earn gold stars for yourself from the leadership.

Answer 9

There is more to be a star developer than just a great programmer. If he does not have team skills and purposefully ignores team standards, he should be brought to his attention. If he refuses to join them after talking with management, he may not be suitable for your company.

Answer 10

If it is really so bright and you can’t change its methods and you don’t want to lose it, but you still want your code to be documented and commented on, my suggestion was to allow a less experienced developer to document and comment for him. Personally, if I were a star developer, I would feel stupid happy if someone else commented on my code, and I would start to do it myself in the end. Meanwhile, while this does not happen, a less experienced developer can learn something.

Answer 11

This question makes me nervous, because while the person you describe sounds egregious, I see a little of myself in it.

I think that I am a very good team player and I was lucky to be in a good team. Nevertheless, I use methods that my colleagues do not understand, although I tried very hard to explain them. There is simply a rather large gap of experience that is not reflected to anyone.

Documentation is a broad and complex issue. I try to follow the DRY (not repeat) maxim. Documentation that is separate from the code can mean repeating itself, so it can become obsolete if you don't slow it down to keep it up to date. My usual approach is to touch it later.

Often the problem I'm working on is so complex that I can promote the plan and document everything I want, but when it comes to the code, I often find that I was wrong and should rethink it. So, the idea that you can document the material in advance, and just follow this, it seems to me, works only for fairly simple problems.

In any case, I think this is a great question, and the answer is far from simple.

Answer 12

Is the guy a rock star? Jokes aside? Think about it for a second. Is he smart but doesn't do anything, or is he smart and able to do something?

Think about it very hard.

If he is really a rock star, then maybe you should not bother with him. He produces incredibly amazing things using his own process. Just because there is another way to do what works best for you does not mean that it will allow him to do his best work. Instead of trying to make him lean toward your process, which can very well kill all his awesomeness, you should try to find a way to adapt to how it works.

If he is really as good as you say, you should not mind it. If it’s not worth it, then he really isn’t that good. In this case, you do not have a rock star, you just have a mediocre programmer who does not like to play the rules. Those guys, you should just get rid. A temperate rock star is usually worth the pain, although because of the quality of what he or she can produce. These people, you have to go to great lengths to save.

Answer 13

It sounds like a star programmer who gets bored with his work and complicates the situation too much to make it more difficult. He will soon find something better.

Answer 14

Trying to make a difference? Which do you prefer, a poorly documented working software suite or well-documented trash? Some people are able to write software that requires few comments, which is not a reliable indicator of quality.

I am afraid that you will lose a good developer.

Answer 15

"Welcome developer,

a little unofficial heads-up to tell you that from next week we will need documentation on the code and a useful comment in the code - this will be the company's policy, and there will be no exceptions "

From this moment on, you simply cope with this failure in the same way as with the fact that you do not have time in time, you cannot stop working during work, etc. Bottom line: if the boss says the document, you are documenting or you are not doing your job properly.

Answer 16

If it works like this, it is not a star developer - excellent software developers understand that maintainability is extremely important. You will probably pay dearly for this in the long run, I would be very frank with him about how serious this is, and let him go if he cannot adapt. I have seen this many times before, and this is a ticking time bomb.

To be completely honest, I have seen developers like this, and if they are simply not at school, they will not change. I will say that now I am reducing your losses without losses, but there will only be more to fire him, as he continues to spew more insecure code :)

Answer 17

It is highly unlikely that management will get rid of it if it is truly vibrant.

The entire project may be closed, of course, but there will be no use in CVS and documentation. Anyway.

No management can start a good programmer just to hire a bad one.

Tell him that he will help him get rid of control whenever he wants.

What does he want to change? He can say to the management: “Well, people, everything is the same as you asked me: registered, documented and under your control. I committed suicide, I pack and leave.”

Answer 18

Code documentation is out of date. CVS training is very simple.

A good class should reveal its purpose with the help of its methods and properties.

Documenting the model outside the application is also easier to flow and understand.

I would bring it to his attention, if you cannot solve the problem, it looks like you will lose the star developer.

Edit: Oops - CSV is used instead of CVS, for many imports, and I use svn heh.

Answer 19

Can a team be successful with it? If this pushes the problem and refuses to accept any code that is not properly documented or does not meet other standards. Hope this makes sense, but it can just make him angry and make him leave. If the team does not succeed, then you are out of luck until you can train the replacement to the level of your skill, which may not be worth the time and effort.

Answer 20

+1 to ocdecio - if he is a star developer, then his code should be based on such a high-quality design that he documents.

Having said that, disappointment may consist in the fact that although he is well versed in technically complex areas that are of interest to him, he is not satisfied with the delivery of functions - only you will find out if this is a problem for your organization.

Having an affordable “guru” could be an absolute rescue ability - or at least it was before, or did StackOverflow make this role redundant?

Answer 21

Do not let the code release until it passes the code check and allows it to be skipped if there are enough comments and / or documentation for the code that he wrote for the current function / project.

Edit Summarize your assessment. A documentation / comment code can be provided to him for his “Areas of Improvement”.

:-)

Answer 22

You can also add automatic quality checks that would prevent him from checking his code until it is sufficiently documented.

That is, if you can convince him to register first! (What is BASIC, imo)

Answer 23

There are a lot of people here, on "no comment, so what?" the bandwagon is here. A competent code without comments is quite possible, but just because someone is smart and does not comment does not necessarily mean that they write a competent code.

So let's clarify. You already said that he does not document his code at all, either in comments or in separate documents, and he does not use any source control. What about:

• Is his code clear despite the lack of comments?
• Does your team use any kind of problem tracking (e.g. FogBugz, Bugzilla, etc.) in which it participates?
• Is his code checked?
• Is there anyone else on the team who is actually at least a little familiar with how his code works?
• Is he at least ready to admit that he can make some changes to the way he works with the rest of the team?

If the answer to all these questions is no, you have a big problem. Just the skill does not necessarily make someone an asset. Do you have a guarantee that he will not leave your company tomorrow or get on the bus? How would you be if this happened? Is it worth the risk?

Answer 24

I think this is pretty typical in any environment. How do you make someone do what you want? This is exactly what "How to make friends and influence people." Dale Carnegie was not about manipulation, but controlled people.

It seems to me that he is simply inexperienced and needs some experience and guidance.

Do you think you can sit down and talk to him about these issues? To tell someone that they are doing something wrong often seems wrong (especially in modern Western society, where we don’t want to harm other people's feelings), but I think that you can very far, calmly and honestly explain the problems and talk with them. This helps if the person respects you and your opinion, which is a completely different problem, as mentioned in the book mentioned above. Make sure he understands that these are serious problems. In addition, he will have to do this in any future development tasks, so it’s good to practice them now.

I don't think until the next performance review is a good idea. Piling up a bunch of negative feedback and delivering it right away is just a bad idea, and I really didn't like it when it was done for me.

Answer 25

You cannot kill people for not doing what you suggested there. He is just different.

if(developer.IsHuman()) { developer.IsUnique = true; } 

I work with people who write garbage (and call it code). I do it too. Sometimes. But, as you already feel, it annoys him not to change bad habits when you know that your work affects others. Try to convince him more.

And I don’t think that you can do much in this situation if you are not a “ Manager ”.

Answer 26

• Ask him to use automated execution verification tools. (See My answer to How to ask an obstructionist questions? ")

• If he overly complicates and does not use SCC, he is not a great developer - these things are important parts of software development.

• In the very unlikely event that it has an irreplaceable brilliance in areas such as algorithms, assign it to work in this area, for example, to determine algorithms and get a real programmer for coding.

  / li>

• Use static analysis code to understand and clear its code.

Answer 27

Programming pairs. Find his pair that will “fill” him for the requirements you have just indicated. You will solve the problem, will control the source, documentation, ask questions to each of his actions, etc. You also train another guy using the guy’s first strength.

Answer 28

From what you describe, this guy is clearly not a star developer. Programming is a team sport, and those who do not play well with others do not attach much importance to the project.

Personally, I might not remember the code that I wrote 6 months or more ago, and really appreciate the history of changes in some source of version control.

If you had regular code reviews with this guy, I think you will see that he is not such a star developer as you think.

Answer 29

I agree with most people on this topic. One way to put it on a hot spot is to have team code reviews.

For the first code verification session, select a code from a team member who is open and will accept recommendations. The star developer will have the opportunity to see how the code review works, and then you can schedule it to be reviewed again. Give him some time to prepare for the next meeting, and by then he should at least comment on his code.

The goal of code reviews is not to disgrace people, but rather to jointly identify problems and places for improvement, but this will be a good way to put a star developer in a hot place.

Answer 30

In my opinion, you need to give up this guy. It seems his code is not readable, and he is definitely not a team, not a safe player.

It is also a very bad practice, allowing someone to see themselves as indispensable. If you let him handle it, his practice will get worse, not better. When he leaves, for all this you will have a huge headache of confusing code. Now you need to reduce your losses if it does not change.

Finally, keeping this developer, without misleading him, creates a bad example from junior developers. If you make them work correctly, you risk resentment from the crowd "why he, not me." If you do not, you will get a bunch of hacks that work like your "star".

In short, if he will not be very fast, very fast, then it is time to drop him, for the health and sanity of all your development officer.