Slashdot Mirror
Pair-Programming with a Wide Gap in Talent?
efp asks: "I'm a graduate student and have a programming assignment coming up. We're encouraged to work in pairs and I've agreed to work with a friend. However, while I'm far from l33t, I've several years more experience than my partner. Are there effective techniques for pair programming with a wide gap in talent? I want us both to get a lot out of the assignment, and I do not want to do all the work (which has been specifically identified and disallowed by the instructor anyway). Navigator/driver scenarios? Index-card design techniques?"
Since you feel that you have more experience, why don't you let your partner take a first crack at the design? Afterwards, you can work with the design to refine it and give it the benefit of your "years of experience"
It sounds like you might have to suck it up and let this be a learning experience for your partner. However, don't be closeminded. People who are less-experienced can sometimes introduce a new way of thinking or a different viewpoint that those of us who are set in our programming ways may not have thought of.
I took on the role of Architect- and doled out other assignments according to the skills of the team. Mine was a three person team though....
SJW: a person who perceives an injustice, and while correcting it, commits a greater injustice.
One of the best ways of learning/practicing something is to teach it. As the more experienced person, you have a good opportunity to help your partner, even though you yourself may not have the chance to do anything really incredible on this project. By delegating some responsibility, but at the same time being very helpful about how something shoudl be done, this can be a very good experience for both of you.
Register the editry.
i'm not a skilled coder at all, but i really enjoy coding with a friend of mine who is very highly skilled. when we've worked on projects together before, we use a navigator/drive method
the less-skilled team member can do the bulk of the typing, which is much more effective for learning than *watching* a more skilled perosn work; the more skilled person can be giving instructions, or working on problems that will come up later in the code
another way to say this is that the more skilled person specs the project out while the less skilled person implements it, and it all happens at about the same time
it's worked for me, but i think the dynamic that already exists between the two parties is a huge part of how well this works
There are quite a bit of things that you can do in this situation, and most of it depends on the skill differential and the type of project. If your partner is not a very good programmer, expect to be their teacher. However, you can't expect to hold their hand the whole way and help yourself or them. They will have to contribute their share in one way or another. As the more experienced programmer, you should have more control over the direction the programming starts off in. Don't leave your partner out though. Talk with them about what you are doing and why you are doing it. Give them tasks that you know they'll be successful at. You might need to do the most complex code yourself, but they can certaintly help fill in the gaps whether it be by writing and testing functions, doing research for the code you need to write, testing what has been written or doing documentation or other right-up related material. I think the bottom line is that you need to excerise your superior skills in a way which positively impacts your partner. Don't be over bearing but don't give them enough rope to hang themselves (or you for that matter).
Scott
S/he will hopefully be looking forward to this too!
:-/
s/he comes with a new pair of eyes, wide and amazed by all that stands before them. Make sure you dont "ignore" them and they will work hard for you. Just because they are less experinced doesn't mean they will work any less hard. Hell, they will hopefully work harder because they know they have a chance of producing a better project due to having someone with better skills.
I know im currently looking to do a java project, outside of uni, with a small team, so hopefully i can actually produce something which works. Currently i produce stuff that doesn't work, because for uni i can still pass with just that!
- http://www.milkme.co.uk
The lesser-skilled one will learn from many things:
- how you approach difficult problems
- how to write tests that effectively target behaviour
- how and when to refactor effectively
- and plus you get to give feedback on his code directly - as long as you're constructive with it, it'll be a good experience.
Plus, you both will get about equal keyboard-time.First find an old monk and a young monk...
i had a similar situation a while ago and to no surprise i was the one who did 95% of the coding, since both of us had the priority on "getting the job done" instead of "learning as much as possible".
still i quickly noticed how my code got better whenever i at least tried to keep a pace at which the other guy could understand most of what i did, so in the end i got into that teaching role (that always teaches yourself a lot too) without deliberately forcing me there and the other guy got more than we initially expected.
if you now deliberately let the other guy solve some of the easier problems himself (which is not "alone") then the learning result might even be close to optimal, because doing little things right will teach you more than barely finding something that might pass as a solution to a bigger problem if that means employing bad practices.
[i have an opinion and i am not afraid to use it]
Sorry, but what's going to happen is that as time goes by, your project will asymptotically approach 100% your code, as you replace and redesign almost everything he's written. I understand that your project can't be all done by one person, but I've been in this situation a lot of times, and so trust me -- do it all yourself and save yourself the headache of having to rewrite the entire project.
That said, pair programming with other people at your level can be quite good, as having two people working together keeps one or the other from getting distracted.
If you want your friend to learn something from the experience, have him do it all by himself, and then when you're done, show him the right way to do it. Or, hell, he might surprise you and you'll learn a new approach yourself. But the total man hours will be less than doing one project together.
What better way than to round out a new / young programmer's
knowledge than to work with a more experienced colleague?
Compare & contrast notes & techniques as you go... & learn.
I don't mean to accept all that's put on the table (screen),
but to have the author right there to ask the odd question -
now & then - has to be an improvement on having the source.
Yep, as we read in a recent article on OpenBSD's attempts to
get (typically: non-Asian) hardware makers to release source
and/or info needed to write drivers, having the source alone
may not be enough for understanding, at least in such cases.
Go for it & get what you can from the experience.
PS What we need is more Pair Teaching (not only the less exp'd
teacher would gain, but so would students... more than one
perspective on the subject matter has to be a win for them)
So you write something like
int Add(int a, int b)
{ return a-b; }
int Test()
{ return Add(1,2) == 3; }
And then your partner can make the test pass by writing:
int Add(int a, int b)
{ return 3; }
or if they are clever,
int Test()
{ return 1; }
Or with a little refactoring,
int OldAdd(int a, int b)
{ return a-b; }
int Add(int a, int b)
{ return OldAdd( a, (-1)*b ); }
Extreme Programming. http://www.extremeprogramming.org/
One of its basic tenets is pair-programming: http://www.extremeprogramming.org/rules/pair.html
Of course, if your partner is way below your level, every session would end up being a tutorial, very counter-productive. In which case, he should either step-up by practicing in his spare time, or worse comes to worst, get a new partner.
Take the time to help your partner get grounded but don't do all the work and be firm about it. In the future don't partner with friends. There is always an expectation that friends are suppose to "help" each other get good grades, which is . I partnered with 3 friends for a semester long project and it was terrible idea. I ended up doing all the work, and the got nothing out of the class.
If the quality of the work is so poor, though, you may not have any choice but to "takeover" the project.
-----
One is born into aristocracy, but mediocrity can only be achieved through hard work.
I've always been a big advocate for pair programming. In my experience, two equally skilled programmers working together on a project tend to progress more quickly and produce better code. When you're working with someone who has less experience than you in the subject on which you are working, I think there is a sort of natural tendency to try to "take over". The most common way this happens that I've seen is that the less experienced programmer says "why are you doing A? wouldn't B work better?" Many times the more experienced programmer will disregard a better solution because they've been using their solution forever and a day. Remember that a less experienced clever programmer has that sort of fresh set of eyes and hasn't become clouded into thinking something is good just because it's common. Remember to use that to your mutal advantage.
Another thing, as other posters have mentioned, is that a lot of code that would be boring broiler plate stuff to you may still be an interesting challenge to your friend. Consider the 90/10 rule (10% of the code takes 90% of the time) and use it to your advantage here. As the more experienced programmer, take on the "10%" (I use quotes because it will probably vary depending on the project anywhere from 1% to 30% of the actual code) and let your friend work on the "90%". Also remember that you and your friend probably have different areas of expertise, so something that may seem difficult to you could seem obvious to her/him.
In the end, play to your respective strengths. Respect eachothers knowledge and opinions, and don't forget the insite that can come from fresh eyes. Keep things light and fun, and try to learn from eachother.
Famous Last Words: "hmm...wikipedia says it's edible"
I would try to break the task down into smaller tasks so each of you can contribute. For example... have you partner write code that interacts with the DB while you write code to manipulate that data once *he* has retrieved it. While you are working with the data, have your partner write something that will address data presentation, report generation, stats, etc.
:)
Just break things down into smaller things and you'll both do fine
I thought the skillz gap was the point of pairs programming.
I'm not a huge proponent of all of the XP stuff, but the built-in test cases has always seemed a good idea. I've found things like Junit to be hugely helpful -- it's really nice to have code check your code. A co-worker just started using it because he found a real need to have his code verified after new changes/refactorings so unexpected things didn't break -- he was making changes that he didn't realize would impact other things and needed a sanity check.
I always thought the whole point of pair programming was to bring newbies up to speed with stuff, while hopefully bringing a fresh perspective to the code. The newbie is supposed to ask questions that makes the senior coder explain, define, and defend why something is the way it is -- the best case scenario is you document some of the stuff that comes up. Ideally, the pair programming should both improve the code, and increase the sum-total of knowledge of the code in the organization.
Unless your friend is a total newb who doesn't know anything, the process should probably be beneficial to both of you.
One thing I think that XP and pair programming is to codify and entrench a culture of sharing knowledge and technologies. In my experience, those coders who want to keep their stuff l337 and 4rc4ne are crappy team players. If you're not willing to spend an hour explaining how things work to your co-workers or your QA staff/junior programmers, you're probably a liability.
I like to think that our QA staff can know that any question they have about the software is valid -- the more they understand how it was intended to work, the better they can test, and they'll never have to ask again; same for our support staff. I find it gratifying to hear them explain to someone else how it works, because it means I've done my job in educating them. I find it makes for a better QA staff, as well as better software -- and I pride myself on the fact that I've never had to explain the same thing twice. (I've had to clarify, but that was because something was complex, or I didn't fully explain it the first time.)
Same deal for newer programmers -- bring 'em up to speed, educate them, and don't treat your knowledge as something to be closely guarded, and the whole team works better. I can absolutely see how pair programming would achieve that.
What you know is the sum total of what you've seen and been told; if you think sharing with someone diminishes your value, you've totally missed the point.
So, in short, try it. If you're in a personal project, you get to teach, and improve your pet project. If you're in a professional setting, you get to teach and improve the quality of the code -- this makes you more valuable and integral to the orgnization. If what you know needs to be closely guarded to keep your edge, you probably shouldn't be doing it in the first place.
Really, what do you have to lose by trying to impart a little knowledge to someone? Even if you decide that not all tasks can be done in pairs, fine, set limits. Do it yourself, but before you commit the changes to your SCC, review them in peers and justify the changes. Pick and choose the rules of XP; they're designed to be flexible, and they already account for that.
Cheers
Lost at C:>. Found at C.
How about the young programmer read source code from a variety of projects. Why should I bother to teach someone who can't be bothered to make that effort, or who remains fundamentally ignorant about not what to learn, but how to learn ?
How about the novice actually crack open some difficult textbooks and sandbox programming environments and really study the fundamentals. Why on earth should I teach any basic concepts broadly available in the standard literature ?
How about the novice actually study up on the domain of the work, in addition to the vanilla comp sci topics. Why should I have to cover and compensate for his lack of motivation and lack of desire to engage in domain subject matter ?
Before we advocate the merits of apprenticeship with great enthusiasm, how about we also concurrently and ruthlessly consider trading, firing, or safely sandboxing the less competant elsewhere, and replace them with sufficiently competant staff.
I'm not out to troll you, I seriously think most novices are problematic. For every ideal novice and situation you can posterchild, there are a dozen that are dysfunctional, unpleasant for the expert, or simply inefficient.
Most expert developers I've known at a variety of companies and settings have little interest in training novices. Linear to our degree of expertise, we want to execute with high competance and attention to detail on complex domain models and enterprise warehouses and highly scalable services and so forth. Novices are not welcome.
Journeymen not yet up to speed on certain project specifics or domain specifics are fine. I would submit they are usually journeymen because they actually do the things I listed above, which your novices ought to do bother bothering people. e.g. reading source code widely, exploring and practicing difficult spaces in the compsci literature, branching out to studying a non-compsci domain, signficantly contributing to an open source project, etc.
There are places for being a novice, but they include school, your own time, hobbyist open source projects, official company-sponsered training courses or free days, professional conferences, and so forth. They do not include expensive, complex, or mission critical work projects, which are, candidly, a sizable majority of work project, else they wouldn't be professional work.
I am myself a novice in new domain areas or technologies, as is any expert, but I don't inflict myself on my work collegues in those areas, or ask them to train me when I have wide resources to train myself. At minimum, I come for clarification or a quick tip at the journeyman to advanced journeyman level, and have a variety of worthwild knowledge to exchange.
Or to spin your quote another way:
What better way for the young programmer to round out his knowledge. But what a painful-to-watch, project-delaying, time-consuming, novice-code-rewriting, overtime-causing chore for the unlucky competant collegue.
I'm paid to develop software, not to teach.
"The hottest places in Hell are reserved for those who, in times of moral crisis, preserved their neutrality." -Dante
It depends on your methodology and goals.
...and dealing with strict OO code, I would write the class structures and high-level organizational code yourself with input from your partner. Then divvy up the implementation, taking the lion's share on yourself. ...and a writing web-based application, I would talk over the application together, write the "heavy duty" database / backend code myself, and then leave him to do the presentation.
//takes two strings and xors x against y ) and some test data.
If you're just trying to ensure a smooth project...
On the other hand, if you really want your partner to get as much out of it as possible...
I would take some of the suggestions other people around here have offered. Write some tests or interfaces for the difficult code, and give him as much or little guidance as you deem helpful.
In any situation, though, I think the most important thing is that your partner has the ability to see criteria for success and test against them. If he doesn't know what he's trying to produce, he's not going to be productive. If you want to be a nice guy and expose him to the actual parameters and concepts of the assignment, good for you, but that means understanding the project fully enough to explain it simply in ADDITION to doing the gruntwork that he won't have time to do. If you just want to get this thing done as fast as possible, give him a lot of methods to implement ( foo(x,y)
I was always cynical about my CS education and basically threw as much grunt work at my partners as possible and then blew through the other 80% of the project the night before just to make them nervous. YMMV depending on whether or not you are a disillusioned 18-year-old me who had no idea why he was blowing through his parents money at some academic institution when he was ready for a Real Job before he started high school.
When you guys design it, assign specific parts to him.
When he gets something wrong, don't redo it, don't tell him "No, do it like this", ask him why he chose that, and did he consider such and such.
Same stuff with coding; why did you do this in this fashion? Did you consider xyz? Which do you think is better? why? And don't just do it with stuff he gets worng, do it with stuff he gets right.
And, if after all that he chooses one way and you would have chosen another, let him "win".
(I assume that you refer to the agile practice known as pair programming, and not coding as team of two people.)
Unfortunately, you aren't in a corporate scenario, where each individual's contribution to the success of the project will (in theory) be judged more or less independently and rewarded accordingly. You are in a class, and the same score for your project will be assigned to you both. That being the case, try out pair programming if the disparity in skill is not too great and your partner shows willingness to invest in learning. Otherwise, then do the bulk of the work yourself and assign your partner to peripheral tasks, to whatever extent your instructor's directions give you leeway. It is ultimately your grade on the line.
In the initial sessions, assess your partner by observing how he behaves. When not in control, he should be actively contributing to the project by pointing out mistakes and ways in which the code should be better and learning by asking questions about what you've done that he doesn't understand or doesn't understand the reason for. He should also actively be encouraged to take control when he believes his solution is better than yours. When in control (which, as the learner, should be the bulk of the time), he should be able to independently navigate to an acceptable solution, ask questions if a path to a solution or anything else is unclear, and be responsive to your guidance. Within a few sessions, also begin assessing his level of improvement. He should be focused on learning by observing you. If he does not do these things, gently encourage him to do so.
Document my code.
or
Just build all the required functions and classes, and let him connect the dots.
or
Let him use all kinds of compiler optimizations and build the makefiles.
or finally
Let him attempt to build the whole program first. Then 'tweak' it to make it work.
"Give orange me give eat orange me eat orange give me eat orange give me you." -Nim Chimpsky
I was the only good programmer in my team for a little electronic robot for a class.
:P
:P. In other words, make him do the routines. Tell him "i need a function that does this and that". So he'll keep being busy, while you can concentrate on doing the more intelligent stuff.
I concentrated in doing the program.
Another guy concentrated in doing the electronics.
Another guy on assembling the robot.
And another guy on doing the interface.
Our teacher wasn't pleased, since teams were supposed to be of 3, and we were four (or something, I don't remember very well). So he asked us if someone was in charge of bringing the sodas
In any case, I'd suggest you to assign him dedicated, controlled stuff. Like "master-slave", where you're the master and he's the slave
But not for the face value reasons. It is very refreshing to hear all of this positive feedback from the responders. Too often in our field we leave newbies out in the cold with an elitist mentality about our trade. There are people who rather than help, sit back and snicker an make fun of the mistakes the new guy makes, or of his lack of experience. All of that is certainly not helpful, and can hurt an aspiring coder. From what I read here, I would be happy to work with any of these posters.
My
Writing code with someone who is majorly less skilled than you is a real drag. They tend to want to reinvent the wheel for every common programming problem instead of pulling in standard libraries. They do this for even the most simple programming constructs (like isalpha(), isnum(), etc).
That unwillingness to reuse becomes painful becase you can see the project isn't getting anywhere. Meanwhile your partner has written hundreds of lines of code to solve menial problems that libc.a or libm.a already could have solved and not actually touched on the real problem you have to solve. Of course, they think they're making splendid progress because of all this code they've written.
A lot of the unwillingness to reuse comes from being scared of something they can't see the innards to. I often heard "but the document's don't describe $OBSCURE_CASE, I'd better write my own version that handles that case too" even though they could have just tested for $OBSCURE_CASE before the function call if they thought that it might occur.
Anyway. Good luck on your project, and try as best you can to get your partner to actually work on your project, instead of reinventing the wheel. Sit down and plan the whole thing out. Break it up into manageable chunks and agree how the chunks will talk. Hand out the chunks and start coding. Keep an eye on your partner and if you see them going off on a tangent pull them back into line and show them simeple ways to do things.
I drink to make other people interesting!
I think there is a really excellent chapter in the following book Pair Programming Illuminated which discusses this. Basically, this is a teacher and student relationship in a sense. As such, you need to encourage the novice to ask questions about what you are doing (when you are driving), and to encourage the student to talk out loud about what they are thinking when they are driving. Finally, you must slow down and explain when things are tricky, and never confuse head-nodding or awed silence for understanding.
As the expert, you do need to delegate tasks. I think it is fine to send a student off on small individual assignments on the project, and then bring it back, they can explain it to you, and you provide comments on the work. Together, you can then bring the code into the codebase. This gives the novice the sense that you don't have to watching over their shoulder all the time, and ideally, moving the code into the your project is quick and simple.
If there is an existing code base, one of those assignment could be a simple "Present it to me" task. Learn this bit of code, and explain what purpose it has in the system, and bring me a list of questions and concerns about it. Then, after that, do a pair programming task that involves that code. The novice drives, you watch.
The list goes on and on. One other thing is to try to get the less experienced person to take on more and more tasks. In fact, you can almost challenge that person to know more about a part of the project than you do. This is good, because you don't have to be the expert on everything, which is tiring. And more you aren't the sole expert on, the better for you. You can just bring your experience to bear when it is requested, allowing you to focus on other tasks.
Part of me wants to say something about proper modular design, object-orientedness, thoroughly designing interfaces then splitting up the work, blah blah blah. However, the reality is that most programming assignments are too small for full-on thorough design to be anything but an obstacle, particularly for a one (and to a lesser extent, two) person team. So, realistically, here's how I'd do it. Note that this is not an ideal, this is what I think would actually happen if I was in your situation. You start coding first. Write the whole thing top-down, and stay at as high a level as you can while keeping it logically coherent. When you get to a lower-level chunk that you don't want to think about right now, write a stub or a FIXME, and get the other guy (I'll assume male for now) to write a function to do that. Then just keep writing, on the assumption that you will be able to plug his function in eventually. How big or small you should make the tasks depends on what you think he can do. Don't just say "here, do this" and then ignore him; give him an idea of how this task fits into the program (if it isn't obvious), let him ask you for ideas about how to do it, and be willing to claim bits back if they're too tough. On the other hand, be prepared to hand off bigger chunks if he's knocking over the stuff you gave him easily. This is based on a few assumptions about the situation - that the project, or decent-sized chunks of it, can sensibly be written top-down; that your partner will be able to handle what you give him; and that he won't argue too much about the architecture. But with some minor tweaking it can probably work. Oh, one more thing - use version control.
mentoring to me! Damnit, this is why mentoring was invented; you get the benefits of experience and uneducated (read; non-cynical) enthusiasm rolled into one team.
Personally, I have always found a good mentoring experience* to be uplifting, enlightening and beneficial. And that's working on both sides of the mentoring experience!
* a good mentoring experience is defined as being one where both parties are well-matched in competency, diligence and intelligence. The only gap should be experience, although minor gaps in competency and intelligence can be tolerated.
.. they type, you teach... unless this person is a complete idiot, I am sure they will have something to add. noone thinks of everything. I've found that I am really good at something and become the 'knowledgable' one when pair programming and it comes to these things, but sometimes the solution requires more than just the knowledge about the topic it sometimes requires a lack of knowledge about a topic to think about it differently and solve the issue.
Only 'flamers' flame!
Does slashdot hate my posts?
Read the first few lines describing the assignment. Wait until two days before the assignment is due, and then he can get the donuts and coffee while you pull a few all nighters to finish the project. Get a friend to pretend to be your boss. Your friend should stand over your shoulder, asking if you are done yet, and read the rest of the assignment to you as you program, adding and subtracting requirements at random.
I Am My Own Worst Enemy
In these situations, one of the best things you can do is write failing tests that he can implement. You have more experience, so you should set the tone and teh goals. Write the tests that you want to creat such that, when passing, will not only get the job done, but teach him something in the processess. Keep them small and instructive.
Don't let them get behind in the project at all. You've got to keep them updated on what code you've done, how it works, etc. Let them ask questions and get up to speed before you move on, and maybe copious amounts of correct comments and documentation wouldn't hurt either.
I did a very difficult programming assignment during my undergrad days, and my parter didn't pull their weight in the slightest. The only part of the project that was broke was the small part my partner did by themselves. And my partner wasn't even worse of a coder than I was - he simply got behind and spent all his time reading the code that I had written instead of writing it himself.
Secondly, practice good programming and make sure you both have a very good image of the design of your project. If you have that to a fine enough degree (though you don't need to get as ridiculous as NASA), it will make it easier for you to spot mistakes that your partner has made (and ones that you have).
Did you ever notice that *nix doesn't even cover Linux?
That begs the question of whether or not they know how to learn or not.
That begs the question of whether they are indeed unmotivated and lack desire.
Geez Louise, you're jumping to so many conclusions here you probably wore out your new tennis shoes already.
I've been training a new person since November in my particular specialty. Beyond giving me rare insights and making me think twice and thrice about what I'm doing, the social interaction and the joy of watching them grow and develop is something that I'll treasure long after they have moved onto another group (or I have.)
Clearly you're paid to develop software.
I'm paid to develop software AND develop the next generation of people to develop software.
And whether I'm paid more than you or not, I'm a lot wealthier.
Mit der Dummheit kämpfen Götter selbst vergebens.
You say that you have several years more experience than your partner, but you describe the situation as a "wide gap in talent." Remember that talent and experience are not the same.
I'm not a professional programmer, so I can't speak from experience about this kind of work. But I'd think, in general, that the way to work well with a talented but inexperienced partner is very different from the way you'd want to work with an experienced but less talented partner. If lack of experience is the reason your partner can't work as effectively as you can, it's natural and in no way insulting to your partner for you to take on a mentorship role. If you and your partner are equally experienced but have a "wide gap in talent," the situation is much more delicate.
that I'm paid to develop software that accomplishes a purpose that betters the world. If I make mistakes, or allow too many novices on board, or allow a novice on board that do not happen to have a sufficient desire to learn or to perform due diligence...someone literally suffers. Somewhere someone will recieve a poor medical outcome, or fail to get a home loan, or watch their startup fail for lack of a quality tool, or labor unneccessarily in the absence of a timely product, etc.
I'm not willing to develop the next generation of people to develop software at the expense of my end user's or the company's customers. I'm not against the obvious neccessity of novices learning, I just don't think it's appropriate on serious projects. They should cut their teeth elsewhere.
You may indeed be richer, regardless of wealth. I am not so full of hubris not to notice the validity of your critiques. As regards wealth, I can say that it is not the money that obliges me to perform, it is the obligation and the responsibility that accepting the money entails. We, as experts, are being paid exceedingly well to deliver, not to engage in pleasant social interaction. And we have an addition obligation not merely to the company that pays us, but to the users of our products and to society.
I question whether the training of novices comes at the expense of other people, and I find the likelihood that it often may, rather tragic, with due respect to the possibility that you may be in an honorable and beneficial situation. I am not persuaded your circumstance is not an outlier of good luck, nor, particularly, whether it is biased towards overlooking instances and costs of failed apprenticeships.
"The hottest places in Hell are reserved for those who, in times of moral crisis, preserved their neutrality." -Dante
this sound like it is an excellent way to prepare yourself for a career in the real world.
Some see the vessel as half full; others see it as half-empty; We pour it out on the floor and laugh
No matter how often I've coded with people with differing levels of experience (sometimes I've been more experienced, sometimes the other way around) I find that being humble, while not entirely pleasing, gives a good experience for both parties involved no matter how l33t you are...
...becuase you'll always forget a semicolon.
in girum imus nocte et consumimur igni
If I make mistakes, or allow too many novices on board, or allow a novice on board that do not happen to have a sufficient desire to learn or to perform due diligence...someone literally suffers. Somewhere someone will recieve a poor medical outcome, or fail to get a home loan, or watch their startup fail for lack of a quality tool, or labor unneccessarily in the absence of a timely product, etc.
What, you have no unit testing? No QA? That's your failure, not the novice's.
You develop freaking SOFTWARE. No more, no less.
Personally, I'd rather develop software, AND people, but maybe that's just me.
My lab partner was a continuing education guy from IBM who had 20 years of experience ( he had white hair ) and was earning his MS. Me, I had no industry experience at all. We had to write a program for class that played a game using AI techniques. Since a lot of dynamic programming stuff was involved, I reccomended Smalltalk ( Visualworks ). He was only familiar with C, mostly in a systems programming vein. I was wary of trying to troubleshoot pointer problems, as AI code in c can get pretty hairy.
;)
:D
The kicker was, we could only really meet and work together on the weekends ( unlike everyone else who lived on campus ). He had a day job. Thus we only had 6 weekends to do it ( and I would be missing a weekend because of spring break too! ).
So we said "Whoever can get the basic search functions working first, we'll use that language." By thursday, my framework was working, he was still fighting various pointer problems.
"I don't smalltalk" "You know programming. It's all the same. I'll teach you the language, it's dead simple."
Smalltalk has a very small keyword set, and very simple but powerful semantics. So I explained it to him as we typed. And even with the vast gulf between C and Smalltalk, he was able to catch some common problems, and offer some design ideas.
Working only on weekends, we were one of the few groups to finish a working program that could play the game well. In fact, we had one weekend left.
The last weekend before it was due, we used Visualworks UI designer ( before glade even existed ) to make a gui, hooked it into the engine, and players could then play against the computer with a nice UI. It kicked butt.
We were the only group that finished on time, with a working game engine and working GUI. All the other groups, if their project ran at all, had a command line interface. I remember chuckling to myself at the start when one group mentioned that they were going to use C++ and MFC, and they'd have it working in no time. Famous last words...
We got a 110 on the project. >:)
So yeah, pair programming rocks. It was a educational experience for both of us.
If you follow that path - each working on different areas - you are no longer practicing pair programming. You are just teammates working on different portions of the product.
I hate it when people attribute gap in productivity to talent!
...
...
...
I think we use the word talent to refer to our missunderstanding why someone is better than someone else in doing something.
Ohhh, he is more talented!
I am not into poetry or painting, so I can't be judge of why some people paint better than other.
But programming, is something I dig into, and I wouldn't compare it to painting, ever.
To a good programmer, in my opinion, require some skills/discipline, and some education.
I believe it's the skills/discipline part that many people confuse with the so called talent.
To be a good progammer you need to be patient, you don't learn patience, but you are trained to be patient.
We went to school, and by going to school daily, even thought it sucked and we didn't learn much, we were trained the skill or discipline, and being on time, every day.
So after finishing school, going to work, even if it sucks isn't such a big deal, cause you been trained.
This is just my attempt to justify gap in productivity amongst programmer, of course there other factors, like how honest and sincere you are in general, how serious about work are you, how much do you love what you do, etc
I just don't like the word talent, you can't measure talent, and what you can't, measure you can't improve, if you believe it is so, then, logically you are saying that there is no hope for bad programmer, which is probably true, but for different reasons, for example, its so hard to train people some skills after they reach a certain age, etc
My advice for the guy asking the question here, is be a good manager, educate and motivate, and educate, and motivate
Lack of education might push ppl to not try their best, so by educating them, teaching your partner what you know and he don't, you will motivate him to do better, put more effort.
And I think what you want from your partner isn't really output, as much as it is effort, if talent exist, it won't affect how much effort he pus, it will affect the quality of the output.
So that's it this is what I thnk!
A lot depends on the partner and how they want to work. I did well in one assignment starting out giving new staff skeleton code to fill in. They had the pre-commented class and method signatures and just needed to provide the implementations. As they advanced they were just given the public interface to the component as a whole and were free to implement that interface on their own. Do that with a couple of components and developers and watch with glee as the componetns come together at the end and work. You need a system that can be componentised though.
Problems come if you get a partner that resists. Coming to a team as the new one for example, even if asked by management to lead. You have to gain credibility, during which time a lot of bad code can be written. It's a fine balance.
If you're doing pair programming properly, one person can't end up doing all the work. Both people are working simultaneously - usually one is coding, focussed in on the details of the specific function and the language that you're developing in, while the other is both checking what that person is doing and keeping an eye on the bigger picture (what is the actual purpose of this function, what is the overall problem that we're trying to solve etc). If anything, you would want the less experienced person spending more time (but certainly not all of the time) actually doing the coding initially as you can then be guiding him when he's going wrong, making sure that he's coding the right unit tests etc.
I had to work with a less expert friend of mine twice and the first time I ended up rewriting most of the bulk work she made since the design had holes that could not easily be patched.
:)
The second time around we first agreed on the specs (and made them strict) than each one wrote its part and later we exchanged the code and looked for bugs in the other's code. It worked much better.
(I have to mention that the second time she had become much more better than she was the first, that played a role too
.. more experience than my partner ... a wide gap in talent
Make up your mind: is it a talent gap or an experience gap? They're not the same thing.
I'd try pairing with the other guy, see what your individual strengths are, and play to them.
My Karma: ran over your Dogma
StrawberryFrog
I actually wrote "much more better" argh!!!
:)
all work and no coffe makes muzzle unaware of the grammar
I've been in this situation, but on the clueless end (I still can't program my way out of a paper bag.) I thankfully had a pretty smart partner who just "got it", and who was willing to take the lead with the problem solving.
We did our work sitting together at his PC; he made sure to constantly ask me if I understood what he was doing, to give me smaller chunks of the problem, and to try to lead me along.
I don't know how you define "doing all the work", but he was certainly the active party. I learned a lot from our assignments, and was extremely grateful to him for leading me out of dead ends, correcting my stupid mistakes, and generally coaching me.
If your instructor frowns on this sort of thing, I question his academic seriousness; it's always been my impression that assignments and tests are as much learning experiences as lectures or studying.
I know this is sort of a blue-eyed optimal scenario, but if your partner is willing to work with you and take an active role, it's really cool for him to have someone with clue to guide him along, and would probably be good experience for you in terms of coaching and tutoring.
Cole's Law: Thinly sliced cabbage
Is there some way you can split it up into two parts, one being easier than the other? I had the same issue in a class in college. I ended up writing an assembler and virtual machine for a fictional assembly language and my partner wrote some simple programs in the fictional assembly language. We got A's...
There's a difference between ability and experience that most of you are missing.
I've been in this situation often:
If the other person is good , i.e. smart and well trained, you can safely get them to do 90% of the work with the odd nudge in the right direction.
Just keep pushing things at them until they choke, walk them through the hard bits and repeat. You'll be amazed how productive it can be with you providing the experience and the confidence and the "junior" doing most of the coding.
Not only that, by the time this project has finished, they'll be a lot better and capable of doing smaller projects (and maintenance of this one) on their own.
You also win, because this gives you a chance to do the architectural stuff that normally gets skipped through lack of time, quality generally improves significantly.
It's a different strategy for "placeholders" - but I'm assuming that if you are using pair programming someone probably has a clue from day one.
Cheers
BTDT.
...absolutely the only commodity anywhere in the world which you can give away freely to everybody you meet--and still yourself possess.
"We reject kings, presidents and voting. We believe in rough consensus and running code." Dave Clark, IETF
...I have to disagree. You should never let it get that far.
The minute your instincts tell you that you are heading towards an abyss (for example an antipattern) you should speak up and question it, pointing out that you happen to know there is a 'bridge out' just around the bend. Then you should explain your reasoning, as it may just be that your partner knows it too but intends to swerve onto a new path which _you_ don't happen to know about. None of us knows everything.
To force the metaphor entirely beyond reason: anybody who has had to rewrite a whole project either wasn't there when the car passed the forks in the road, or else was asleep in the passenger seat.
Two heads are nearly always better than one.
"We reject kings, presidents and voting. We believe in rough consensus and running code." Dave Clark, IETF
While I think the GP missed the point, it actually does work in a way. While you wouldn't want to be working seperately, pair programming is all about one person driving (running the keyboard and generally the main algorithm) and one person watching and commenting. By having the person most experienced with an area driving, you still move at a decent clip, the person watching learns a fair amount by watching and listening, the watcher often catches a lot of little syntax bugs, and by being forced to give at least a running commentary of what they're doing, the driver is learning too.
I've recently had the experience of doing pair programming with someone just out of college, unfamiliar with the work we were doing and unfamiliar with the language and it still worked out. Admittedly, he hasn't driven much yet as he's still getting up to speed, but he's got a decent grasp of the architecture now and he's starting to get the language too.
This sig has absolutely no significance and serves only to take up screen space and waste the time of the reader.
I always kind of preferred it the other direction with the more experienced person at the keyboard. Unless both of you are good listeners, good typers, and in general have a very tight bond (as you and your friend likely do), progress will be slowed by misunderstandings and errors as the person navigating suggests code and the driver types out what he thinks he hears, not what's being said. ^_^ And given programmer communication skills, sometimes the problem is that the driver is writing exactly what's said, not what's meant.
So long as the person driving at least does a running commentary on what they're doing and why, the navigator will be picking up on things as they go and by forcing the driver to explain himself and answer questions, he'll be paying all the more attention to what he's doing and why.
This sig has absolutely no significance and serves only to take up screen space and waste the time of the reader.
That's OK. It's nothing to be ashamed of.
I often say the reason I sometimes mutter to myself is that when you find yourself in a tough spot, it's comforting to tell your problems to the smartest person around.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
The design should be done together. The coding should be done together. The testing should be done together.
:)
_Not_ one guy doing a rough design and then the other guy reviewing it (and maybe rewriting it).
The essence of this is _talking_. Talk about what you intend to do before you touch the keyboard. Listen to and assess your partner's replies. Answer your partner's questions. When you reach something approaching consensus, _then_ hit the keys and write some tests. Then implement. Then test. Then review. Then move to the next bit and lather, rinse and repeat.
This will take longer--maybe much longer at first--than working alone; but the code will be vastly better and you'll be producing better code faster as you get used to the technique.
When your partner is doing the talking, follow him/her step by step and pipe up _immediately_ if you've an objection. Don't sit silently analysing one point while your partner runs on. Nobody can listen to one thing and think about another at the same time.
You might want to stay silent because you're afraid you haven't thought it through and have made a mistake. Instead, be completely open, allow yourself to make mistakes, even big ones; even often. It's OK to make a mistake; and mistakes _teach_ you things. Never forget that. Forget your pride instead. You'll become a better programmer.
If you throw yourself into this freely it might just make you into a better person as well; more open, looser, more laid back, more confident, more light-hearted. These are good things. (And guys: women are attracted to these qualities in a man. They've told me so.
If something occurs to you while you're typing, stop typing and talk about it. Maybe you've remembered a better way. Maybe you've thought of something new. Maybe it's just an old blind alley. Talk about it and you'll (both) find out. Pair programming is about bringing another mind into your normally internal mental conversation by vocalising.
Although pair programming is a relatively new concept it has many similarities to a development process much favoured in the Eighties: formal code inspections a la Jackson methodology.
For those who don't know: in that process a programmer, having come up with a design, called an inspection meeting _before_ touching the keyboard. (yes, I know about meetings too, but these had a purpose and _worked_). At the meeting were the programmer, a requirements analyst, a DBA, a representative of Ops and a fifth, uninvolved person who did nothing but take notes. The programmer chaired.
The programmer was required to present verbally his or her design and planned implementation. Each of the others was there to offer the view of the design from the POV of their own discipline.
No meeting was allowed to last longer than 20 minutes because being humans, none of the participants could fully focus for longer than that, and _full_ focus was required of everybody present. The last 5 minutes of every meeting was for developing a complete, written task list--for all participants--resulting from the discussion. All tasks on the list had to be at least addressed, if not completed, within a day. Any issues still outstanding at the end required a second, still more focused meeting. There could not be more than 2 meetings. There was no coffee and no doughnuts. There was no time for that.
Like all of my colleagues, I loathed the idea of formal inspections before I did one; and I still loathed them after I'd done a few. The reason? Those guys were picking holes in MY DESIGN! That was my BABY they were criticising. I hated the process; I hated them. And then later, when I saw how much better my baby became, I loved the process; I loved them. IT WORKED. Better code. MUCH better code. Code that would work in the DB. Code which met the requirements. Code that would run silently and sweetly in Ops. Code which scaled well. Code which was efficient and flexible and agile and reuseable. Code which was fast. Code which any programmer woul
"We reject kings, presidents and voting. We believe in rough consensus and running code." Dave Clark, IETF
I'd say dive right in, don't hog the keyboard and make the other guy sit at your shoulder. Let him/make him do his share, and if you disagree, let him make you explain yourself. Restrain your impulse to lay down the law, and practice listening. You might find you get a lot more out of this assignment.
Nothing is more instructive than helping somebody else, unless it is lettting others help us.
The truth is, few of us is as good as we think we are. Or at least few of us are so good that having our ideas challenged now and then isn't healthy. Many a time I've got up with the intent of showing something to somebody else, and the very prospect of doing so gives me a new perspective.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
I know. We're getting off of the topic of pair programming, but I've got my stump when it comes to unit testing. Unit testing is handy but it is far from a panacea and it can lead to serious problems if you're not careful. First of all, unit testing will only test what you tell it to test. If it's not covered in your tests, it's obviously not being tested. Secondly, it's tempting to run tests and then fill in the "correct" answers for the tests, but if your initial code is wrong, all of your subsequent code will be tested for the wrong values. Anyhow, useful tool, but be careful.
This sig has absolutely no significance and serves only to take up screen space and waste the time of the reader.
If she did the driving, you should have done the navigating.
So it would have been you that should have kept her clear of the design holes you got.
If you just lets a novice program alone, expect that you have to rewrite it.
That is how I learned to program. I learned OOP concepts (high level) and learned how to program PHP by pair programming with a friend that was far more experienced than myself. It mostly consisted of him programming and me watching. He would explain each chunk of code and why it was there and how it worked. A lot of those first sessions went right over my head, I just kept up with as much as I could. Slowly I would take over in certain sections (he could sandbox out a part of the code that was relativley easy in comparison with the project).
It can be a good way to learn, but make no mistake you will have to do most of the work. I spent a lot of time with this friend (we would stay up to 3 am consistently) but in a couple weeks I was doing a lot of routine PHP work with no problem. (Granted PHP is easy compared to, oh say Java, but since I knew NOTHING about programming prior to that it was a good leap for me).
In any project you have your three constraints: time, budget, scope. If you have less "resources" you will probably see a relative increase in time to compensate for that.
To bring this back to the original poster, by the way, remember that it was a grad school programming project. If not that sort of project, then what? If not there, then where?
Sorry, I guess we have to agree to disagree. You are paid exceedingly well to do what your employer tells you to do, no more and no less. Unless you're a sole proprietorship, that may involve doing things that cut against your grain - like training a new employee.
I did not start training this employee because I liked her (although I do, she's definitely easy on the eyes) but because our mutual manager instructed me to. Therefore, it became part of my performance assessment to make sure that she was trained adequately and to the company standards.
When you take that responsibility on, you also take the responsibility for vetting that users' work until it passes code reviews and unit tests on its own. So by that metric, you're taking on a huge responsibility to protect "society" from the inaction or poor action of the newbie programmer. And that's part of your job. If it's not, then don't do it. But if it is, then suck it up and do the best job you can, and at the end of the day you'll have a quality software project AND an employee who can help deliver more of them.
Mit der Dummheit kämpfen Götter selbst vergebens.
I had a very similar assignment, and identical concerns with my final project at school. I've programmed for years and my friend/partner didn't have as much experience as me.
We tried to split up everything evenly. We broke down the application in to "actions" and drew use case diagrams for everything so we knew everything that the app needed to do from front to back.
After diagramming that, we turned those into class diagrams and a database diagram (which he knew how to do well).
From there we split into what we knew best. He designed the entire UI and I architected the solution and created blank projects with blank method headers. This made it really easy for him to start filling in the code.
All he needed to do was look at the method signature, read the comments, and write code to accomplish that atomic class. Rince, lather, repeat.
We ended up getting an A+ in the course and he learned a lot about coding.
--TE
The best way to bring up a newbie in pair programming is to give her simple stuff that she can do reasonably quickly and well enough. The most common highly delegatable by far for text-based programmers like me is translation scripts. It's a breeze to specify; You need to figure out what other programs you are going to interface with and then just tell them what you need in and out. Best to have real files to work with. For example, in my field I use a lot of distance matrixes that consist of an array of labels and a 2-dimension square of numbers that is diagonally symmettric; but there are many different formats for these and my CompLearn system only supports one text matrix format. So already there are a bunch of simple translation programs that I can easily delegate by saying "see this distance matrix output from program X?" Translate it to something that works with CompLearn! This is also useful for the output side of most programs that need to work with the real world. And of course the venerable and highly useful HTML screen scraper is a great subtype of this big class of programs. The reasons this is so good to delegate are as follows:
My favorite language for this kind of thing is Ruby, but I think Perl or Python would be fine too; anything that supports regexp and decent strings is a winner.
Happy Pair Programming and good luck! Rudi
Since your partner doesn't have as much experience, let them be on top for the first few times...
Oh. Wait.
When I first started coding, in a serious manner, I had a guy work with me on a few projects. What would end up happening is that he'd do the main design, the control classes, and the manipulation of the data structures. I got to do the more tedious details, where a mistake wasn't the end of the world... since it wasn't too involved in the actual logic of the program.
In the end, we came out alright, because my less experienced self did the majority of the harsh time-consuming things (in my case, it was the formatting of the data output), while he did the more "interesting" things, but the more experience necessary things too. What he wrote leveraged what I wrote, and glued it all together.
You need to restart your computer. Hold down the Power button for several seconds or press the Restart button.
From the poster:
However, while I'm far from l33t, I've several years more experience than my partner. Are there effective techniques for pair programming with a wide gap in talent?
Equating "talent" with "experience" is going to get him into trouble... anyone that lacks talent (at whatever task) will have a tough time either understanding what a more experienced mentor is trying to get across, or they'll have a problem adopting a suggestion from a brilliant protege.
Less is more.
I used to program, and I consider myself fairly decent at it. Having only seen the computer game Tetris, and in 1988 using an IBM PS/2 30 (with a MCGA and no known interface to it), I managed to hack the interface in a week or so, and in a little over a weekend I programmed a tetris game using it. I also wrote my own vector drawing program, my own ASM operating system... converted Debug to a more full=fledged assembler... and I really loved having the Borland Ref. Manual to help me use all those handy little functions.
So I don't consider myself a beginner.
But I never figured out how to get a hold of, and use, all of these libraries. I sit here with Linux running, writing my own C code. Yeah, I know there are lots of useful functions out there. But I need a good reference to use the libraries; and I just never learned how.
Would you or someone like to clue me in?
Correct Horse Battery Staple: 72 bits of entropy. Enter "Correct H" into google. When it generates the phrase, that's
Let me preface this by saying that I would almost agree, except that zero-sum is too high an estimation of job reviews. At the place where I work, the managers are told to give reviews on a score of 1-5; and not 5, because that score is reserved only for the company president's boss; and not 4 -- that's reserved for the president. And 3 really would imply that the person should be the manager. So mostly, 1 and 2 are all that can be given out, and the manager should feel free to give a single "3" score wherever he feels that the person is performing especially well. 1 and 2, of course, are "not acceptable" and "barely acceptable."
Point being, that the job reviews have no basis in reality. They are a specific lie, for the specific purpose of denying raises.
So let me propose a number of scenarios, and the specific response:
(1) Benefits turn out to be of negligible value. Response: Factor in benefits as a slight negative value -- the cost of the time that it's going to waste. Pick a job with a higher salary.
(2) Job reviews are nonsense. Response: Pick a job with a higher initial salary, and change jobs as often as you can get a better wage.
(3) Employers start pushing for more unpaid overtime. Response: As much time as you give to the employer under pressure, spend that much time applying for other positions elsewhere.
In the end, the employment game itself is probably a worse-than-zero sum game, for the reason that the employers seem to view their employees as their primary enemy, followed only by their own boss and their customers. When that happens, things are going to break down. To be honest, the person who trusts in other people is headed for disappointment.
That said, I've found that trusting in God has not disappointed. The job I have, I have because He wants me there, not because it's a good place to work. But the work that He has me doing is among those who have no better options. And that's different from the work my employer has me doing. I accept the second as being the cost of the first. Meanwhile, by the grace of God I can be loyal and faithful at my work, and for the most part, not rebel. To me, the sum situation is worth more than salary, job reviews, benefits, or whatnot. But I can definitely understand that the current situation is untenable for most other people. At least, though, there is a response for those who need to move on.
Correct Horse Battery Staple: 72 bits of entropy. Enter "Correct H" into google. When it generates the phrase, that's
Yes, I can help. Learn a different programming language!
Seriously. You only re-use code in C when you really, really have to, because it's so intensely painful to do, and writing libraries is difficult and tiresome. Every time you want to pass a reference around, you have to decide who's going to free() it. If you want to get in the habit of reusing other people's code, learn a language with a stronger re-use culture. You should anyway; far too much new code is written in C when there are better alternatives with automatic memory management.
I like Python, but you might choose Ruby, or Java, or C#, or Haskell, or OCaml, or even Perl. In any of these languages, you'll quickly get into the habit of seeing if someone's already solved your problem, because code re-use is so much less painful.
Xenu loves you!
Sounds like this will be your first experience with how pair programming often works in the real world.
Learning how to communicate at different levels and still produce an effective pair is your learning experience you'll take away from this, while the other guy is soaking up your programming experience.
You'll be seeing this scenario again in the job world... think about what you can learn from it to make the next time easier.
+++OK ATH
Moral of the story is the pairing will be what you make of it. If your goal is to be an elitist ass and run people off it is easy enouth to do, but in the end you're just hurting yourself.
"Can there be a Klein bottle that is an efficient and effective beer pitcher?"
Recently, I had to complete a research paper on distributed programming for the Agile 2006 Conference in a two day weekend. Russian XP expert and project leader, Anton Viktorov, flew into Boston from St. Petersburg to help write up the SirsiDynix project. Over 1,000,000 lines of code were written in record time by a set of Java teams distributed across Utah, Colorado, Canada and Russia. As a pair, we had widely divergent experience. Starsoft Labs, the leading XP shop in Russia, was selected as a partner by Scrum company, SirsiDynix, to replace a large library system installed at over 12,500 sites worldwide. CTO Jack Blount, formerly COO of Borland, ran the project as a distributed Scrum of Scrums with individual teams distributed across geographies. Anton had been pair programming for years at StarSoft Labs with little experience writing research papers. I had over 20 years experience writing research papers and 13 years of Scrum. We decided we better pair write the paper to meet our two day deadline in the middle of a Boston blizzard. I did most of the wordsmithing as he framed the details of the project. The SirsiDynix/StarSoft 56-person distributed Java team was as productive as a 6 person colocated team using Scrum. Needless to say, we pair wrote the research paper in record time. You can judge the result for yourself at the ScrumAlliance site. See: Sutherland, J., Viktorov, A., and Blount, J. (2006) Distributed Scrum: Agile Project Management with Outsourced Development Teams. Submitted to Agile 2006, Minneapolis, July 23-28. http://scrumalliance.org/index.php/scrum_alliance/ for_everyone/resources/scrum_articles/distributed_ scrum_agile_project_management_with_outsourced_dev elopment
more experience != more talent
X-treme programming is all the rage now, lucky you you just graduated early :)
Pedantry and conventional wisdom, plenty there are in your replies :)
Think out of the box, but wear a raincoat.
Asymmetric programming as in asymmetric warfare.
NUMA
If someone likes doing something then let them do it as it is more efficient then wasting time and energy making someone do what they don't like :)
Walk backwards until you get where you both are now.
Generate the expected output then figure how to get the computer there, both of you team up on the one Professor that won't grade on the curve the third member of your team the computer.
Time is your friend if you don't let someone else make it your enemy. Thinking about a deadline obviously wastes time better used on just about anything else.
Teaching is the best form of learning.
Of the 4 dimensions light prefers the geodesic in time. Your working surface might just as well be hyperbolic or not. Hint: Static structures with the shortest timelines for logic flow :) One can build the road and the other drive the car and swap every now and then.
You can work with anybody if they can work with you.
5 minutes of communication, 20 minutes of work, 2 hours of sleep.
Unless life and death internal conflict is the issue at stake your personal state's of mind during the journey will mean little at the victory celebration even if you never speak to each other again.
Even if you did all the work yourself you would be no worse off than if you were on the project by yourself except that you wouldn't get the 20% credit expected for learning teamwork in the latter case.
In life you will either work with your equal, or someone superior or someone inferior. Working with your equal is usually the most difficult especially if you get along and make the same mistakes ;)
Different folks are equal at different times.
Objects, Structured Programming, minimal proofing (Logic envelopes approaching a convex hull, but don't waste time on the optimal fit as soon as you find a sufficient fit). One way in one way out if the predicate is satisfied, else exception until a wrapping predicate is satisfied.
Use your tools, but don't make your work dependent upon the tool.
Sparsely document what is not obvious, otherwise don't waste time on non executables.