My teammates screwed me (not boring)



  • I'm writing this to let off a little steam about a school project I recently finished that was barely/non-functional because my teammates screwed me.

    I know, this sounds really really boring, but wait it gets interesting.  I was not screwed because a lazy team left me stuck with all the work.  Relative to the way things actually went, I would be overjoyed if I had just had to do most of the project myself.  The problem was I had teammates that would do a bit of work on something, get it half working or not working at all and then go down in flames defending their design decision.

    The project was going to try and locate the origin of an acoustic signal.  A week after I explained the approach to the team, two of my teammates come up to me very concerned a week later because they found that the proposed frequency was regulated by the FCC.  They didn't understand that the FCC regulates radio, TV, etc which are ELECTROMAGNETIC waves, whereas ACOUSTIC waves are something completely different.  Electrical and physics considerations are probably not the central expertise of most of the people who read this site, but I think this is so glaring even an intelligent layman wouldn't make this error.  Even worse, after I explained this to them it took weeks for them to really come around.

    My plan was to use a Java based system to do HTML rendering.  After I explain this, one of the people on the team comes up to me and explains that he has written an HTML parser before, so he could write a custom HTML renderer for the project.  Now, the entire Java application took 150 lines to implement.  And he is proposing to essentially implement a web browser from scratch.

    The punchline is, after this level of incompetence in the design phase, and messing around for months spinning their wheels but not getting much done in implementation I step in to start patching some of the glaring holes.  And get trashed for it.  I am accused of incompetence, laziness, you name it.  Because pieces of the project which were other people's responsibility, and had been neglected for 3/4's of the duration of the assignment were not getting done in a timely fashion for integration testing.  So, I get the hot potatoe and the blame.

    But here's the thing, just like that custom HTML renderer, some of my teammates were completely out of touch with reality on what they were capable of.  So, they insisted on getting broader responsibilities.  Then, didn't even understand what they had taken on and got sidetracked on very easy things.  The hard tasks were left gathering dust, until I started working on them having completed my primary responsibilities.  And then these same people turn around and accuse me of being some kind of cowboy because I just start working on tasks on my own.

    To keep this all from sounding like alot of hot air, here is one example of the kind of stupid bullshit that was getting implemented.  The purpose of this function is to convert a byte sized integer to a string.  The ANSI C sprintf() was avilable but this person was most likely unaware of it.


    unsigned char* btos(unsigned char x)
    {
    int i = 0;
    unsigned char* s = new unsigned char[4];

    if(x > 200)
    {
    *(s + i) = '2';
    ++i;
    x -= 200;
    }
    else if(x > 100)
    {
    *(s + i) = '1';
    ++i;
    x -= 100;
    }

    if(x >= 90)
    {
    *(s + i) = '9';
    ++i;
    x -= 90;
    }
    else if(x >= 80)
    {
    *(s + i) = '8';
    ++i;
    x -= 80;
    }
    else if(x >= 70)
    {
    *(s + i) = '7';
    ++i;
    x -= 70;
    }
    else if(x >= 60)
    {
    *(s + i) = '6';
    ++i;
    x -= 60;
    }
    else if(x >= 50)
    {
    *(s + i) = '5';
    ++i;

    x -= 50;
    }
    else if(x >= 40)
    {
    *(s + i) = '4';
    ++i;
    x -= 40;
    }
    else if(x >= 30)
    {
    *(s + i) = '3';
    ++i;
    x -= 30;
    }
    else if(x >= 20)
    {
    *(s + i) = '2';
    ++i;
    x -= 20;
    }
    else if(x >= 10)
    {
    *(s + i) = '1';
    ++i;
    x -= 10;
    }

    if(x == 9)
    {
    *(s + i) = '9';
    ++i;
    x -= 9;
    }
    else if(x == 8)
    {
    *(s + i) = '8';
    ++i;
    x -= 8;
    }
    else if(x == 7)
    {
    *(s + i) = '7';
    ++i;
    x -= 7;
    }
    else if(x == 6)
    {
    *(s + i) = '6';
    ++i;
    x -= 6;
    }
    else if(x == 5)
    {
    *(s + i) = '5';
    ++i;
    x -= 5;
    }
    else if(x == 4)
    {
    *(s + i) = '4';
    ++i;
    x -= 4;
    }
    else if(x == 3)
    {
    *(s + i) = '3';
    ++i;
    x -= 3;
    }
    else if(x == 2)
    {
    *(s + i) = '2';
    ++i;
    x -= 2;
    }
    else if(x == 1)
    {
    *(s + i) = '1';
    ++i;
    x -= 10;
    }
    else
    {
    *(s + i) = '0';
    ++i;
    }
    *(s + i) = '\0';
    return s;
    }

     



  • Talk to the professor about it. If he's not a jerk and/or idiot he'll understand, although if you haven't done so already you really should have when the problems started.



  • Thank you for the advice.  The project is actually over however.  I had talked to the professor, but she was very adamant that the point of the project was to force people to work together in a group.  The school also did a very poor job of communicating requirements to the students, so nobody knew exactly what the grading criteria were or anything like that.

     

    I also made the mistake of thinking that the rest of the group would be able to paint by numbers if I laid things out for them.  The problem became that they became totally lost in the details.  It felt like a sinking ship taking on water -- more and more time and effort got put into implementing the pieces in incredibly inefficient and time consuming ways.  Once implemented, the project was locked in to using marginally functional pieces.

     

    As you'd expect from incompetent engineers -- testing was highly erratic and things were getting declared "working" that were nowhere close to working.

     

    Compounding the whole thing though, I got blamed instead of thanked for taking on additional responsibilities.  Pieces of the project were declared "working" which were in fact failing in exactly the ways I had predicted.  Literally, some recommendations I made were ignored for 4 months.  Then they finally came around to doing things the straight forward way and it is this "aw shucks" attitude that "we gave it our best shot".



  • I think the industry must take a good part of the blame here.  Colleges--at least the one I attended--take their walking orders from the industry, and "teamwork" is oe of the major emphases in their specifications.  Unfortunately, many instructors really have no idea of how to manage group dynamics.  They just assign teams, and let mob rule take its course.  It's really a shame, because effective team dynamics are obviously critical to the success of any large-scale development project.  To teach such dynamics, though, requires a much closer engagement in the group process.  Instructors should actually take time to sit in on group sessions, lay out and enforce ground rules for process, and have solid metrics to ensure that the process encourages the constructive, as opposed to the poisonous, aspects of group interaction.

     



  • Aaargh. I hate the fact that in school, if 3 of the 4 people are incompetant, the competant one gets yelled at. It's like they think that because the majority says the sky is pink, then it must be pink. Good luck on your next project.



  • Re: My teammates screwed me (boring)

    I suspect that this was less a programming test as a team-player test - put together awkward teams, give them an ambitious project and see how they cope.

    If this was the case I would have failed you. It sounds like you alienated the other members of the team and had a total lack of respect for boundaries. In the real world any programmer who takes it upon themselves to rework other peoples tasks without permission or consultation tend to find themselves wondering why they just got the sack.
     



  • mmm projects, the best team work in school projects is where your group agree's they suck and the person who can code the best, writes the code. someone else writes the documentation and the guy who sucks at everything but is still in school because he can smooth talk the teachers, defends the project.

    If you have a fourth guy, he sabotages the projects from the other groups. Since in most cases your grade will depend on the average quality of turned in projects.
     



  • @doublereedkurt said:

    Thank you for the advice.  The project is actually over however.  I had talked to the professor, but she was very adamant that the point of the project was to force people to work together in a group.  The school also did a very poor job of communicating requirements to the students, so nobody knew exactly what the grading criteria were or anything like that.

     

    My next comment to such professors was always: "So what you are trying to teach us here is that working in a group is a disaster and likely to result in projects floundering, and there's nothing you can do about it". Then I'd watch them try to wriggle out of it. If they tried to say I should have done something to solve the problems, I'd ask them what - and when they couldn't answer, I'd ask why we were being tested on things we hadn't been taught.

    It may not do anything about the problem, but it's fun to make the offending professor squirm. 



  • @asuffield said:


    My next comment to such professors was always: "So what you are trying to teach us here is that working in a group is a disaster and likely to result in projects floundering, and there's nothing you can do about it". Then I'd watch them try to wriggle out of it. If they tried to say I should have done something to solve the problems, I'd ask them what - and when they couldn't answer, I'd ask why we were being tested on things we hadn't been taught.

    It may not do anything about the problem, but it's fun to make the offending professor squirm. 

    If I was the professor, I'd respond with something along the lines of, "In the real world, you don't always get to pick your group. You have to learn to work with whoever's thrown at you, for better or for worse."    



  • @stratos said:

    mmm projects, the best team work in school projects is where your group agree's they suck and the person who can code the best, writes the code. someone else writes the documentation and the guy who sucks at everything but is still in school because he can smooth talk the teachers, defends the project.

    If you have a fourth guy, he sabotages the projects from the other groups. Since in most cases your grade will depend on the average quality of turned in projects.
     

    Yup - that's always worked for me!



  • @rbowes said:

    @asuffield said:

    My next comment to such professors was always: "So what you are trying to teach us here is that working in a group is a disaster and likely to result in projects floundering, and there's nothing you can do about it". Then I'd watch them try to wriggle out of it. If they tried to say I should have done something to solve the problems, I'd ask them what - and when they couldn't answer, I'd ask why we were being tested on things we hadn't been taught.

    It may not do anything about the problem, but it's fun to make the offending professor squirm. 

    If I was the professor, I'd respond with something along the lines of, "In the real world, you don't always get to pick your group. You have to learn to work with whoever's thrown at you, for better or for worse."    

    Response: "I have most definitely learned that. Do I get an A?"

    You have to realise that I'm subtly pointing out to the professor that there are rules about this stuff, and if I could be bothered to go to the hassle, I could make some trouble for them about it - they are actually supposed to teach you the stuff that you're graded on. It never happened to any of my classes, but while I was at university there were a couple of courses that got shot down by the moderators after the event (which means all the people registered for it get full marks and the professor gets chewed out by the board; you do not want this to happen to one of your courses before you get tenure).



  • Was this a course on Engineering, or a course on Project Management?

    The project was an exercise in Project Management.  If it was an Engineering course, the professor apparently expected you to already know about project management, or figure it out for yourself on the fly.  (Over in the Project Management course, I suppose they give the same assignment.  The students use iPods all the time so they know about acoustics and electronics or can quickly learn enough to get the job done.)

    (When I actually took a Project Managment course, I was not at all surprised to find out that there is a lot to learn, and people don't automatically know all about it.)



  • @stratos said:

    mmm projects, the best team work in school projects is where your group agree's they suck and the person who can code the best, writes the code. someone else writes the documentation and the guy who sucks at everything but is still in school because he can smooth talk the teachers, defends the project.

    If you have a fourth guy, he sabotages the projects from the other groups. Since in most cases your grade will depend on the average quality of turned in projects.
     

    This is true genius!  In fact, I believe it works very well in the *real* world too.  Between school and work, I have played at least two of the roles in this pattern. 

    The same pattern can be applied in both school and work in various situations.  Even if all three developers can agree that their skills are equivilent in any of the roles, but each has outside constraints (such as other deadlines, planned hangovers, etc), then they can choose to work functionaly disjointly. 

     



  • I feel your pain, I had some projects go down in flames due to incompetent team mates at uni.  Just take satisfaction in the fact that there's a good chance they'll either be serving you coffee in Nero or working data entry later on in life :¬)



  • I hear everyone consoling you in your attempt at this project, but I see another side of this.

    Reading through the text I see where you basically seemed to say "my way is right, heres how to do it."  Then doing your work then looking back at others work and seeing it isn't how YOU would have done it and decide to just start re-writing it.

    I don't care if you are the best on the team, team dynamics require you to work within the team itself.  Sometimes the best way to do something is not the way it should be done because some members just can't grasp the idea.  Remember there are numerous ways to do something right just as there are numerous ways to do something wrong.

    I agree the code snippet you posted was bad, but claiming the entire team was useless and you were the only one worth anything at all just makes me think you believe yourself to be above everyone all the time.  Remember, you can write bad code too. 



  • Wow, that code sucks.  How does your department let them get through?  The head of my department chewed out my class a few weeks ago for not using the optimal data structure for a given problem, and the problem had nothing to do with data structures!  (Well beyond what any problem has)

    Anybody who submited that code should have a sit down with the department head and be asked if they really want to be programming computers for a living...

    Oh, and you get a WTF award for suggesting the use of sprintf, which has been deprecated for about 10+ years[1] now! Please use snprintf for all your string formatting needs, or asprintf, or damnit, ANYTHING but sprintf.  sprintf should not exist in your vocabulary, it has been the cause of thousands upon thousands of buffer overflows.

    [1] Well in real C APIs at least, some "other" APIs have only deprecated the thing for around 5 years.  :) 


    Err,

    *gets off of anti-sprintf soap box* 



  • @KattMan said:

    I hear everyone consoling you in your attempt at this project, but I see another side of this.

    Reading through the text I see where you basically seemed to say "my way is right, heres how to do it."  Then doing your work then looking back at others work and seeing it isn't how YOU would have done it and decide to just start re-writing it.

    I don't care if you are the best on the team, team dynamics require you to work within the team itself.  Sometimes the best way to do something is not the way it should be done because some members just can't grasp the idea.  Remember there are numerous ways to do something right just as there are numerous ways to do something wrong.

    I agree the code snippet you posted was bad, but claiming the entire team was useless and you were the only one worth anything at all just makes me think you believe yourself to be above everyone all the time.  Remember, you can write bad code too. 

     
    I agree with you 100% about doing things the way the team can understand.  The project was a two semester senior design project in electrical engineering.  I came up with the basic idea for the project, did the high level architecture, then we divvied it up and went to work.  Fast forward 5 months
    and the analog circuit design is in a complete shambles.  With two months left out of the 7 months of the design/build/test phase of the project the simpler circuit is sort of half working, and the harder circuit is at square 1.  In fact, it is really at square -1 because an example design I provided to use as a starting point in the architecture phase has apparently been forgotten.

     

    At this point I get the software to a working state and start working on the harder circuit which hasn't been started.  I'm sure analog circuit design is way outside of the expertise of most of the people that read this site.  Since the easier circuit is still flaky, I re-design it to be simpler and more robust and get all the parts needed to re-do it in one afternoon.  Now, keep in mind this is the sole product of the other person for 5 months of work.  The design that is going forward is a Frankenstein monster which is uses parts pointlessly.  There was no need for ANY ICs, the entire thing could be implemented with a handful of generic off the shelf resistors, capacitors, diodes, and transistors.  However, this person has managed to use 4 ICs.  Some of the ICs require external inductors, they need to be soldered in special ways, etc etc.  So what literally should have been a weekend worth of work has stretched out for months.

     

    So, now comes the part for the circuit that needs to be designed which should ACTUALLY take 2 months.  I'm trying very delicately to nudge this person along, but there is so much stupid floating around group meetings it is painful.  The guy who wrote that terrible C code I put at the beginning has an opinion on everything!  His core "competence" is working in low level C code and digital circuits.  He wants everything to be custom made.  In his opinion analog is better than digital, digital is better than software.  Decisions arose to move functionality out of circuits into software and out of analog into digital and he was against it both times!  The most basic thing in the world, that it is easier to do things in software than hardware and easier in digital hardware than analog hardware seems to be a completely alien concept!

     

    After working on the analog circuit for two weeks, it is ballooning out of control, the rough design is calling for something
    like 200 discrete components (versus less than 20 for the digital).  The simulation is not working and trying different circuit designs is a long and grueling process.  So, I take another look at digital.  My proposal to the group is that by just doing raw data acquisition from the transceiver and getting that into the digital circuit we can worry about finessing the data to extract the bitstream later.  Since the actual extraction circuit is in the FPGA, we can lay out and test the hardware and then the FPGA can continue to be modified up until the night before the demo without physically changing any of the circuits.

     

    This proposal is met by a complete shitstorm.  The guy who knows nothing but has an opinion on everything is convinced that analog is better than digital.  Now, he doesn't understand analog at all, and he thinks he knows a bit of digital (but actually designs digital circuits as well as he writes C).  I am accused of destroying the project by not consulting with the team.  I have "forced" the team down the digital route by working on a digital solution for 4 days!  Nevermind the other person whose job this was and didn't even start working on it for 4 months.  The deadline is now too close to change horses (this is the first deadline which actually got missed).

     

    So by the time the shitstorm hits, I actually have a Matlab simulation showing the digital decoding method will work, there are analog to digital converters in the mail, and a rough Verilog code has been written to confirm that the FPGA has enough resources.  Keep in mind this is all in 4 days!  All the analog circuit has going for it is a rough intuition about how it should work (MY rough intuition that I had to spoon feed to the "analog expert").  The digital circuit has a great deal of simulation and confirmation.  And I am accused of all kinds of things.  I am ATTACKED because I preemptively started working on something that should have been started months earlier but wasn't.

     

    On the one hand people are complaining because they say they are up till 3am in the lab working on this project.  On the other hand they say that laying out and soldering 200 components is no problem.  When I point out that the circuit layout can be frozen much earlier in a digital circuit than an analog one, I am accused of just wanting to do digital to get more time.  Like doing it in an easier way that opens more slack in the schedule is somehow a bad thing! 

     

    I guess what I am trying to say is that this was not a case of me pissing in other peoples corn flakes.  This was literally a case where I designed everything, and the other members of the group were sitting on the side throwing rocks at me.  One of them worked fine.  But, the other two had no positive suggestions to make, they just bitched non stop about how what I was doing was wrong.  And their arguments were irrational and ignorant.  After making the easy parts ridiculously hard, they want me to stop and consult them on how I approach the hard parts.  In the end they finally took an earlier design I had made (the analog circuit) and ran with it on their own because they thought they somehow knew better than I did how difficult it would be to get the circuit I DESIGNED working.  I predicted the ways that the circuit would fail.  The simple "naive" circuit would actually have so many problems that it would be better to do the circuit in the more complex but more robust way.  This approach goes "swoosh" 5 miles above the heads of my group mates.

     

    One week before the project is due, I am told that the analog circuit is working.  I really really want to believe this is the truth, that in the end they had pulled through.  The digital circuit just needs a small amount of testing to confirm that the analog to digital converters actually meet their spec, and it will be fine.  I have already laboriously mathematically simulated the entire circuit, as well as built a testbench and examined every internal register of the custom digital circuit to confirm that the behavior of the circuit agrees with the mathematical model.  I am told to STOP work on the digital circuit immediately because the analog is working.  I am still being polite despite having 10 kinds of bullshit thrown at me by the group.  So, I ask "should I continue working on the digital circuit as a backup just in case the analog runs into unexpected difficulties?"

     

    I am told, no stop working. The analog circuit is definitely working. 

     

    By this point I am emotionally and mentally exhausted.  My blood pressure has gone up so much over the past month that something that looks like a hickey has come out on my neck.  So, I go home.

     

    Three days later, I find out not only was the analog circuit not working, it was not working in the EXACT way I predicted it was not going to work.  The two dipshits had gone off and slapped a circuit together WITHOUT DOING ANY SIMULATION.  Then they didn't test the circuit properly and thought it was working when it really wasn't.  So they tried to get it working for a couple days and failed miserably, then gave up.  There were still 5 days left before the demo.  Other groups were in the lab working frantically.  They told me to stop because what I was doing was no longer necessary, when it was actually critically necessary.  Then they just gave up.  And didn't bother to tell me so I could get the alternative working.

     

    So, then it comes time to present the results (it turns out we didn't need to have everything working to graduate).  The night before the presentation, 10pm.  We have each thrown in some powerpoint slides.  The person that has fucked up the analog sees that I have some slides talking about the digital circuit and shits a brick.  "We had to pick the one that was further along and go with it"

     

    This is really the cap that made me pop my top and post it to this site.  Let me reiterate the chain of events:

    1 - architecture is laid out by me

    2 - architecture is changed to give a bigger part of the project to someone who is concerned they don't have enough to do

    3 - this person proceeds to fuck up the "little" piece which wasn't enough for them to do earlier and not even start on the hard part

    4 - I have to spoon feed one method of doing the hard part to this person

    5 - after working for a couple weeks I realize the simple method won't work, and revert to the initial architecture

    6 - I proceed to stay up till 6 am, cut class, and generally do everything in my power to get the circuit done in the most efficient way I can, working through mathematical verification, simulation, implementation, debugging, doing everything methodically and by the book to ensure that it will actually work

    6a - an endless stream of useless bullshit off the cuff criticisms come at me

    7 - the little piece FINALLY gets done, with 9/10ths of the project schedule already eaten up, the person decides to take my earlier design and start working on it

    8 - the earlier design for the hard part is slapped together WITHOUT SIMULATION OR MATHEMATICAL VERIFICATION

    9 - it is sloppily tested and declared working

    10 - I am ordered to stop working

    11 - I am not informed that it actually isn't working

    12 - I am ordered to remove any mention of the work that I was cutting class and raising my blood pressure for a month and a half to get done, because "we" decided to go with "the one that was further along"

     

    One last thing that probably needs a bit of explanation: the circuit was kind of a two stage process.  The easy part fed into the hard part.  Since the idiot who was fucking everything up had built the easy part, it was in that persons possession.  So, in order to do final integration testing I needed to physically have the easy part, which means I needed the cooperation of the idiot.  Also, the idiot had decided that they should be in charge and so took it upon themself to tell everyone else what to do. 



  • Another gem from the guy who wrote that horrible horrible C code:

    There was a small task of doing a little bit of linear algebra.  This was moving to software from a digital circuit.  I had to spend about a month nudging people to get them to come around to doing it in software.  (The fact that it was more and more obviously completely impractical in hardware helped).  So, we are emailing back and forth I say we should get this done quickly, if there is a time issue I could get it done but somebody should do it.

     


    The guy who made that C code says, "no no, I'll take care of it".  He then decides that the guy who was trying to do the linear algebra in hardware is being "obstinate"  and not giving him necessary information.  The math is available to everyone, as in "fill matrix A with these values, invert it and multiply by matrix B which is filled with these values, multiply the result by matrix C and the quantities of interest are the first three rows of the result".  So he spends two weeks DOING NOTHING because he DOESNT UNDERSTAND THE MATH and so thinks that the other guy has some secret voodoo which breaks it down further than that which he isn't sharing.

     

    After two weeks of doing nothing, I ask what is going on and manage to show him that the other guy isn't holding anything back.  Once again I offer to just do it, once again he says "no no I'll do it".  It is going to be done "next friday".

     

    Two weeks later, he comes up with some crazy bullshit hand-waving about why it isn't working yet.  Keep in mind all he has to do is transcribe some linear algebra from paper into C code.  He doesn't have to do any math or derive anything, just monkey see monkey do.

     

    Two weeks after that, it is "90% done".

     

    One week later, he explains that it is done, but not tested.  There is a simple way to generate test inputs to the math and confirm if the outputs line up properly.  He has not done this.  He asks me to re-do the EXACT SAME MATH in Matlab, then give it some randomly generated inputs and email him the inputs and outputs, so that he can check that the C code gets the same inputs and outputs.  Oh, and by the way get this done in one week.
     

    I agree to do this in the interests of keeping peace in the group.  However I then get drawn into the digital circuit.  So, I let him know after three days that I am probably not going to have a chance to re-implement the code in Matlab.  I give him pseudo code for a way to automatically generate test inputs and outputs that can try a million test cases instead of 4 or 5. 

     

    From his response you'd think I just punched a baby.  I am told that it is "laughably trivial" to implement in Matlab (nevermind that this guy took a fucking month and a half to get it done).  If I "still consider myself a part of the group" I'd better get it done.

     

    Now, keep in mind this guy doesn't have ANY experience with Matlab.  He just has heard it is good for doing linear algebra.  Therefore it is "trivial" and nevermind the fact that filling in the three matrices is still going to take 70-80 lines of very dense numerical code that all needs to be carefully checked.  Besides, it is one of the stupidest testing schemes known to man. 

     

    As an aside, another thing that I'm sure will endear him to you guys:  when it came time to implement it in software several of us went and independently found different linear algebra libraries.  I found one that was GPL'd.  He found one that wasn't.  When I presented that one, unaware that he had already located another, he said "I don't want to infect our code with GPL".

     

    "Our code" that would have been "infected" was about 200 lines of buggy crap.
     



  • I forgot, even after that there is more to top it.

     

    After the analog circuit I designed failed in exactly the way I predicted, there is some discussion as the group written report is getting assembled.  I say that I think the analog circuit is actually not even close to finished, because debugging the circuit will be at least 10x as hard as building it in the first place.  (It is the electrical equivalent of spaghetti code).  Trying to be conciliatory I say "hey, we are both being hypothetical anyway".

     

    So, this is the circuit I designed.  Which they went and implemented when I told them it had problems.  I told them what the problems were.  I told them how they would manifest.  I was told there were ways around these problems (which were crazy ass bullshit methods).  They built the circuit without even TRYING to address the problems I predicted.  They manifested.

     

    But since I just looked at the output, since I wasn't actually in the lab building the circuit, I somehow don't have the same zen bond with the circuit that this guy does.  Actually plugging things in to the breadboard means you know what you are doing, predicting the exact failure mode WITHOUT staying up till 3 in the morning putting together a circuit that isn't going to work is just plain laziness. 



  • Geez you had a lot to get off your back there!

    I hope this worked as therapy for you.

    Even more I hope I never have to work with you in the future! 



  • @stratos said:

    mmm projects, the best team work in school projects is where your group agree's they suck and the person who can code the best, writes the code. someone else writes the documentation and the guy who sucks at everything but is still in school because he can smooth talk the teachers, defends the project.

    If you have a fourth guy, he sabotages the projects from the other groups. Since in most cases your grade will depend on the average quality of turned in projects.
     

    I thought the original post was mildly entertaining at best, but this reply almost made me spit coke on my keyboard...



  • @RaspenJho said:

    @stratos said:

    mmm projects, the best team work in school projects is where your group agree's they suck and the person who can code the best, writes the code. someone else writes the documentation and the guy who sucks at everything but is still in school because he can smooth talk the teachers, defends the project.

    If you have a fourth guy, he sabotages the projects from the other groups. Since in most cases your grade will depend on the average quality of turned in projects.
     

    I thought the original post was mildly entertaining at best, but this reply almost made me spit coke on my keyboard...

     That post is certainly the best post of the month!

     

    To the OP,

    I sympathize with your experience.  However, you do have a lot to learn about team work and especially team leadership.  If you were the leader you shouldn't have let 5 months slide by so easily.  Youl should have been better at motivating and directing people correctly.  Of course, if you don't want to be a team leader this doesn't matter.
    On a different note, if you expect random people on the internet to read what you post, you might want to limit yourself to a novella instead of a slightly abridged version of War and Peace ;)
     



  • @tster said:

    To the OP,

    I sympathize with your
    experience.  However, you do have a lot to learn about team work
    and especially team leadership.  If you were the leader you
    shouldn't have let 5 months slide by so easily.  Youl should have
    been better at motivating and directing people correctly.  Of
    course, if you don't want to be a team leader this doesn't matter.
    On
    a different note, if you expect random people on the internet to read
    what you post, you might want to limit yourself to a novella instead of
    a slightly abridged version of War and Peace ;)
     

     

    Thank
    you.   It doesn't matter so much if anyone reads it all, just felt
    like shouting from the rooftops.  I wasn't the team leader. 
    At first there was no leadership position.  Then what ended up
    happening is one person took de facto control, by being the person
    "keeping track of the schedule".  This meant that everyone became
    accountable to her for getting things done by certain times and she was
    accountable to no one.  And her part of the project was the one
    that slid out 5 months.  Mostly because she ignored my suggestions.

     

    She
    literally missed every single deadline which she committed to. 
    She was never under any pressure from anyone else in the group for what
    deadlines she chose.  Even the stupid things like "lets have
    powerpoint slides done in 3 days".  5 days later I show up for our
    "presentation rehearsal" and she is frantically working on her slides.

     

    Are
    there techniques for managing "sideways"?  I think you are right
    that I could have moved earlier to mitigate the problems.  But the
    basic trend was that the other members of the group were becoming
    entrenched in technically indefensible positions.  Then they
    seemed to yell all the louder in defense of their decisions and refuce
    to change more vociforously the less sense those decisions made in the
    first place. 

     

    Anyway thank you for your sympathy sorry for the rambling posts.  :-) 



  • has anyone else noticed that in the email notifications for this thread the title has changed to:

    (Worse Than Failure) Topic Reply: Re: My teammates screwed me (boring)



  • Well to be frank, you sound like a ass. But i'll let you of the hook for being mad as hell.
    You later posts even made me think about Cpound.

    The silly little  thing about tech people is that next to the social aspect, most also seem to manifest a god complex of some sorts. This makes inter-techy discussions difficult. A good way i have found to counter this is to put what failure planning in your schedules.

    Like for instance, you make a dead-line for your analog/digital what-ya-ma-call-it. You mutually agree on a back-up strategy. People suck, they get ill, stuff doesn't get done, WoW was more fun then drawing designs. whatever. Deadlines get missed, it's a fact of life. So making sure you have a solution to counter that is just good practice.

    Another thing is how you bring it. The trick of getting your idea pushed in is not by shouting the hardest. Although that sometimes works too. The best way is to lobby in private with the other members of your group, without your opposition being there to point out the flaws or potential problems. relying on best practice and widely documented techniques is useless because of the god complex factor.

    The best way it seems is to initially agree to some points in the oppositions proposal, but point out some flaws you think will be more then problematic, and show your way as a sure fire way to avoid said problems. If possible, only give half your solution with a minor gap/problem, the techy in the other person will hopefully fill it in making it part his/her solution, and thus more prone to supporting it.

    The idea is to present your idea not as a totally different way, but as adaptation of the idea of your opposition to fix the problems in there design. And while this may sometimes look impossible, it never is. Perhaps sometimes you have to take a few hours and just think about how your idea isn't totally different.



    Also in multi layered projects like this, it's often wise to implement proxy interfaces, that output correct values. That way your hardware might have been shit, but your software could be shown to work.
    Although you might have already done that, i couldn't recall you saying.

     

    p.s.
    While the above may seem mean and unethical to some, in the end it mostly doesn't really matter why a certain way was chosen, what matters more is that the majority of the project group agrees with the choice. This will simply result in a better project, because no mater how great the idea, if the people who built it don't like it or understand it; it will end like shit.

    And if it doesn't really matter what choice is made, id rather have it be my choice because that's always the better one.
     




  • @doublereedkurt said:

    Are
    there techniques for managing "sideways"?

    Yes, usually: get a new job somewhere saner. Some places, such as Google, explicitly call this process "firing your manager". 



  • Oooo I like that.



  • I love the title....  first thoughts that came to mind were of the fornication variety..   usually people say things like "my teammates screwed me (not literally)".  And heck, getting screwed by project members for months doesn't sound bad.. often times that works out better than marriage.

    Woo-hoo!!



  • @pauluskc said:

    I love the title....  first thoughts that came to mind were of the fornication variety..   usually people say things like "my teammates screwed me (not literally)".  And heck, getting screwed by project members for months doesn't sound bad.. often times that works out better than marriage.

     

    Hell, I'd have sex with doublereedkurt if I was on his team (or on another team, to distract him and raise our chances for a good grade).

    Even EE students need pity sex. 



  • @doublereedkurt said:

    I wasn't the team leader. 
    At first there was no leadership position.  Then what ended up
    happening is one person took de facto control, by being the person
    "keeping track of the schedule".

    This problem is my biggest criticism of how group work is handled in schools.  In business, there is usually a single person having clear authority over a project, either by virtue of appointment (project manager), by hierarchy (someone's boss), or by expertise (she's the super-mega-guru who knows everything, so we'll follow her).  The team is accountable, in some way, to this person in charge, and the leader has some way of rewarding and punishing team members, if only by giving comments to your manager for your next performance review.

    In school?  Nothing like this.  Makes the whole process very frustrating.  This thread is just one example of millions of similar problems. 



  •  Heh, I just found this thread again when I tried googling myself.

     

    Now that it has been a couple of years I can be much more philisophical about the whole experience.  Re-reading the post it is interesting to look at my state of mind.  I was coming off of three months of working on the project every day.  Some nights I was up till 5am working on something, picking right up where I left off the next morning.  I started getting a splotch on my neck from the stress (I think blood pressure related).  Also, I was driving 10-15 mph faster on the freeway than normal.

     

    The biggest lesson I have taken away from this is that intelligence and competence in your co-workers are critically important.



  • Hopefully, you've also learned to assign no 'work product' tasks to the person who's supposed to enforce the schedule.

    There's a reason that, in the real world, the project manager is usually not a producing member of the team. When the project manager is a producing member of the team, the project manager is generally the most experienced, most senior, and most accountable person on the team. And, when that isn't the case, we generally hear about it some time later here.

    I've been on successful projects where the 'project manager', while not assigned anything, did do some actual work product - but it was all demand-determined. That is, the project manager worked on those aspects of the project that were about to be missed because the other team members were working on unanticipated problems with earlier parts.



  • @doublereedkurt said:

    Heh, I just found this thread again when I tried googling myself.
    Google. One engine to find them, one engine to bring them and in the forums bind them.

    Now that I got the geekiness out of my system let me move on to my main point... @doublereedkurt said:

    The biggest lesson I have taken away from this is that intelligence and competence in your co-workers are critically important.
    One of my coworkers whose work has been featured in these forums, has a strange aversion for source control. I've tried explaining to my boss why this is a problem, but from what I can tell, all he thought is that I'm not a "team player".

    My coworker is now working alone on some projects on his privately owned laptop. There isn't a single company machine that carries his code. I'm currently waiting for the laptop to die.

     



  • @DOA said:

    My coworker is now working alone on some projects on his privately owned laptop. There isn't a single company machine that carries his code. I'm currently waiting for the laptop to die.
    I would help it along.



  • @stratos said:

    The best way is to lobby in private with the other members of your group, without your opposition being there to point out the flaws or potential problems. relying on best practice and widely documented techniques is useless because of the god complex factor.

    This sounds less like a good way to lobby and more like a great way to really, really piss your opposition.  Besides, since when is open debate a bad thing?  Maybe discussing design decisions with the entire group makes for a poorer product, but you manage to create something without making half of the team feel like a puddle of piss in the corner.  And this is school, it doesn't have to be perfect.  In fact making a myriad of WTFs but still learning how to communicate/cooperate in a group is what it's really about.

    That being said most teachers don't have the "vision" to look past a grade to see how the ad-hoc group managed to resolve differences and get work done.  My advice to the OP would be to take a communications class if you've not already graduated.  I did and while I absolutely hated working with the popped-color-frat-culture comm majors (ironically enough the subject of the class was small group communications, the kind you encounter in software development), it gave plenty of insight into how to resolve conflicting idea[l]s while managing to not strangle your co-workers.



  • @doublereedkurt said:

    I had talked to the professor, but she was very adamant that the point of the project was to force people to work together in a group.

    That sounds very familiar, in fact, that same "point" b0rked my Data Structures final grading.

    We were random-assigned teams, and even when we asked the teacher to let us choose our teammates, she wouldn't budge. So when this assignment came (a simple AVL tree), I had the problem of being the lone coder in my team of 3, and the other 2 friends I had were in dire need of a coder. So we three decided to "split and merge", that is, we just made our own unofficial team.

    We tried to submit the code as two separate forked codes, but the teacher saw through us and didn't accept it that way. She took off 30% of our grades because of "team rebellion", however our AVL implementation was the only one that worked.

    It does have some reasoning, though: you can't always choose your workmates.


Log in to reply