Hello my friend and I would like to build a First person dungeon crawler. I am just curious though I feel as everything can be done with just one programmer. How would you guys split up the workload?
I see 2 scenarios.
-
Split it by feature. You’ve got a design doc (Right? RIGHT!?) so this should be easy. Don’t try to make things “fair” as far as work load if that’s what you’re worried about. Just each pick a feature you know you can accomplish and are passionate about, and based on priority as is written in your design doc (right? … RIGHT!?).
-
Pair programming. This is a real thing. Google it. I’ve done this in the past and it’s actually really fun and works well. You’re only coding 50% as fast, but you’re also coding 100% more efficiently if both people are doing their jobs. Essentially, one person types, and the other person communicates design goals, syntax errors, or just stupid stuff the coder is doing. I’d usually be the coder and I’d hear feedback while typing such as “Actually that list won’t work since indexing won’t be reliable in this case. You should use a Dictionary.” Or something like, “You screwed up right there. That won’t compile.” Or the best ones: "We’ll need to incorporate X as well, so we should make those methods virtual and expose those fields or… " TL;DR One person is constantly considering the bigger picture while the other person pecks away at the nitty gritty. It will feel slower but the quality of code shoots through the roof. It’s also easily don’t remotely with things like Google Hangout’s screen share functionality.
3 Likes
Possible approaches:
- Give two programmers two different systems that barely overlap.
- Using JIRA or another bugtracking software establish list of features/problems that needs to be fixed/implemented, let people pick one issue at a time then submit it into repository.
Also make sure both programmers are familiar with git or similarly powerful version control system.
As for pair programming… I don’t believe in it and never heard of it actually being used.
3 Likes
If theres only two of you, which one is the artist?
1 Like
Pair programming? Isn’t that where one person uses the mouse and the other the keyboard?
2 Likes
Nah man, two people, one keyboard
Obviously it makes you type code twice as efficiently.
4 Likes
GitLab now has a Kanban board, which is a pretty easy and standard way of task tracking. Jira is great if you know Jira, otherwise it is a massive time sink.
And yeah, I tried pair programming on some projects a few times. It never worked.
It’s where one guy does all the programming and the other one sits there pointing out the stupid mistakes. 
6 Likes
I think I had extremeprogramming book collecting dust somewhere. It was supposed to be an ultimate form of enlightment or something. IIRC the idea is that whoever isn’t writing at the moment will be instantly spotting mistakes
https://en.wikipedia.org/wiki/Pair_programming
I think that while it might in theory provide some benefits, there’s extra issue of making sure that people in the pair are sorta “compatible” to each other. Wiki also says that it only works in sitaution which require high degree of creativity, and when both programmers know what needs to be done, it results in productivity drop instead.
1 Like
I think it’s totally insane. It’s an incredibly expensive way to program. And I’m not convinced that it actually helps much.
There is plenty of space for collaboration and peer review while designing the code. But that belongs on the white board, not while the code is being typed into the computer.
Who does strategy as they type?
According to the article on Wikipedia the resulting code has 15% fewer defects on average. If you were developing code for a very sensitive system you might be able to justify the costs. For game development though I don’t believe you’ll see that situation very often at all.
Only one of them is typing at any one time. Strategy would be discussed prior to coding sessions and the person typing would be the one with the most experience with the strategy selected.
1 Like
I wouldn’t call it insane, it has roughly the same logic as “rubber duck programming”, only the duck is now intelligent and has its own opinion.
Wikipedia article provides decent outline of the method, you should check it out.
My main issue is that for this thing to work very efficiently you’d either need a level of trust comparable to “childhood friend” or “spouse”, or you’ll need to be in incredibly friendly culture. It is also unsuitable for introverted types. As I said, I don’t practice this and probably wouldn’t, but I see how it could work.
Yeah, there isn’t much creativity on the coding side in gamedev. (IIRC)The whole extreme programming thing came from java environment and with presumption that you’re making applications at insane speed, and the applications are “one of the kind”. Meaning this kind of technique would be definitely suitable for those scenarios.
1 Like
Pair programming works. I’ve done it a few times with a junior developer. In these kind of situations it is quite effective and I can see it working overall even for very experienced folks.
What happens is when you’re writing code… you’re often just quickly dumping things out of your brain and you may make a typo here or forget to declare a variable there or simply forget to take into account some impact or dependency or whatever. Could be anything really… basically any of the things that make it so when you write some code there is an issue of one kind or another.
For the observer it is far easier to see these things. Because the programmer’s mind is looking at the tree. Observer can scan and see the entire forest. Think of watching one of the umpteen Unity gamedev videos out there where someone is writing code and you can instantly see they forgot to do something. They finish the code. Test. And wonder why it doesn’t work. Then finally they see the same thing that you noticed 10 minutes ago. It’s this kind of thing.
It’s not something I see as being cost effective or efficient though. Not as much as having the other programmer actually programming. Testing continually and iteratively reduces errors in code.
5 Likes
I found pair programming to be a good way of teaching as well. I don’t know what kind of combative personalities some people seem to think everyone has but most people I work with willingly accept help/criticism and working together on code is actually pretty fun and a very efficient way of communicating.
I wouldn’t do it all the time or anything, but a couple times a week I find it useful to sit with junior team members and practice this kind of thing. The feedback I have gotten is that they would like to do this more, not less. Unfortunately my time does not allow that.
6 Likes
I was with a company about 10 years ago that jumped on the XP bandwagon. We tried PP and found that there were often personality conflicts which made it a pain to manage and slowed development to a crawl. We fell back to our agile-esque workflow and tuned how we did code reviews. I have heard anecdotes about people making it work, but overall no one I know actually uses it anymore.
In my current company, pairs just form spontaneously to solve specific problems. Instead of investing in PP, I invest in dedicated QA, automated testing, DevOps, and we collect data on every aspect of our systems in real-time in order to find and diagnose problems, sometimes before they are even reported.
2 Likes
This is kind of a blanket response to everyone since you all have touched on various aspects.
Pair programming is definitely not for everyone, and less for every situation. In our case where it worked very well was with one experienced coder and one not. It was over a VC and we used screenshare, so there wasn’t any personal bubble issues, although I don’t believe there would have been unless one of had had chili or something.
In the OP’s case, it’s a team of 2, not a large company. It could work, it could not. It might be worth trying, or it might not.
2 Likes