Ask HN: working with a "bad" programmer
11 comments
It depends on whether he's bad and doesn't think he's bad or he's bad and he doesn't know he's bad.
If it's the former, he could literally kill the startup.
If it's the latter, I can honestly say I have only met a few programmers who were incapable of learning good coding practices.
If it's the former, he could literally kill the startup.
If it's the latter, I can honestly say I have only met a few programmers who were incapable of learning good coding practices.
Code reviews and distributed pair programming (for Eclipse we use Saros plugin).
You haven't provided enough information to provide any useful advice. Care to elaborate?
One of the ways that control/power issues first manifest are complaints about style. We need specific examples to tell if there is a legitimate problem.
Can you gauge how cooperative the other programmer will be in having a discussion about best practices? Hopefully he/she is at least decent with versioning. How about testing? Do you think the other programmer would be open to doing TDD? I know TDD isn't everyone's cup of tea, but it's certainly easier to get into than it is to teach someone how to write comments or change their style of coding.
Be straight with him. That you both need to work on your communication back and forth and you'd like it if he could use more comments in his code. Tell him the time writing a comment saves you ten-fold on stopping to 'follow the program'. Ask him if he's been having trouble with any of your comments. (Communication takes two people, errors happen between BOTH people.)
Coding practices, try and work on him with it...don't be direct but use a 'hey, I know a way you might like to do this instead, let me show you' type approach. It will take a lot of time to break bad-habits. I started programming not using Camel notation, instead preferring title case...I still prefer Title Case after years of trying to break myself :)
Coding practices, try and work on him with it...don't be direct but use a 'hey, I know a way you might like to do this instead, let me show you' type approach. It will take a lot of time to break bad-habits. I started programming not using Camel notation, instead preferring title case...I still prefer Title Case after years of trying to break myself :)
If you don't have a problem getting work, then just leave and look for the next gig. Finding the right fit can be difficult, luckily these days developers have lots of choices.
Mentor him. "In this section of code, you can do this and it looks cleaner." It sounds like most of the problem is that he is short on experience and does not know how to be a good programmer, so be the best example of a good programmer and teammate that you can. Teach him a few things and he might look up to you and start picking up your habits.
Make sure he knows how to debug so that you can tell him about a bug in his software and he can fix it so you don't have to.
Make sure he knows how to debug so that you can tell him about a bug in his software and he can fix it so you don't have to.
From my experience, there are two types of "bad" programmers: Those that want to improve and work with you, and those that don't, or at least not take advice from you.
For the first category, as others have said, you should try to mentor them.
For the second category, this was tough in my experience. I did my best trying to work on my communication, being friendly, but the other programmer just ignored it. After I gave it some time, I wrote the business guys (some have a technical background though) what problems I had with the other programmer. If you keep it high-level and that it is mainly the communication that doesn't work, they should get it.
From then on, it's really their job to fix the problem. In my case, it was handled pretty good. I didn't become best friends with the other programmer, but it was workable. If your management can't fix the problem (final escalation: firing the other guy), you should quit. This will not be the last time such problems will pop up in the company (be it engineering or another part) and good management is able to handle that.
For the first category, as others have said, you should try to mentor them.
For the second category, this was tough in my experience. I did my best trying to work on my communication, being friendly, but the other programmer just ignored it. After I gave it some time, I wrote the business guys (some have a technical background though) what problems I had with the other programmer. If you keep it high-level and that it is mainly the communication that doesn't work, they should get it.
From then on, it's really their job to fix the problem. In my case, it was handled pretty good. I didn't become best friends with the other programmer, but it was workable. If your management can't fix the problem (final escalation: firing the other guy), you should quit. This will not be the last time such problems will pop up in the company (be it engineering or another part) and good management is able to handle that.
The first question is, since you are not a founder how are you being compensated?
The next is, does the code quality really effect your compensation over the long term?
Finally, productivity is not lines of code, but revenue and users. Good coding practice may make a slight difference in the success of a startup, but odds are it won't.
The key is determining if the likely pain is worth the potential outsized rewards. If the rewards are not potentially outsized, then it's not really a startup.
Good luck
The next is, does the code quality really effect your compensation over the long term?
Finally, productivity is not lines of code, but revenue and users. Good coding practice may make a slight difference in the success of a startup, but odds are it won't.
The key is determining if the likely pain is worth the potential outsized rewards. If the rewards are not potentially outsized, then it's not really a startup.
Good luck
Daily code reviews worked for me. My colleague wasn't "bad" and I'm not great, but we had very different approaches to writing code that made collaboration difficult. Daily code reviews helped us get on the same page on a lot of things and also allowed me to casually introduce new programming concepts or provide feedback on questionable programming practices.
The problem is that the other programmer have bad communication(we both work at home) and programming practices: a lot of files without comments, hard to understand/read code, buggy code, un-pythonic code... It's getting difficult to be productive in this environment.
What would you do in this situation?