Sign up ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

Until recently, I was the sole developer on several in-house projects. A few months ago, we added 0.4 of an FTE to our development team. It's nice not being alone on our projects, but it hasn't been easy.

A bit of background: when I started in my position, there was no use of source control, issue tracking, or even testing. I implemented all of these practices myself, and the improvement in productivity has been noticed by multiple stakeholders.

Our new 0.4FTE is basically 40% of the time of an employee in another department. He's a competent programmer, but collaboration has been difficult.

Several months in, I'm still experiencing:

  • Emailed source files rather than repositories being checked in to Git.
  • Use of email and instant messaging instead of the issue tracker to discuss the project.
  • Resistance to code reviews.
  • Ego getting in the way of pair programming or early collaboration on components (i.e., I don't want to show you the source for this yet, it's ugly).

Our department is weird. Our team lead has to divide his time between project management, system administration, and hardware installs/support. We got into probably the worst argument we've ever had over how I expected to interact with another developer vs. "This is just how he is, you need to email in addition to submitting an issue, etc."

My question is, how do you deal with this?

I've tried various approaches; refusing to acknowledge issues without a ticket, refusing to look at code not checked in to our Git repo, but ultimately, I'm the de facto lead developer on this project, and like it or not, I shoot myself in the foot by being a stickler for process. At the same time, I'm driving myself crazy (to the point of looking for a new job) in the process of trying to deal with the lack of coherent (or at least, enforceable) guidelines.

I've brought up the notion with colleagues outside our department that maybe it's just a bad fit, but sadly, we don't have much of an option at this point. Any ideas for ameliorating this situation would be greatly appreciated.

share|improve this question

closed as primarily opinion-based by enderland, Ixrec, Snowman, MichaelT, durron597 Sep 2 at 4:18

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.If this question can be reworded to fit the rules in the help center, please edit the question.

"improvement in productivity has been noticed by multiple stakeholders." Apparently not. – JeffO Mar 14 '12 at 0:41
@JeffO It has... it has not been directly attributed to adopting solid practices. They just assume I'm a wizard. I'm not. – Jason Lewis Mar 14 '12 at 0:56

1 Answer 1

up vote 5 down vote accepted

I see you've tried various approaches, that you've talked with other colleagues and with your boss but I don't see that you've ever sat down with the other developer to have a conversation about how the two of you can work together more effectively. Have you done that? If so, what were the objections raised to things like using source control?

Realistically, the answer is probably some sort of compromise between the two of you. There are elements of the process that clearly result in improved productivity and that are likely very easy to justify. For example, if your build process is based on checking code out from the repository then someone has to check the files in. It's not terribly hard to explain that having you spending time figuring out what changes another developer wrote need to be checked in is not a productive use of time. On the other hand, there are probably elements of the process that simply aren't a great fit. For example, it seems perfectly reasonable to want to discuss the project in email or over IM rather than using an issue tracking tool for that. Someone may need to upload the gist of the conversation to the issue tracking tool depending on what is discovered in the course of having the conversation. Otherwise, the issue tracking tool would seem to get overloaded with back-and-forth conversations that obscure where important decisions are being made and what bits reflect misunderstandings of the issue. And items like code reviews and pair programming are, presumably, things that you're trying to introduce now if you were previously the only developer on the project.

Are the tools and processes that you're using something that is used across the company? Or is it just being used for your project? If you put yourself in the new developer's shoes, is he being asked to work one way with you and a completely different way on the other projects that he's involved with? If so, that could certainly cause him frustration. If the other projects use a different source control tool (or no source control), perhaps you could offer to help him get his environment set up or do a quick overview on the source control tool and how that feeds into the build process. If the other projects do code reviews poorly, perhaps you two can have a conversation about how you'd like code reviews to happen in a way that makes both of you if not happy than at least comfortable.

share|improve this answer
Really good suggestions. Part of the issue is that nothing is standardized across the organization. IT here is very decentralized, very insular on a departmental level. I think ultimately it is going to come down to the new developer and I coming up with a process together, since management doesn't seem to want to be involved. Sadly, there isn't 'time' to hash out process during working hours, so maybe we'll just have to have extra dev meetings after work... at the pub. Thanks. – Jason Lewis Mar 14 '12 at 5:50

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