Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I work in a team of 2 developers, my partner is the founder of the company, in the beginning he did everything on his own. He hired me about 3 years ago to help him get things done quicker and satisfy our customer needs.

Often I get small project to do all by my own, as long as it works great (and it usually does...) he doesn't care much on what I did or how I did it.

But if the customer calls him up asking why something doesn't work as expected and I'm not around to forward the call to me, he could get very angry on why he doesn't have an idea on how that program works.

I don't keep anything as a secret, if he asks me on something how I did it I'm happy to explain as long as he's willing to listen (which isn't long), but I don't know why I need to say it in first place, in developing software everything is written down clearly.

Most of the time I work on projects he wrote and I don't need to ask him anything (it happens maybe once a month that I ask him how something works, just because I don't have the time to look it up).

I've read a lot on that great site about small teams that usually means 7-12 people. I couldn't find how 2 people work as a team; we don't have project managers, reviewers or testers.

I feel that the fact he don't have time to review the code on his own is not my problem, so the question here is am I doing something wrong? Do I need to walk over to him and give him a lecture on what I did even he doesn't ask me?

share|improve this question
Do you use source control? If so, do you care for putting useful comments into the changelog? That might help him to some degree when you are not available and he wants to know which part of the code you have changed lately, and why. –  Doc Brown Nov 29 '12 at 11:43
I tried to work with source control but it went off very fast. the reason was my partner didn't commit to often (could be 'weeks' without commits, so when he does there was naturally so many conflicts that break everything... in other words; the source control is in place but doesn't do any good for us. –  Ezi Nov 29 '12 at 16:21
Honestly, I get the impression there is something seriously wrong in your team. Getting that many conflicts means the two of you had both worked on the same program for weeks without aligning your work in between, and then you blamed source control for what you really have - a communication problem. Do you really believe that merging your different work gets easier in such a situation without source control? You have to learn to talk with each other. Daily! Now! No excuses. And if you can't, you should seriously think about looking for a different job. –  Doc Brown Nov 29 '12 at 16:34

2 Answers 2

up vote 4 down vote accepted

am I doing something wrong?


You can improve the situation by figuring out why is it that he is not happy sometimes. You understand that he feels that the software is "his baby" and he feels upset not to be able to figure it out anymore, may be because of the changes or because his lack of time. Anyway, all parties here mean well. What you could do is:

0- Be more accessible, by mobile, or by other means.

1- Provide a well organized summary of changes with some explanation that he could quickly reach and see. This may be able to help him answer questions about changes.

2- Record some demos that he can watch when he has time, in fact, you may be able to provide the same demos to your end customer showing new features or changed functionality.

3- Explain that you are willing to improve the situation and brainstorm some ideas with him with the purpose of making him more comfortable with the customer support issue. Be clear that you are willing to change the process to a better one.

Main thing, keep the communication lines open between you and him. Don't think of who is wrong and who is right, think of who to enhance the current situation.

share|improve this answer
You can also add a wiki or a shared document, where-in all the requirements with the execution details are explained. You can document it as and when things change and then it would be your partners responsiblity to read the wiki/document. –  eminemence Nov 29 '12 at 6:35
All these things sound like alot of work. It would probably be best to discuss all those options with the boss first to check he is happy they are done on work time?? –  dreza Nov 29 '12 at 7:48
I would only do number 3 and document the classes (their purpose and how they fit together with all other classes, i.e. when are they used and by what). Methods are usually not a problem. –  jgauffin Nov 29 '12 at 8:00
I agree with @eminemence and dreza. –  Emmad Kareem Nov 29 '12 at 9:37
@jgauffin, diagrams may be good for development level, in this case, I think the problem is in working with the system and knowing how certain functions work or why they don't work, so class diagram will not tell you that. –  Emmad Kareem Nov 29 '12 at 9:39

I had similar issues when I was working at a startup before, after I've joined to one of those enterprise companies, I found out how a start up working process could be go wrong if people don't pay attention to it, anyway after dealing with an enterprise project, where you have engaging with large number of targets and code lines I can suggest following to you.

  1. You need coding standard, so both of you follow that, for example naming conversion, or how you arrange your code( putting bizz logic into specific target and separated it from your interfaces). So later on if something happen on interface of page 'X' you know where you must look for it (of course it also depends on on arch of your software)

  2. Another useful practice that you can establish is code review on each other code (I know it could be time consuming but it is really helpful). So after while you as team, became familiar on each other coding style. beside that by comments and suggestions on each other code you can increase your code quality.

  3. You mentioned that you don't have any tester in your team. In my opinion it just naturally increase risk of appearing bugs in your software. As Programmer beside your functional test that you do after finishing piece of code, you can also establish unit testing so it increase the quality of your software.

At the end sometimes it is just personality and attitude of people that makes it hard to working with them and not the technique or process of your work.

share|improve this answer
Thanks for sharing your experience. I like your last paragraph the most... –  Ezi Nov 29 '12 at 16:17

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.