This post is a story. A story about the workplace. I generally try to avoid the topic of work ever since I started working at a company that has bi-yearly confidentiality training. But this story is about my interactions with people, not anything product-related, so I think I’m safe.
It’s been a bit of an interesting year. Around the end of last year, I was extremely busy. But around the beginning of this year, there was a project that I needed to be moved to (I was still busy, but not as bad). Another engineer had had the project for 4+ months and was struggling to get the software on a new platform into a production-worthy state. In all fairness, he was completely out of his element. Our manager had decided to let him spin his wheels–sink or swim–and he sunk. When I got brought in to audit the code, I found numerous errors, and many code releases went out without fully resolving these errors. I took over, and the previous engineer was given a workload that required far less development–because it was maintaining programs that I had worked on for the past two years. The majority of the maintenance that I was doing was given to a second engineer so that I could focus on the new program/platform.
In two weeks, I had completely overhauled the program, stripping out all unnecessary bloatware and simplifying the work of future engineers. I don’t mean to toot my own horn, but it was simply a difference in skill sets–having the right man for the job.
Unfortunately, during the auditing process of the first engineer’s attempt to develop the code, I called out a lot of his mistakes. You have to understand: multi-million dollar decisions could be made based on the data gathered by these programs–we can’t afford to release bad code, literally. But at one point, there was even a slight confrontation between this coworker and myself. We had had a meeting a few days previous, and he had been given an action item to change a number of things in the code. I took it upon myself to modify a script that I had written to check the code for needed changes. I modified the script, but this engineer didn’t ask me for the data. Instead, he made a couple changes and then made a program release. When I caught the error–that the agreed-upon changes had not been made–I sent out an email to him and our manager(s). His quick response was that he thought the script had been run and that everything was fine–basically, he pushed the blame over to me because I was in charge of this script that should have done his work for him.
As fate would have it, neither his manager nor our common manager was at work that day. I was mad. I don’t remember now if it was the same day or the next, but at one point I asked him point-blank, face-to-face if he was blaming me. Oh, he quickly backed down from that one. No, he wasn’t blaming me (now). And then later he has the gall to say to me that “he would appreciate it if we didn’t use raised voices” in further discussion. I had to just turn on my heel and walk back to my desk before I hit him in the face. (Don’t worry, this coworker is still alive, and I happily help him at least once a week, albeit, slightly amazed at the simple debugging that stumps him–he’s not a programmer.)
So when I took over his project, there may have been some feeling that I took it from him or got him kicked off the project. And that’s partly true. I told my boss to put me on the project. But it wasn’t because of any ill-will. I wanted the best for our team and the best for our company. I wanted the program done right. And yes, I was the guy sitting on the bench, yelling, “Put me in coach! Put me in!” I wanted to jump on that sinking ship and save it. And I did. I threw out any work the previous engineer had done (it was in a completely wrong direction, an example of “better to start over than try to salvage”). I started with a fresh fork of the program (we borrow code from another group). And I’m not exaggerating when I say that I had a stable production release within two weeks. My coworker, bless his heart, did not understand the program, didn’t really know what he was doing, and he was only able to complete a fraction of the total program requirements. I mean no disrespect, but I can say with complete confidence that he never would have gotten the program where it needed to be.
Well, most of this is water under the bridge. It’s been over 4 months since this all went down. And like I said, my coworker comes to me for help with his current work. And I like him–he’s a nice guy. Not a great programmer, but very few people are. I sometimes get frustrated that he’s working 100% of his time on something that used to be ~10% of my time, but I’m doing my best to deal with the fact that not everyone works at the same rate. But despite my griping, I want to get along and work well with him. And I think I do. At least I hope I do.
So fast-forwarding to today. I think me and this coworker above get along alright–we’re able to work together as necessary at the very least. (I mean, we’re not hanging out on the weekends, but I don’t think we have much in common anyway.) So the surprising part of this story (and really the part that prompted this post) is what happened with a different coworker. Engineer A above actually interviewed with our group before I joined the company. He was hired into a different group originally. Engineer B used to work with engineer A back at their previous employer. I believe it was engineer B that referred engineer A to the company. Engineer B was my cube-mate for almost two years. We got along pretty well. Eventually, engineer A was placed into our group by upper management. And that’s how we all ended up working together.
Then one day during the drama/excitement mentioned previously, walking to lunch together, another coworker made a joke or comment about engineer A’s code or something. (As both this coworker and I had been brought in to audit and help with engineer A’s project when we both had more than full workloads, we were frustrated with A and kind of surprised at some of the errors he had made–and we talked about this at lunch sometimes.) It wasn’t something awful, but I remember thinking, “Oh no. We probably shouldn’t talk about this around B,” and I quickly changed the subject. But I must have been right, because after that day, B stopped having lunch with us. And after I took over A’s project, he really turned a cold shoulder. I tried several times to invite him to lunch, each time being declined. He no longer just talked to me in the cube. If we did chat, I was the one initiating the conversation, and it was short. There were a lot more whispered conversations between A and B. Generally, the atmosphere that had been friendly turned very cold. I flat-out told my best coworker (as I will call him) that I don’t think B likes me. A couple interactions in the last few weeks have cemented this in my mind. Nothing horrible–just chilled.
Now, I know I’m not prefect. Heck, I’m writing a long blog post about work drama. But I like to think that I’m a mostly likable person. I know that I’m confident about my skills, and that might seem cocky or arrogant to some. And that might rub some people the wrong way, especially when that attitude puts me in a place to take over your project (or your coworker/friend’s project). But it’s also the attitude that makes some coworkers happy to hear that I’ll be handling work that will directly affect them (or disappointed to hear that you no longer handle work that affects them). I’m not going to give 10% just so that someone else’s 100% looks better. I’m going to give 110%, and if that put me ahead, then that’s life. That shouldn’t be held against me. I didn’t have a vendetta against A. I just saw a sinking ship, that’s all.
You can’t win ’em all. If someone doesn’t like you because you worked to help your company and your team, even if some feelings and egos might have been bruised, then that’s not really someone whose approval or appreciation should be sought. It is what it is, I guess.
But when all that’s said and done, it would still be nice to be liked.