As some of you may know, Derek and I have been working on a few projects (Project Win) over the past months. We started these projects in February and worked through until May where we decided to go our separate ways for a little bit.
Although none of our projects made it to deployment, we still learned some invaluable lessons:
Mental Stamina
When you work on a project by yourself you have the luxury of working at your own pace. Each stage of planning, design, development and testing is done in one way or another, but in your own way and at your own pace.
When you work in a group though, you literally need to synchronize your work habits with your partner’s. You need to convince yourself that Derek is right, and you really need to do more design on Component A when you would much rather be coding up Component B. This will be easy to do on some days, and difficult to do on others. Its hard, its stressful, and it strains you, but a lot of the times you have to sacrifice your own desires for the sake of the project.
The Little Things Matter
Its the little things that count, and a bunch of little things stacked up together can have a major impact on performance. I’ll be the first to admit that I didn’t work at 100% capacity. Meeting downtown every day for a full day’s worth of work right after exam season wasn’t as fun as I thought it’d be. I thought that I superman and that I’d be able to work through it, but I was totally wiped out from the previous emester. I was okay to work for the first few days, but after that both my performance and my patience dropped. Derek knew this and I knew this. Be aware of your own body, and know when to stop.
On another note, there are little things that you can do to help improve morale. Early-morning Reddit sessions and afternoon Timbit runs really helped us clear our heads and get us through the day. Find out what works for you and your team and use it.
Healthy Discussion (or Arguments) are Vital
This is more relevant to the design stage of the project. Healthy discussion between group members can lead to great ideas and eliminate bad ones. Bad discussions can be poisonous, so avoid them at all costs.
How did we avoid poisonous discussions? Well, Derek and I agreed that whatever happens, neither one of us would be so mad that we couldn’t make it out to lunch (PBS? lol). Thankfully, we never really got mad in any of our discussions. The key is that we never made personal attacks on the other person(calling someone a noob-face doesn’t count). If you can keep the discussions positive and on-topic, then I think you’re good to go.
One of the dangers of having lots of discussions is that they can go on for a very long time. This happened to us, and that’s why we didn’t get much progress in the time that we had. At the end of the day, you need someone to make an ultimate and final decision. Discussion is good, but indecisiveness will just leave you stranded.
Written Documentation
I cannot emphasis this point enough: Write Stuff Down.
I know everyone says that documentation is key to success, documentation is necessary for team coherency, etc. etc.
Let me make it simple. When you work on your own project, you can keep all of the project details in your head, you don’t need to write anything down, etc. That’s great, good for you, that’s how I roll too.
But when you work in a group, your partner won’t have your perfect memory. Write down your design decisions on something that everyone can see so that each team member has at least some sense of what’s going on in the project. This is even more important if your team spends a lot of time discussing the design. We’ve had morning meetings where we’d try to start work on features that were “locked in” from the previous day’s discussions, but we’d have no idea what to do on because nobody remembers the final decisions.
Keep a wiki, keep a blog, whatever; just make it public and keep it up-to-date. It helps to maintain the overall project vision,and it comes in handy when you start dividing the tasks.
Don’t Be Afraid to Ditch It
Cognitive dissonance is a big problem with programmer; you believe in your code so much that you literally trick your mind into thinking that everything is going according to plan. Everything makes sense to you in your head, so naturally the code must behave perfectly when it runs. This is a big problem, and you need to force yourself away from the project and give it a serious review (or hell, ask someone else to do it for you).
If you find that the code is getting messy, cluttered or is just downright wrong; don’t be afraid to throw it away and start over. You won’t be wasting it; I mean, its just data after all. The rewrite will go much faster and the code will be much better as a result. (see Plan to Throw One Away).
Speed Is Your Friend
Don’t get too attached or caught up to any particular idea. Pick it up, evaluate it, and run with it. If it works out, great, if not, find something better. Work quickly, and work smartly.
I’d like to say that we did this a lot, but it wasn’t until we failed for a few weeks that we really got into the habit of working fast.
