Writing a better test system with Benny (real story)



  • This story is about a major 'incident' that I had with another software engineer that I have informally diagnosed with Borderline Personality Disorder. Sorry it's so long, there's a lot of subtext going on so it requires some backstory.


    I'm a mid-level programmer at a medium sized publicly owned company with lots of subdivisions. Our subdivisions tend to be fairly isolated from one another, which gives our development team freedom to settle into their own processes. A senior programmer that I work with, Benny, has been working with the company for many years in as sister subdivision to the one I work in. Benny is a fairly skilled programmer, but he has some major personality flaws which can make him difficult to work with. As a real person, there's actually quite a lot to him, so I'll put his short biography in the next paragraph, just in case you want to skip it. Knowing about Benny is not necessary for the story, but it does help foreshadow what's to come.

    Benny is the type of programmer that likes to claim complete ownership over any code he writes. If you imply that there's anything wrong with his code, then you're basically spitting in his face, that kind of thing. Benny is also very egotistical, and has a love for writing miscelaneous GUI applications to accomplish common tasks, as it allows him the opportunity to parade himself around the office introducing his new utility to the less-tech-savy development members (producers, designers, arists, what-have-you). Benny is a generally friendly person, but he is very manipulative; asking you to open and assign bugs to him then claiming that you've assigned him work (even sometimed complaining about 'all the extra work' that he's being assined), asking you to look over his code then using you as a scapegoat if things go wrong, that kind of thing. Benny is also frequence condescending, speaking to fellow programmers as if They know nothing about what he's speaking, even when the concepts he is trying to express are fairly mundane. Given this, it shouldn't be too surprising that I try to keep Benny at arm's length.

    One day, during a regular planning session, my development director William begins to bring me up to speed on a new project they wanted me to start working on. Benny's department was responsible for delivering some performance results for their product to an external vendor (to prove that they were going to be able to meet the production demands they were given), they were coming up fast on their deadline, and they were behind; the team was fairly confident that their product would stand up to the performance tests, but their performance testing framework was still in nascent stages and was not going to be ready in time. As it turns out, the full story as to why they were behind was a little more interesting. First, the external vendor actually already had their own full suite of automated tests ready to go, but Benny's team didn't trust that a third party could accurately test their product, and insisted on providing their own tests. Second, Benny's team actually already had a full comprehensive test suite that they had developed about a year and a half earlier, but they weren't going to use that one. Why weren't they going to use that one? Well, it was developed before Benny joined the team, and Benny insisted that he could make a better one; one that could perform better, faster, at lower overhead than the predecessor.

    So, what was my role to play in all this? Well, in true Benny style, it turned out that Benny had actually managed to generate something that would theoretically meet the bare-bones specifications of our first round of performance tests.. but his solution existed stictly in GUI form, and would not be able to handle the full specifications of the test. In fact, not only could the application not scale to meet the demands of the test that we needed to fulfill, but Benny was actively refusing to develop a solution that would allow it to. This, as William explained to me, is where I came in. My task was to work directly out of Benny's sandbox branch and create a solution that would allow Benny's team to meet their deadlines. For people not familiar with the concept of personal sandbox branches, this would be equivalent to walking directly into Benny's house and rearranging the furnature for him so that his house would be able to accomodate the future house guests that he was expecting. Given how I described Benny's personality above, you can probably guess exactly how thrilled I was about this particular arrangement. I expressed my displeasure to William, and William expressed his condolenses to me in turn.

    The first day of my task was on a Wednesday, and the solution was due on the wednesday of the next week. I begin by discussing the situation directly with Benny. He is familiar with the problem of course, and begins to describe to me his vision. The solution that Benny had set up was specifically designed for driving load. The project would simulate a large number of user applications, and would hit a critical mass and die out at around 4 thousand users simulated. We were looking to hit upwards to a million users, so we would need to spawn multiple instances of his application, across multiple load driver machines. Benny had generated up a generic fake-user-handling core DLL in c++, which he was loading in C# to work with his GUI. I informed him that I was familiar with the basic concept of DLLs, but that I had never worked with them before. Given that he already had a basic system set up to load the dll in C# for his GUI, I asked if he felt it was appropriate for me to generate a command line interface in C#, leveraging much of the code that he had already written for managing the DLL. Benny was adamant that this was not the correct solution, and suggested instead that I write a command line interface in python. I happened to have a great deal of experience in python, and while I wasn't convinced of the merits of writing a performance-critical application in python, my fears were allayed by the fact that the utility I would be writing was just a wrapper for invoking processes in the core DLL, which would be performing most of the heavy lifting. Having learned that the best way to work together with Benny was to agree to his demands, I decided to go with his solution, and set off to create his python interface.

    As I mentioned, I had never worked with DLLs before, much less in python, so it took me two days of research and implementation to get something that I'm reasonably satisfied appropriately loads and calls the hook that he's written. I've attached debuggers and verified that his functions were getting called, and that their return values were being appropriately interpreted, that sort of thing. Now that the grunt work was done, the next step was to test it and make sure that everything actually worked the way it's supposed to, and that I was passing his functions the right parameters to inform the DLL that it should run the appropriate tests. Given that the majority of the API I had integrated with were functions named generic things such as "startup" and "shutdown", I was curious as to where the actual load request was supposed to come from. Throughout all the exposed function calls in that DLL, there was only a single function call that seemed like it performed actual load, and I wasn't sure how it worked.

    So I went over to Benny's desk to ask him how it worked. Benny began hemming and hawing about the generic concept of load testing, which I was already well acquianted with myself, having written my own custom load test applications throughout my career at this company. Throughout the conversation, Benny's descriptions of the way in which his process would actually generate load was as vague and nonspecific as his API. Suddenly, after some discussion, I realized that the reason I could not determine what the program did was, because, it in fact did nothing. Well, "nothing" is perhaps a little harsh. Benny was familiar with the actual product that we were delivering, and he knew how to create a program that could connect to this service and simulate fake users, but he had no concept of how to actually approach making these users generate any kind of real load. All his application was able to do was connect to the service, and not drive any load beyond that. This was not going to be sufficient for our first milestone, which was now due in only three days. Since I had been involved to create "The Actual Solution That Generates Load In Our Production Environment", and since Benny was marketing his solution as being "The Solution To All Our Problems", I now knew exactly what his game was, and why he had refused to take on the command line application himself. If we failed to meet our Wednesday target, Benny could simply claim that our failure to meet our deadline was due to my inability to create a command line application that properly interfaced with his system. Benny was in over his head with no idea how to proceed, and It was now my name on the line for ensuring that we had a deliverable that would meet the expectation of our respective departments.

    Ultimately the meeting transformed from one where he would described how his load driver worked into one where I described in great detail to him the particulars of how his load driver solution should work. Of course, Benny being Benny, this wasn't a process of him sitting humbly by while I instructed him on how he should address his problems. Instead, the meeting was a labored painful procedure by which I would ask him how he sought to solve certain problems, and he would ask me how I thought the application would handle it, as an instructor would ask a particularly slow student how they might address an obvious problem. I would give him options for different ways he could implement a solution, mentioning other consideration he would need to keep in mind, and he would condescend to me about those problems that I surfaced for him, acting as if I could not come up with a solution for them, despite the fact that he was, in fact, the person who needed help coming up with a solution.

    All in all, this was a frustrating process for both of us, and as the meeting progressed Benny absentmindedly let slip some information that cued me in to some greater plans that he had in the works in his grand chess game. Benny and I were not the only engineers present for this meeting; Benny would regularly make commentary about the situation to another engineer that shared his cube with him. Amongst the information that Benny slipped, he mentioned that he was unhappy about the fact that 'they' (my managers) were having 'them' (me) write a command line interface for his program. He mentioned angrily that he had not received 'requirements' for a command line solution, that he was disgruntled that there were other people creating this command line solution for him, he was also particularly derisive of the fact that they were doing it in python, his tone of voice implied the fact that only a moron would have implemented such a solution.

    This was my first inclination that Benny was posturing not just to throw me under the bus by proxy, but that he was actively working to complain directly about my work to management. He had laid the groundwork for his argument against why other people should not have been writing the command line argument, at the same time he had established the fact that he was unhappy with the solution. He already had at ready his excuse for why he hadn't written it himself, and he even had his argument ready to go at why we should not use the solution that I was creating. If he was a more intelegent person, he would not have let slip this information at the time that he did, in front of the person that he did... namely, me. So at this point in time in the meeting, I decided to shut my mouth. I stopped providing Benny with hints or advice on how we should procede. The rest of the meeting went about as well as you could expect given those facts.

    Different accounts will give you different versions of what happened in the rest of the meeting, and, as you'll discover later in the story, this is actually somewhat significant.

    Benny claims that what we discussed next involved me and him coming perfectly to agreement on the fact that he should write the command line interface for the program, and that my only job was to provide him with a text file that his command line interface would parse, which would tell the program how to behave.

    The nearby engineer that Benny was remarking to would avoid the argument entirely and claim that it "Was not so obvious" as to what we discussed next, and that there "was no clear path forward".

    As for my own recollection, I recall Benny spouting out various slipshod suggestions (amongst which was the file parsing solution that Benny mentioned earlier). I however was not fond of this solution, for many reasons, including not only the fact that it simply would not work very well and would be very difficult to automate but also the fact that it would mean that my job was primarily to be Benny's personal slave and simply assume that he would be able to write a command line interface by the time we hit our deadline on Wednesday.

    As luck would have it, William walked by around that time, and I cried out to him in desperation. He was somewhat busy and so was reluctant to join us. I personally try not to disappoint him when possible so I decided not to press the matter further; if he was too busy to join us then I would simply try to continue on the meeting without him. Benny, however, had other plans. He likely could tell the fact that I was being less cooperative with him at this point, and insisted that William join us, and so he did, took a look at everything that I had written on the board in terms of describing everything that I expected him to do, and was prompty horrified at the elaborate solution that was presented before him, and not unfairly so; the primary reason I joined the meeting in the first place was simply to determine how I was supposed to interface with his code, and to do so by gaining a higher level understanding of what exactly it did. William was concerned that we intended to implement the entire solution that I outlined by wednesday, he reminded us that the test on wednesday has a much more narrow focus, which consisted only of connecting to the server. This was the first time that I was made aware of these new requirements, and as he mentioned this I came to the realization that it did not matter whatever plan Benny was trying to pull with his new-Benny-order, because in fact the utility DID already perform the behavior that I needed for Wednesday.

    William, out of concern for the fact that we might not deliver on time, asked us if we knew what we were going to do next. I replied that I intended to simply continue with my solution in python to have it hard-code the behavior that we expect it to perform on wednesday, and that we could deal with all the other implementation details at a later date. Alas, I probably should not have said that, because I had now alerted Benny to my plans. Just as I was now aware of the fact that Benny intended to fuck me, Benny was aware of the fact that I intended to deliver on whatever solution I could before wednesday. Unfortunately, before this meeting, Benny had actually informed me that he in fact intended to change the API at some point after his solution 'hit DL', which would make my task even more difficult.

    As a side-note, in case you're not familiar with that concept, 'DL', which stands for 'Distribution Line', is the place where all our code lives. Once code is 'In DL', all other programmers have access to it. We also have a 'continuous build system' which constantly makes executable files out of the code which is 'In DL' and tells us if things are broken. As I mentioned above, Benny, somehow, had managed to keep all of his code in his 'sandbox'; this means that all of the work I had to do, was in fact working directly with his sandbox. It also meant that Benny had absolute authority over what I did, because if I made any attempt at checking code into his sandbox, he would start an incident of magnitude so great that I would not be able to escape. Benny was no stranger to interdepartmental controversy, and had actually previously gotten other engineers that he did not like to work with fired. In the grand game of playing other people and making them do his bidding, Benny was a master. In fact, my earliest warning sign came not on Friday, during the course of this great meeting. My earliest warning sign came a few days earlier, when I submitted the first implementation of my code to 'code review', to get feedback on whether he felt that I was headed in the right directly. My code review received no comments whatsoever; Benny had effectively pocket vetoed what I had written.

    And this is where I stood on Friday: All of Benny's code was in his sandbox, I was informed that he would be changing the programmable interface sometime after he finally checked his code into DL, and I knew there was effectively no way I'd be able to get anything that I wrote into his sandbox. However, as luck would have it, Benny had actually shown me a new version of his application preceding the meeting. What this meant to me was that I knew that he had already finished his API changes; I simply needed him to check his API changes into his sandbox, and I'd be able to develop against it. Also, given that my interface was written to interface with his DLL, they did not actually have to be written together. So I checked my code into my sandbox instead of his sandbox, and began writing a scripted process that would automatically merge my solution with the location where his solution would be deployed once it hit DL. This would allow me to actually check my code into DL without having to go through his sandbox. In addition, to safeguard against it breaking, I could write a test script which would verify that my application behaved as expected, and integrate it into part of our build rules (which my department had control over). I could even write the test such that it would pass if the Benny's application was not there, so that I could check my code into DL immediately when it was finished, and it would immediately start testing the code as soon as Benny checked into DL. Mmy final plan was to actually completely write and run the load test that we intended to run on wednesday, and have it running on monday.

    William had picked up on my attitude at the end of the meeting earlier; I got the impression that he felt I would not be cooperative for much longer, and intended to also perhaps pull me off the project. This would be perhaps the quintissential 'Benny Wins' scenario; it would make me look like the uncooperative asshole while Benny would look like the innocent bystander. As such, I decided that if I could completely finish the application and have a test run by Monday, then I could end the entire thing before Benny had a chance to start his bullshit, and could also prove to my boss that I was able to handle the task that was given to me. With that in mind, given that I could not proceed with the application until Benny had checked in his API changes, I decided to finish the test harness for his application, so that I would be ready to run a test with it as soon as the application was done. I finished my work and checked what I had into DL; I was ready for him.

    After that, the waiting game began. I didn't know anything for a fact, but I knew that Benny often worked on weekends, and that given that he had actually finished the new API on Friday, that he was likely to check it in sometime soon. I checked multiple times through the night on Friday, and on the fourth day I rested. On Sunday, I checked once more and discovered that Benny had checked in his changes late on Saturday night.

    I cannot say whether or not Benny saw the work that I had done, and I cannot say whether or not it motivated him to do anything different. I simply provide that information and let the reader draw their own conclusions.

    On sunday I discovered that Benny had checked in his changes. I set forth in compiling his code so that I would have an interface on which to test my changes... it did not compile. This was something that I did not expect, or i should say, something that I had not anticipated. So I deliberated for a short time on how to proceed. Ultimately, I determined that it did not matter if the program itself was functional, as long as the interface remained the same, so I set forth in actually fixing his code, such that it would compile. I should say at this point that I use the term 'fixing' very loosely; I mostly commented out broken code until it compiled, but I did so very surgically, such that it would not affect the API. Note that as I mentioned I was not very familiar with DLLs, and such I needed to be sure that my solution was actually calling his API correctly, which I could only do if I could debug the running process and verify that the data I was sending was being correctly interpreted by his application.

    In any case, I got it working and I set about my work. This version of the API had a lot more custom structures and classes than the previous one, it required more work to get everything working again, but ultimately, it did work... in a sense. As I mentioned, I commented out some lines of code that previously did not compile. I could not say whether or not it would actually do the test that it was designed to do. However, that was Benny's problem. I reasoned that he would have to fix it before he checked into DL, and that the interface was not likely to change much more, now that he had finished his refactor. That turned out to be an incorrect assumption.

    Late on Sunday evening, just as I was finishing up my work such that I would be ready to write the actual implementation of our Wednesday Deliverable test, Benny checked in a new change... and this time, he didn't just add a few more data structures. In fact, he modified the application programmable interface to use entirely compiled code; something called "google protocol buffers", which he had worked with perviously. As far as I can tell, there was no benefit gained from switching from what I now refer to as the "second iteration" to this latest iteration of the API. In fact, all the backend logic was the same. The primary difference was that instead of defining custom C data types in python which I could pass to the application, the application now took a stream of bytes. I was quite unhappy at this development... I had never worked with google protocol buffers before, in fact I wasn't even sure if I would be able to use python to perform the marhsalling anymore; I did not see anything that allowed me to specify a generic byte stream in any of the python-dll marshalling code documentation I had come across.

    But I'm not the kind of person to give up that easily.. as long as I could compile the latest DLL, I could run the application in a debugger, examine the data that was being passed, and see if there was any data structure I could pass that would be interpreted by the program correctly. And so, I once again set about compiling Benny's code, but once again, I encountered something unexpected... The program did not compile. To rule out the possibility of this being a misconfiguration on my own machine, I decided to run his sandbox build through the automated build system. The news that I got back was even more grim. In fact, now, not only did his application compile, but all the other applications in his sandbox did not compile. He had apparently made changes so fundamental that it completely broke everything in his sandbox.

    Whatever was wrong with that sandbox was way beyond a simple code fix. It was majorly fucked. Not the least of my problems was that, in order for me to make it work, I would have had to complete his horrible migration to google protocol buffers. So, I had a decision to make: No matter what I did, what I had written wouldn't work, because the thing I had written, was for a version of the application that did not compile. In order for me to be able to achieve my original goal of running the complete load test over the weekend, I would actually need to go back and get it working again with the friday version of the application, and I did not anticipate that working out well. And so I spent the rest of my evening Sunday coming up with a plan for the next day.

    Monday eventually rolled around, and the fun began to unfold. Throughout the day I heard various engineers muttering (and in some cases, yelling) about how the "fucking sandbox" was broken. As it turns out, I was not the only engineer who had been forced to work out of Benny's personal sandbox, and in breaking his sandbox he had also blocked everybody else that was being forced to work out of it. Strike 1 to Benny's reputation. Benny is also the kind of person who likes to work from home a lot. He'll often come in past 3PM, and on some days he won't even come in to work at all. So at this point in time he was not sitting at home, nowhere to be found, while people at work were angry about him breaking the sandbox. The management for his team sent out an email reminder that everybody on our project was in crunch mode, and that mandatory hours were being enforced where everybody must be physically present in the office for our core hours.

    During this time, I appealed to William. I informed him that I had got a command line interface completely working.. for a version of the DLL that was depricated. William suggested that we simply push forward with getting the version of the sandbox from Friday into DL. I did not mention to them that my application would also not work with the version from Friday, and that I would still need to perfom additional work to determine how to interface with that version, but as long as I had a stable version to work with I would be happy. However, their team rejected this idea. According to their team lead, the version of their sandbox from friday had a critical bug that would prevent us from moving forward with that solution, so they were going to fix their sandbox and get the latest verision in... the version with protocol buffers.

    William, having been informed of the fact that my life was now a lot more harder with this latest change, began a conversation with Benny. I am not privy to what was said, but I believe the general gist of the situation was that Benny was asked if we could not go with the protocol buffer solution. Apparently, Benny was tremendously upset at this suggestion (which I would expect), and I suddenly found myself in my technical director's office, standing besides me was the engineer who had overheard our meeting from Friday. And then we began the game of 'he said she said'.

    This is where that thing I alluded to earlier becomes relevant. As I mentioned, Benny claims that we had a meeting and came to all sorts of conclusions about what each person would be doing, the chess pieces that Benny had set up were finally starting to move, and William wants to determine who exactly said what. I reaffirm my statement that I would be working on a python command line interface, and the engineer dragged along with me is able to decipher that this whole series of events is nothing he wants any part of, and disavows any knowledge of specific plans that were made for 'next steps'. William primarily called us to his room so that we can determine exactly what our next steps are. He lays out three possible plans for next steps. Amongst those plans are the file solution that Benny claims we agreed to, as well as a solution to get the command line interface that I wrote working again. While the other engineer and William are discuss exactly what went on in this meeting, and whether or not it would be sufficient to use this file-share solution that Benny is so adamant that we agreed to, I can do nothing but grit my teeth. When they finally finished their discussion and sent off a meeting invite to myself, Benny, and Benny's managers, I was dismissed.

    However, I did not leave. Instead, I began with, "You know that Benny's playing you, right?" William looks quizzically at me. I then let out 4 days of pent-up aggression towards Benny. I informed William that Benny was a manipulative asshole, that the whole game of he-said-she-said about who agreed to what in that meeting was pointless because Benny had not actually begun writing a programming solution towards that affect, and that anything he claimed otherwise was a lie. I let out everything on my mind about Benny's personal character. Strictly speaking, it was not the best career decision I could have made, but my primary concern was that if I let Benny get too many steps ahead of me that it would be impossible to maintain ground. I wanted them to be aware of the game that Benny was trying to play, and that I was in on this fact.

    I then returned to my desk and began researching google protocol buffers. I knew that I had to attend a meeting to personally argue my case against Benny in only a few hours, I still had a solid argument to make.. Benny had not written any of the code towards actually implementing this solution that he claimed was causing him so much strife, and I could still get everything working with whatever he had, provided he get working code into DL. In that time period, I discovered that in fact google protocol buffers defines an interface for compiling code into python. I also discovered that python strings could be used to send raw byte data through the python ctypes library. This meant that I could create a solution that worked with his application, even if it was in Google Protocol Buffers.

    I arrived at the meeting on time, so did William. The other members of the meeting (Benny, Benny's manager, and Benny's team's lead) were late. I mentioned to my manager the fact that "If the only thing we need to worry about is google protocol buffers, then I can probably get it working again". As if on cue, Benny's manager and Benny's team lead show up. We begin discussing the fact that we can get something working as long as they can fix their sandbox. Finally, Benny arrives and the meeting begins officially. William asked if everybody had seen his email, in which he outlines the possible solutions that he addressed earlier. William then mentions the fact that I had offered to get it working with google protocol buffers.

    And then, something magical happened... Benny literally just starts yelling. First he starts yelling about how my team had "Done work that he had not agreed to", then he starts yelling about how I had "Agreed to provide him with these configuration files". The most glorious part about it, is that everything he was yelling about, were not problems. Even if true, even if I had told him that I was going to provide him with a configuration file instead of making the CLI, even if true that he had no knowledge of what exactly I was going to write, none of that actually mattered, towards delivering a solution. In fact, he was doing exactly what I had complained to the technical director about earlier, he was simply coming up with any random thing that came to his mind that he felt would give him a leg up on the situation. Benny's manager begins trying to tell him to calm down, while Benny continues to yell. Benny yells about getting "Conflicting requirements" from my team, and so Benny's manager tells him not to talk directly to us, and to talk to him instead.

    When Benny continues to yell, Benny's manager decides to end the meeting, without me having to say another word. On our way out, Benny closed the door in front of me. His manager stood up and opened the door for me and apologised.

    As I mentioned earlier, one of Benny's most frequently used tools is when he talks directly to individual people and then tries to get them to agree to random shit... a power which he suddenly lost in the middle of that meeting.

    On that same day, after that meeting, their team lead gets involved, and starts giving me requirements. He tells me that I should write the thing in C# instead of python, and a few other arbitrary requirements. And so I do. I work overtime once more, and finish it that night. The next day, the drama starts anew, as you could probably guess, given that Benny's original objection had nothing to do with the implementation. Benny starts yelling about how we're doing work that they haven't signed off on. Benny's team lead blocks my C# implementation again. This time, he claims that he wants it to be in a single executable, instead of an external application which wraps a DLL. I had not done because I knew that Benny would flip his shit even harder about this affront towards his design, and now the team lead personally decides to modify mine to make it a single executable.

    I wish I could have been there in that discussion between the team lead and Benny, because the team lead shows up at my desk that night, tells me that he discussed his idea with Benny, decided that they should go with my solution, and that I can "check in at my leisure". Officially, my part in this story is over.

    Thursday rolls around, and we're actually running this test. Benny's team lead is there, trying to use the GUI that Benny had written to demo a smaller-scale version of the test... and it won't work. It keeps crashing. And so, they use my command line interface, and it works great. They get numbers so good that Benny's lead is literally running around the office taking pictures of our performance monitoring software. Everyone knows in the back of their mind that none of this would have happened if it weren't for me. Basically I'm god. I'm of course paraphrasing the whole situtation. But that's basically where I stood. I got my shit into dl, and I saved the day, but Now my team has to go through tons of official planning with official technical design documents and whathaveyou before we write anything more for that team, so that we "won't have the same problem again". Nevermind the fact that the problem had nothing to do with not enough planning, and everything to do with too much Benny.

    The team also decided that Benny doesn't get to be the sole owner of that tool anymore; they decided to put Benny and another guy on the project as co owners. The other guy quit three days later, and so they decided that it should be Benny and the team lead working on it. A few months later, Benny quietly wrote a C++ version of the command line wrapper; mosty copy-paste code. His version didn't take off; they still use the C# version.



  • Dude,quite a story! I hope the venting here has done you some good.

    It wasn't clear to me that your manager understands that Benny was the issue, and how many hoops you jumped through to deliver. You might want to keep tabs on that situation.



  • Thanks for the reply :) Yeah, I definitely try to keep Benny at a much larger distance these days. There hasn't really been much fallout from this whole ordeal; their team ultimately got a solution that works for them so they can't really complain, and Benny's manager seems to have taken my side in the whole issue as he's been much friendly towards me ever since the meeting where Benny started yelling



  • Always good to have a friend with Benny fits.


  • Discourse touched me in a no-no place

    Tracking someone's sandbox is always a bit of a problem, even with the very nicest and most competent people, and that it was being done by several people off of Benny's…

    Still, it looks like you've not come out of it too badly.



  • @flabdablet said:

    Always good to have a friend with Benny fits.
     

     

    http://www.sadtrombone.com/



  • Best of the sidebar anyone?



  • I realise you got through this and ascended to Godhood, but if he continues to exhibit that kind of behaviour, get him fired or leave. If you take the second option, the answer to your exit interview should be "Benny".

    @pyro789x said:

    ... [venting] was not the best career decision...

    You didn't have many options by this point. You were already losing ground having to work from his sandbox. It's not your fault and you probably weren't to know, because why would someone in your own company want to wreck the company? When you have to start playing at Art of War with people in your own company just to defend yourself, they're putting the company in jeopardy and your career with it. You deserve better than working with a psychopath. Your objective is to improve your company, that's what you're paid for. His objective was to get away with doing as little work as possible while screwing with you, or something. Psychopaths are good at keeping their agendas hidden because they are usually making an enemy of somebody.

    My advice is to keep written documentation on everything, including the python solution by email, confirmed by Benny. Obviously he won't bother sending you back a confirmation and make up some bullshit like "can't you even remember that?" upon which you can say you were trying to avoid a he said/she said situation, which he has now created. I want to emphasise that we don't expect to have to treat people like potential enemies because everyone should be there for the same reason: to improve the company. So I'm not saying you should have thought of it already. Wars are supposed to be fought with other companies, not between colleagues.

    Every interview I go to I now ask about the basic procedures for handling tasks and source control. In my last interview I got asked why so many questions on basic procedures (after they gave legitimate and detailed answers) and I told them I had worked in places with lax procedure and it had not worked out well. That was only half the truth - it had not worked out well because the manager had taken the attitude that better protocol was to "avoid doing work", while simultaneously inserting work items and pointing fingers when we couldn't meet deadlines because of the extra work he was giving us. Obviously many people just up and left because of that dipshit.

    Anyway, the point is you got lucky. Benny clearly didn't know how to play his own game properly otherwise he would have coolly responded with "google protocol buffers was always my idea, I even have code for it" or some equivalent. Watch him. Make sure everything he does is publicly visible (or at least within the company) and draw attention to anything threatening the moment it appears. He wasted a lot of your time already and will likely do it again if given the opportunity.



  • Thanks for the comments :)

    A lot of what happened went on 'behind the scenes', and I think only Benny and I really know the whole story. However, Benny's outburst in a meeting room was perfectly visible to everybody, and that's really what I tried to make the focus point of my long-term life strategy. Both my manager and his manager actually personally confided to me that his behavior wasn't acceptable, and that he would be off the team if it continued. I actually think the only reason Benny is still with the team right now is because he's working on an application critical to our project, and they're afraid they won't be able to deliver if they lose him. (edit: That and because it's ridiculously difficult to fire people at my company. I only know one guy who was 'laid off' for cause, and he was laid off many months after the last time he did anything fireable. The person I mentioned in my story above who was 'fired' was actually basically reassigned to work in the salt mines, and so he eventually quit) Personality problems aside, he's not a bad programmer.

    Ultimately, I definitely share your concerns. I didn't mention it in the story as the story itself was already long enough, but I did make sure to talk to my manager about how difficult it was to work with somebody so manipulative, and that I wanted the whole situation documented with HR so that I would have something on record if anything ever happened again. Trying to argue this kind of point with people makes me sound a bit like a drunken raving paranoid lunatic, so I try not to push too hard, but I did forward our chat logs where he suggested I should use python (Thank god for communicator! If only our whole Friday meeting had taken place online!). As far as the HR thing goes, It's a bit of a mixed bag. By doing that I was also putting myself on their map; in general I feel that if HR knows your name, it can only be for bad reasons.

    As a bit of an epologue, Benny actually did try some of his shenanigans again shortly after this whole thing took place. Long story short, he called me over to his desk so that I could "code review" something he had written. When I got back to my desk, I had a new email from him (CCing our managers) talking about how we had discussed something related to how I would be approaching a problem related to this whole solution. I quickly followed up his email with a second email directly to my manager informing him that this was NOT what we had discussed, and then I blocked Benny on communicator. That was the last time I heard from him in a professional context (we sit close to each other so I still see him frequently, and always smile and wave at him)



  • @henke37 said:

    Best of the sidebar anyone?
    Longest of Sidebar?



  • @El_Heffe said:

    Longest of Sidebar?

    Indeed, but (if the story is sufficiently true), The Character Known As Benny is quite awful. But how did that company manage to have two teams that are supposed to work together yet seem to have no other purpose than making each other's life miserable?



  • @TGV said:

    how did that company manage to have two teams that are supposed to work together yet seem to have no other purpose than making each other's life miserable?

    My team actually is tasked out to work with tons of different teams in my company. It usually goes much better than this, and even in this case things worked out for the company in the end, personal disagreements aside.



  • Some best practices to fight the prevalent WTFs there. I was surprised that you pulled off a good outcome in that situation...it sounds like Benny has plenty of practice backstabbing.



    Technical WTFs:

    • Have a single project owner who defines requirements, prioritizes them and signs off on them. Clears up many misunderstandings and interdepartmental or interpersonal politics will drive requirements less often
    • Have requirements in a system accessible to everyone and with information on who defined them.
    • Avoid project and private branches (the book Continuous Deployment is good there)

    Social WTFs:
    • Never spend more than 50% of your time on work that isn't visible to your boss (in your case, doing work someone else will take credit for)
    • If you're going to work in an environment where you have to cover your ass (CYA), learn how to do it well (e.g. keep an email paper trail or email a meeting summary copying bosses...if it ain't on paper, it didn't happen). Better yet, don't work for a company that requires CYA, or one that would hire and then put up with a Benny, much less promote him
    • A good book for improving technical and organizational skills is the Passionate Programmer, especially the section 'Marketing, Not Just for Suits'


  • @pyro789x said:

    it's ridiculously difficult to fire people at my company. I only know one guy who was 'laid off' for cause, and he was laid off many months after the last time he did anything fireable. The person I mentioned in my story above who was 'fired' was actually basically reassigned to work in the salt mines, and so he eventually quit
      While it's unfortunate that things ever reach a level where such a thing is necessary, it's nice to know that you can always slip out to the parking lot and cut someone's brake lines.



  • For some reason (despite how little it played into the events in question) I think I would have found this story a lot less interesting without the note at the beginning that Benny is "a fairly skilled programmer." Possibly because I kept expecting that to be more relevant than it was.



  • @cmccormick said:

    If you're going to work in an environment where you have to cover your ass (CYA), learn how to do it well (e.g. keep an email paper trail or email a meeting summary copying bosses...if it ain't on paper, it didn't happen).
    "The more paper, the cleaner your ass"



  • @cmccormick said:

    • If you're going to work in an environment where you have to cover your ass (CYA), learn how to do it well (e.g. keep an email paper trail or email a meeting summary copying bosses...if it ain't on paper, it didn't happen). Better yet, don't work for a company that requires CYA, or one that would hire and then put up with a Benny, much less promote him


    Actually, rather than trying to CYA (although keeping a paper record is a very good idea) I think it's better just to have people trust what you say. That way, not only does it cover you when the other guy fucks up, it also covers you when YOU fuck up. That's clearly what Benny has spent his time at the employer doing. Buffing up his reputation until his word is practically gold.

     



  • @kilroo said:

    For some reason (despite how little it played into the events in question) I think I would have found this story a lot less interesting without the note at the beginning that Benny is "a fairly skilled programmer." Possibly because I kept expecting that to be more relevant than it was.

    I'd argue that note was wrong. A fairly skilled programmer knows when to save work by reusing the previous solution and knows when it's time to stop architecting castles in the sky and just slap the damn features together.



  • @Bulb said:

    @kilroo said:
    For some reason (despite how little it played into the events in question) I think I would have found this story a lot less interesting without the note at the beginning that Benny is "a fairly skilled programmer." Possibly because I kept expecting that to be more relevant than it was.

    I'd argue that note was wrong. A fairly skilled programmer knows when to save work by reusing the previous solution and knows when it's time to stop architecting castles in the sky and just slap the damn features together.

    You're right, of course, but given the context of the rest of the article, I just took it to mean the quality of the code he writes isn't the problem. Or to put it in your terms, when he actually gets around to BUILDING his castles in the sky, they don't fall apart.



  • It's weird Benny had that aneurysm at the end seeing as how he was so conniving for the rest of the story. It's not clear to me, but did you do the venting about Benny to William while Benny was there, or had he already left?

    And yeah, it's always a good idea to keep an e-mail trail whenever someone tells you to do radically different things than what you were tasked for. (Rewrite a C# program in Python when it's meant to interface with a native component? Really?)


  • Discourse touched me in a no-no place

    @Arnavion said:

    And yeah, it's always a good idea to keep an e-mail trail whenever someone tells you to do radically different things than what you were tasked for. (Rewrite a C# program in Python when it's meant to interface with a native component? Really?)
    Is the subtext that you think that Python can't interface with native components and C# can, or vice versa? That's a weird claim, as both languages have that capability. (The major thrust — keep a trail of what you were actually asked to do — is reasonable.)



  • @dkf said:

    Is the subtext that you think that Python can't interface with native components and C# can, or vice versa?

    No, just the fact that it appears to be primarily a C# shop, yet for writing something completely from scratch that involves interfacing with native code (a task that is not specific to either Python or C#) OP was asked, recommended even, to use Python. I'm well aware that both Python and C# can do it, and involve roughly the same amount of effort w.r.t. defining structures and marshalling.


  • Discourse touched me in a no-no place

    @Arnavion said:

    No, just the fact that it appears to be primarily a C# shop
    We don't know that; the article doesn't specify (I double-checked). In fact, with larger organisations it's quite possible for some parts to be strong fans of C# while others think Python is the One True Way.



  • @Arnavion said:

    It's weird Benny had that aneurysm at the end seeing as how he was so conniving for the rest of the story. It's not clear to me, but did you do the venting about Benny to William while Benny was there, or had he already left?

    And yeah, it's always a good idea to keep an e-mail trail whenever someone tells you to do radically different things than what you were tasked for. (Rewrite a C# program in Python when it's meant to interface with a native component? Really?)

     

    he sensed that his conniving was going to backfire  espacially after getting a lot of flack for sabotaging his own sandbox when other devs relied on it

     



  • @dkf said:

    @Arnavion said:
    No, just the fact that it appears to be primarily a C# shop
    We don't know that; the article doesn't specify (I double-checked). In fact, with larger organisations it's quite possible for some parts to be strong fans of C# while others think Python is the One True Way.

    You're right. There is still the fact that it started out as a C# application (admittedly one with a GUI instead of commandline) so rewriting it in Python is still silly.





  • @Arnavion said:

    It's weird Benny had that aneurysm at the end seeing as how he was so conniving for the rest of the story. It's not clear to me, but did you do the venting about Benny to William while Benny was there, or had he already left?
     

     Benny wasn't there for that particular meeting, it was me and the third engineer. Benny didn't show up to work until it was time for our later 'official' "what do we do now" meeting, where he prompty started yelling soon after his arrival.

     

    [quote user="Arnavion"] it appears to be primarily a C# shop, yet for writing something completely from scratch that involves interfacing with native code (a task that is not specific to either Python or C#) OP was asked, recommended even, to use Python[/quote]

    There's actually quite a lot of languages being used in my department, but the standard is usually c++ for application / performance critical code, C# for tools, and python for machine management / configuration management / automation utilities

     

     


Log in to reply