SHARE:
Uncategorized

Playing Well With Others

Flatiron School / 12 June 2013

The following is a guest post by Katie Ishibashi and originally appeared on her blog. Katie is currently a student at The Flatiron School. You can follow her on Twitter here.

Group coding at The Flatiron School was new to me. I’ve had several jobs in the past that have involved coding, and they have never been exactly social. Generally, I would meet with non-techies to find out what kind of web thing they, and go back to my desk and make said thing. That was the entire action sequence. I learned a lot this way, in part because the nonprofits I worked for often had no one else on staff who could solve a problem. It was me and Google. I learned quite a bit this way, though this meant I had to learn much later in life not to write code that irritates other programmers. Someday, I shall introduce you to my session variable named George.

The biggest drawback to being a lone wolf is you completely miss the osmosis-type learning that occurs when you have other coders around you. If a technique did not come up when you were frantically searching Google for answers, you can easily miss it entirely. It’s also true that there’s no one to cross-examine you, and it’s easy to stop working once the damn thing works, even if it’s massively inefficient.

When I came to Flatiron, The closest I’ve ever come to collaborating with someone on a web endeavor has been something like “OK, you do the navigation, and I’ll do the footer.”

Pros

Different strengths This includes the obvious, like people knowing languages you don’t know, but also people who think in a different way than you do. I’ve only been team coding for a week, and already there have been several times when I’ve watched others easily solve problems that had me staring blankly, and vice versa.

Your random eccentricities don’t seep into code as much There’s no way you could get away with naming a variable George in a group.

It’s ridiculously easy to ask for help. At Flatiron, we often hear a lecture on a topic and then go to code in a group, and if there’s something in the lecture I don’t understand, there’s always someone in the group who can explain it to me.

Group jokes! We just wrote a program that tells the user it’s deleting their entire hard drive if they enter invalid input, and then stuck it on some likely marks. It was AMAZING. I occasionally tried to do this when I was on my own, but the joy did not compare. Jokes are funnier with many people in on them.

Cons

Other people’s random eccentricities sneak into the code, and you will not find them as charming as your own eccentricities Even though it’s harder to put your own eccentric touch on code in a group (Hi, George!), you do sometimes get outvoted in a group, and then have to sit there as the group goes down what you view as a strange path. There is very little you can do about this.

When a group gets bogged down, it REALLY gets bogged down Taking major coding detours as an individual is bad enough, but taking an irrelevant detour with the weight of four, really hard core people speeding along Detour Road means that you can get SERIOUSLY bogged down. You can write not only write test code to implement your detour, you can write four different versions of it, and then you can sit around discussing all of them for hours.

Guest Speaker: Sandi Metz Previous Post Yargh Next Post