Note: this post is a rant. But it’s an important one.
Last summer, I started working on a research project at a computer science lab at Tufts University. Unfortunately, I had a severe clash with the work culture at that lab. After just one month, I ended up quitting, with very little after-thought. I was confident that this work culture is toxic, and I thought that it had some serious issues that need to be fixed for actual innovation to happen. The following is an account of what happened: interactions with the lab leader (who was my boss), and more importantly, interactions with a co-worker, who could be the most terrible teammate I will ever have. I am mostly an inwards-blaming person; nonetheless, I feel confident pointing the blame fully at those people for messing up. Yes, it was that bad. Read for a recount of a subset of cringe-worthy interactions with the lab people.
First was me: very excited to begin work in a computer science lab, and very hyped to be working on a project that is related to Machine Learning/Artificial Intelligence. The job also had good pay and flexible hours. Even more exciting, my boss promised that this project will be “towards a publication”, which was very enticing to me. I was ready to do my best. My project followed the conventioanl structure of data science projects: first is the data collection, and then the “machine learning” part, where you train a classifier to learn something from the data. I was to do the machine learning part, while a co-worker (let’s call him Jim) does the data collection part. Jim has been working on his side of the project for a while, and my boss wanted me to met Jim to see what he has been working on.
First encounter with Jim
So I meet Jim. He is an old, bearded dude who talks and acts in a socially awkward way. I was happy. That is actually fine: I like spending time with “weird people”, partially because I think they are funny and cute, and also because, around them, I don’t feel pressure to act in any certain way. I was thinking: Jim probably has problems interacting with many people, but not with me, because I just know how to interact with socially-awkaward people, and it takes a lot more weirdness than normal to throw me off.
But I was wrong. Jim is actually so bad that I can’t deal with him. It is not just that we don’t have chemistry and should limit unnecessary contact; he actually goes out of his way to make matters worse. Like mean, condescending responses is his thing. But we all met those kinds of people. I actually want to talk about other behaviour that are more subtle yet very toxic for performance.
Anybody who creates software knows that there are a million ways to write a software that achieves the same result. Not to blow myself up, but through my experience in programming, I realized that most of design decisions are trivial and don’t really matter! What names should you use for your function? There are probably a bunch of names that are equally readable, and provide the same level of clarity. Just pick any -freakin- one of them and move on to a design decision that actually matters. The behaviour of overthinking trivial decision has been a very well-known killer of productivity in software industry that it got known as “bike-shedding”. (You can Read more how that term originated here).
Jim seemed to love bike-shedding. What makes matters worse, he decides to bike-shed my own work. I was working on my own “section” of the project, but I was happy to have someone discuss my code, because (I thought) I was likely to learn something from him. I wish they were productive discussions, but they absolutely weren’t. “How should we represent this numerical data?”” “Well, there are a few ways and they all provide the same information and just about as equally elegant. I just chose this one”. Jim doesn’t like that, and proceeds to tell me to switch to another method, giving some trivial reason. I would rather discuss something more meaningful..
The PI is just as bad
At this point, I realized that Jim is a big trouble to deal with. I would rather tell him to mind his own section of the project and stop interfering with my work, and he did get the message. Enter the second problem, the PI. Another condescending person, who is just as fond of bike-shedding as Jim. Hey PI, you are manager of people. You better know how to manage people. Instead, you are creating a lab where members try to minionize others into following them blindly with no questions asked. Unsurprisingly, at best, you create one superstar, and several minions writing meaningless code.
I am not about being a minion. I am about being a productive, creative team member who cares about fellow team members’ learning and satisfaction just as mine. At the very least, I would rather be in a lab where people understand the importance of a good work culture.
At the end, even after Jim leaving, I quit without notice. The air was too bad and it was clear to me that bad work culture is at fault. Looking back, I realize I learned quite a lot in both technical knowledge and in experience, and now I have come to understand work culture as a very important factor in any institution.
Thanks for reading!