Coworker Series — When the First Thing A New Hire Suggests is to Demolish the Entire System. The Story of P: Part 2

Jonathan Chao
4 min readMar 1, 2022

(If you haven’t read Part 1 and would like to know the entire story, please check Part 1 first)

P really doesn’t like Django. I don’t know what has happened in the past but he really tries everything to demolish future development using Django at our company. As we continued to integrate P into our team, we started assigning small tasks to ease him into the architecture, supposedly something rather simple and small thing to do.

If I recall correctly, the task was adding a button in a page calling an existing API with some JSON as payload. If you know what you’re doing, this should take a couple of hours. When receiving the task, P immediately talked to our manager requesting to do an overhaul of the system once again, claiming that if Django cannot be touched, we should at least switch from Angular to ReactJS right away.

He was once again explained that it’s in the roadmap, just not now. P then claimed that there’s no point doing this task if we know we are going to switch to React later. Our manager finally had enough and simply said “Regardless of how you feel about architecture, I want you to do this task.” or something close to that.

P gave in, sort of. My desk was right across from his at the time, so I could see how he was doing. I was expecting that he would come to me and ask some questions because, well, that’s what new employees do, right? However, P did not ask any question. He sat at his desk for the rest of the day, occasionally having a chuckle while looking at the code. Our other coworker thought he was laughing at the code, but no one really knew what was really in his mind.

Next day, P was late again. Wondering what’s troubling him with being on time, we casually brought it up and asked if he needs help. P explained to us saying that he was doing business with some other parties because that’s the only available time for them. That was really an unexpected answer. What was even more shocking was that he said it with a straight face, not even trying to sugarcoat it. I get that we don’t track when and how people do their job as long as the job is done, but it’s still surprisingly to me that he didn’t even try to hide it. At this point, I officially put the “weird guy” tag on him.

Our management team really did a lot of special things for P. On top of the “we are keeping Django” message, our CTO sent out another message to the team saying that we have set the standup at 10:30 am and everyone should respect it and show up on time so no one has to wait. We all knew who this message was for.

P become the focal point of the office gradually. Our team members got frustrated. Management got frustrated. Other teams who had to work with him also got frustrated. It was simply a mess at the point.

The last straw, I believe, was the incident when P has overwritten everything in our staging environment. At the time, we were doing a big project reconfiguring and renaming bunch of models. We had to do some special maneuver to make Django not complain. This made the process not able to be automated.

One of our teammate, let’s call him M, was responsible for this and had done a lot of work on it. The work had finally moved to staging and he had done all manual works needed. Then for some reason, P thought it was okay to move changes to staging without code review and qa approval (basically skipping 2 lower environments + peer review). On top of that, P ignored the git conflict message and forced the change in. Thanks to that, staging environment was broken, and all work M has done was gone. Now it took double to time to even get staging back to how it was before all the changes.

M fixed all that, claiming that this is harder than making all these changes and it’s wasted a lot of time. He talked to us saying that he‘s not happy with P.

Immediately, P forced some other changes into staging again, which broke staging and all M’s work. Now M is really PISSED. He grabbed our manager and talked to him in a room for good 45 minutes. No one else was in the room, but we could all guess the conversation wasn’t exactly joyful.

At the end of that day, our manager grabbed P into HR’s office, and P was let go. There was a sigh of relief after everything was done. P was gone; things were back to normal; we had to resume the hiring process, which at the moment we were very happy to do so that we didn’t have to work with P.

I seriously thought P was very smart and knowledgeable when we were interviewing him. Thinking back, there were some red flags we should have noticed. The biggest one might be our PM saying P would ignore all roadmap and just want to upgrade everything to his desired tech. On the bright side, I guess I’m glad that the damage was minimal (except for M), and we could learn a valuable lesson about what to look for next time when we interview a candidate. On the other hand, we can safely say it was not a very pleasant experience for all of us.

I hope the best for P, but I would not want to work with P again.

Buy me a coffee: https://www.buymeacoffee.com/jonathanckz

--

--

Jonathan Chao

I am a software developer who has been in this industry for close to a decade. I share my experience to people who are or want to get into the industry