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'm taking a class where I work with a partner to implement the link layer of the OSI model.

I've worked programmed with a partner once before and it went bad. Is the goal to divide the work up and decides who does what or should one person code and the other person reviews and switch roles after a while?

Any tips are much appreciated. Literally I know nothing about working with a partner to program so even if it's basic please tell me.

share|improve this question

closed as not a real question by gnat, Joris Timmermans, Yusubov, Walter, TMN Oct 15 '12 at 13:46

It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.If this question can be reworded to fit the rules in the help center, please edit the question.

    
The only goal is to complete the project. All that matters at the end of the day is if the project is completed. –  Ramhound Oct 15 '12 at 16:34

4 Answers 4

Is the goal to divide the work up and decides who does what or should one person code and the other person reviews and switch roles after a while?

Unless your instructor explicitly told you how to share the task, it is up to you and your partner to decide. So I would start by discussing this with him/her. This includes a rough assessment of your qualities and skills - nothing bad, just to see whether you are more or less on the same level, or one of you is more skilled / experienced in some aspect of the work. This quite strongly influences your options.

If the two of you are on about the same level, probably the best is to attempt to solve at least the most fundamental tasks - fleshing out a rough design and implementing a skeleton application in code - together.* You don't need to make a shiny perfect design up front - it takes a lot of experience to succeed with this. It is better to just try to come up with ideas, discuss how the program could work the way it is expected, and if in doubt, write code to verify your ideas. The outcome of this is a skeleton, containing all the main parts of the program and capable of some very simple functionality to demonstrate that the system is working end to end. E.g. the skeleton of a word processor would be able to open a very simple file, display it in an editor window, then save it. A skeleton web server would be able to respond to the most basic HTTP GET request by sending back a "200 OK" response with some hard-coded content. Etc etc.

Once you are ready with this, you may start dividing up tasks between the two of you if you prefer so. In fact, the second main aim of creating the skeleton is to allow multiple people to work on the code in parallel. Which implies that putting everything into a single source code file is not the best idea here ;-)

One (possibly obvious) note: if you haven't used a version control system before, now is the time to start using one.

If, OTOH, one of you is noticeably more skilled / interested in some area, it may be obvious to give related task to him/her. The other may want to watch and follow though, or to get a presentation afterwards, to learn that skill too. At a later point in time, when both of you already are familiar with the basics of teamwork and solving problems, you may choose to do the opposite, letting the lesser skilled one to do a specific task in order to even out your skillset.

*Side note: This process may or may not include pair programming. If both of you are open to the idea of pair programming, why not give it a try. However, make sure that you are really working together, with both of you participating and switching roles frequently. If one of you is dominating and the other is just trying to stay awake, this does not help either of you, and just gives a bad experience.

So if you don't like the idea of pair programming, and/or you have some bad experience (as you seem to have mentioned in your post), and/or you feel it would be one thing too much to learn at this point, you may leave it off. Still you need lots of cooperation between the two of you, so make sure you meet, discuss and share your results with each other frequently.

share|improve this answer
    
+1 for version control. Back in my college days on a group project I introduced RCS to the group (working from a shared folder). That saved significant time avoiding overwriting implemented code with a stubbed version and recovering from alcohol influenced bug introductions. –  MichaelT Oct 15 '12 at 14:13

Jean-Paul Sartre in his play No Exit, famously said, "Hell is other people." Of course, for everyone on this planet, except you, you are other people, so there is a lot to work on.

Team projects in school and in the work place can be filled with challenges. There are some helpful tools you can use:

  • Start early.
  • Create some goals for yourself about what you would like to learn and do on the project.
  • Spend more time that you expect selecting partners.
  • Keep your team small.
  • Understand your differences.
  • Seek out people with complementary strengths, contrasting ideas, diverse backgrounds.
  • Understand and manage group dynamics.
  • Understand communication and thinking styles (external - talk it through, internal - plan it out, write it down).
  • Pick someone who is equally serious about the class or project as you.
  • Work with people who have a compatible schedule.
  • Create a shared understanding of what the professor (or manager or scrum master) expects.
  • Communicate frequently.
  • Try to make things an equal partnership.
  • Don't quibble about who is working or accomplishing more.
  • Be attentive and accommodating.
  • Show appreciation early and often.
  • Be happy and positive about working together even if problems arise.
  • Expect to have tough days, so use easy days to build working relationships.
  • Bite your tongue if you are tempted to say things like "I hate you, I would never work with you again" because after that happens, everything will get harder and you won't have the career long friend that you should make in college. Our business is not so large we won't make or accept job applications to/from that person later, particularly since the advent of Linked In.
  • If your partner is stuck, provide help.
  • If you are stuck, ask for help.
  • Use collaboration tools.
  • Be as aware as possible of the work others are doing. Your interest is motivating to the other person.
  • Peer review each others work. Recommend, but steer clear of criticism that is personal, permanent, or pervasive ("you always screw up everything" is not helpful).
  • Understand what constitutes plagiarism and take steps to insure that your work and the work of other members of your team is original and properly attributes the work of others.
  • Enjoy the work.
  • Understand what worked and what didn't.
  • Share the credit for the success, but don't recriminate if things didn't meet expectations.
share|improve this answer
    
+1 This is a good list - equally appropriate in school teams as in real-world development environments. –  Crollster Oct 15 '12 at 8:38
    
"Don't quibble about who is working or accomplishing more" so what do you do if someone accuses you of not doing enough? By not defending yourself isn't that like admitting they are right? –  user66282 Oct 17 '12 at 20:30
    
I think it is good to be assertive, but don't be defensive. If something unfair is going on you should try to resolve it quickly without arguing. State your case as directly as you can and move on. You may bring in your teacher or manager to resolve conflicts, but typically that is a last resort, and if you can't resolve your own issues, it is a negative indicator for leadership in most organizations. –  DeveloperDon Oct 18 '12 at 3:44

Part of what you will learn from this exercise is ensuring you have a good, clearly communicated design with your team mate.

Working alone you could "wing it" to some extent, by coming up with some "design" but then changing it at will, since it will only affect your own work.

Working in a team (2 or more people) means you should both work together to properly design what you are writing, and ensure that your "interfaces" or contracts are properly defined. I put "interfaces" in quotes, since they may not be proper OO interfaces, depending on the language you are using. (In school, it's a good idea to work together on the design, whereas in the real world it will often be one person doing the design, and assigning modules out to the team)

Once you have this properly thought out design, each person in the team can then develop a part of the whole system (a class, or a discrete area of functionality), and as long as they program to the agreed interface/contract the modules of the application should slot together.

One approach you may wish to use is the Feature-Driven Development approach, which means that 1 developer is responsible for an entire feature of the whole application, and as long as it fitted into the application "core" which glued the whole application together, they were more or less free to develop it as they saw fit. (this also makes it easier for lecturers to mark it, since they can clearly see which student wrote which piece)

NB While I am a big fan of pair programming, and use it regularly in my day-to-day job, I'm not sure if I agree that it would be of benefit in this situation, since it's too easy for 1 developer to just "tune-out" of the development. This is something which I usually only recommend for a complex piece of code, that can benefit from several pairs of eyes to get right.

share|improve this answer
1  
The problem with Design up front is that you need to know what you are doing before you can do it. In school, as in real life, this is not always the case. I suggest in addition to initial design - (it's just a blue print and is likely to change) that you need to work closely to refine you initial design/interface/contract. Without this, you can easily get into "Analysis Paralysis" –  mattnz Oct 15 '12 at 8:29
    
I absolutely agree - open communication is absolutely essential to make this work, as you should fully expect your initial design to change due to some unforeseen issue. The important part of all this is learning to work effectively with others, and not trying to be the lone-wolf super-human programmer we all believe ourselves to be ;-) –  Crollster Oct 15 '12 at 8:36

Since it's school/university you'll probably better off doing pair programming. You'll be able to both correct and learn from each other.

http://www.jamesshore.com/Agile-Book/pair_programming.html

share|improve this answer
2  
If they can do it well. However, IMHO pair programming is not always trivial to pick up for inexperienced persons via trial-and-error. Such an attempt can easily turn into something completely different, without the participants even noticing. In fact, it sounds like the OP may have already had a bad experience with it. –  Péter Török Oct 15 '12 at 7:57
    
I would encourage pair programming to. Especially for a first time cooperation attempt. You will learn a bit of how other people think regarding the same issues as you and you will learn skills from each other. –  inquam Oct 15 '12 at 8:16
    
Without knowing the personalities involved I would caution against making one size fits all recommendations - It you have any doubt, thats the Politically Correct way to say it.... –  mattnz Oct 15 '12 at 8:24
    
Well. That's why I added probably to the suggestion. the linked article should help them decide whether it's something for them or not. –  jgauffin Oct 15 '12 at 8:31