Programming <3 Teamwork <3 Programming

In the past almost-three-weeks of already learning so much about Ruby and programming, I have also been enjoying another subject we have been studying and practicing - teamwork!! Given how we have been operating so far - being seated in groups, switching up those groups periodically, and seeing a reminder on every Ironboard pull request prompt to tag collaborators, it feels like this is as important for us to learn as are the technical aspects of programming. 

Why is it important for us, as beginning programmers, to learn how to develop with a team? Here's what stands out to me the most. There is so much to learn, and many minds are better than one. Already, our programs are getting bigger - they have gone from single files to multiple files and any day I am expecting them to grow more and more. How could one person manage increasingly complex programs? And even if they could, why would they want to? Most of us want to make programming our careers, and even though I have never had a programming job, I am 99% certain that teamwork will be a big part of it. Taking code and systems created by other people, learning the way they have functioned before we got there, and communicating our ideas for how to move the project forward will be essential. There are so many ways to do any one thing, whether it be creating an algorithm to solve a problem or constructing a method within a class, or even variable and method naming conventions. The way people do these things are reflections of how they think, and as a new developer, hearing about other people's thought processes helps me understand both problems and potential solutions better.

So, yes, kumbaya, yay teams, but let's also be real. Working with other people can be really challenging. How do we work as a team?...but also make sure we, as individuals, are learning what we need to learn and getting our Ironboard lights green?! Based on my experience these last 3 weeks (and the previous 30 years of my life), these are my suggestions about how to approach team work.

Give What You Can Offer, Ask For What You Need: At the beginning of the Flatiron day (or, more generally, at the beginning of any project), start off by finding out what everyone's expectations and learning goals are. For example, ask the group, "Is there anything you want to work on together today?" Things move pretty fast around here (and I bet that will happen at a job, too), and from what our instructors have been telling us, it is important to stay together in our learning. That said, people also have to go at their own pace. Checking in about people's expectations - at the beginning of a project, and periodically throughout - is a way to see where everyone is at, and collectively decide on the best course of action from there.

Ask Questions. Also, Tell Me More: I am so fascinated by all the many ways to do things. So far, this is one of my favorite parts of programming. Be curious, ask questions, not just of your wise instructors, but also of your wise classmates. "How did you come up with that solution?" or "Tell me more about the way you did that." are ways to start those conversations, which are actually helpful for both parties, not just the person who is asking the question. When we explain our reasoning, we deepen our understanding and  perhaps it might even reveal connections or decisions we had made that we weren't conscious of while we were programming. Rubber ducking makes us better programmers. 

As perpetual beginners, let's remember:
     A small group of thoughtful people could change the world. Indeed, it's the only thing
     that ever has - Margaret Mead (maybe)

Go team!!!