Sometimes…

Sometimes it’s not stupidity, or ignorance, or shortness of time, or laziness, or lack of energy, or apathy, or antipathy, or a “lack of interpersonal skills”, or immaturity, or incompetence, or arrogance, or any of those other things that makes a team project fail.

Sometimes you just overestimate the ability of your teammates to work independently.

Sometimes it’s just that moment when you realize that you have 6 days and that the other members of you team simply do not have… it. That thing that enables someone to be able to sit and code for hours and produce something that works and compiles and comes close to doing what it needs to do. No questions asked, no chit-chat required; if it doesn’t work, it better fake it convincingly; if you don’t know what it should do, read the specs and interpret; if it bombs, rehash and tinker efficiently until the explosion becomes something pretty enough to glaze over the watchers’ eyes.

Sometimes its just speed. Who can type and code and understand the fastest and produce the most precise and accurate code in their speed? Six days with exams and sleep and work and three other classes isn’t a long period of time.

Sometimes… sometimes everyone does their level best and you still end up with more than your fair share of a project.

2 thoughts on “Sometimes…”

  1. Sometimes usually ALWAYS. Can you think of (/remember) a group project that you have worked on (in the past), where at the end of it all, you were glad to have been working with Pat? Or where you felt like Pat put in as much effort as you did? or where Pat made it look like you didn’t do anything? No. You can’t (I don’t think so anyway, i’m sure you can respond for yourself). You are a hard workin mammajamma. And u ma’am know lots o shit. You are not meant to work in a group. I feel like you would do much better leading a group. Not in the whole, “Oh, praise ye, someothercommonbullshit, you are a leader” kind of way, but instead a way where I feel like if I let you “hire” a team, and then see a project through, the quality and efficiency would be as has never been seen. I hope never to be your industrial competition.

  2. Not always. Earlier this term, I worked on a group project in Operating Systems that included a guy who seemed very much like me in working style–very independent, very willing to tinker to make things work. He was, of course, willing to help all the teammates where needed, but he never immediately suggested that we all sit four to a computer and spend time hashing out a program. We designed together, but we didn’t code together. (I thoroughly enjoyed working with him, too; dude was hella smart in Linux and a quick learner of C. And he was a computer engineer, too; who’da thunk it? :-P)

    I’m just finding that more people think “group project” means “group coding” than what I thought. A blunder on my part, perhaps, although when I did try to help out one of my teammembers (on my current project) by giving him a coding buddy, the coding buddy sort of wandered off…

    I’m also not complaining about my current team, I don’t think. 🙂 Or I don’t mean to. They (we) are busting their asses–and you can’t ask for anything more than that, or be disappointed by that–but there are few scenarios that I can calculate in which we have something approaching a working product to demo by next Monday. Most of those involve me taking the hit in other classes (my second project, tests, etc.) to write about 80+% of the remaining code. Other scenarios involve my freshman shaping up and becoming the genius I think he has the potential to be. I don’t think the latter is going to happen, what with him also having a second project.

    You live, you learn, I guess. I think I’ll work with experienced seniors (like the OS guy) for the remainder of my time at Rose. Yeah, that’ll do it. 😉

Comments are closed.