

Ask HN: working with a "bad" programmer - mxmpawn

I'm working at a startup with another programmer, the founders are business guys and they don't even look at the code.<p>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.<p>What would you do in this situation?
======
KevinEldon
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.

------
RollAHardSix
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 :)

------
CookWithMe
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.

------
brudgers
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

------
debacle
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.

------
gexla
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.

------
pepsi_can
You haven't provided enough information to provide any useful advice. Care to
elaborate?

~~~
codeonfire
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.

------
shortlived
Code reviews and distributed pair programming (for Eclipse we use Saros
plugin).

------
danso
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.

------
danso
What's the question?

~~~
mxmpawn
I'm sorry, I had a problem with the submission.

------
Tangaroa
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.

