Coworker Series — When the First Thing A New Hire Suggests is to Demolish the Entire System. The Story of P: Part 1
Sometimes, we hear stories about developers being disconnected from the product roadmap. This means these developers would focus on code quality and best practice (which are good things) and completely disregard the product deliverable (but this is bad). This is the story about a coworker who is very adamant about the architecture while being completely oblivious of the rest of aspects of the product. To protect the identity of this person, let’s call him P.
When we interviewed P, he did a good job on whiteboarding and system design. From his resume, he has both the quality of a good dev and good entrepreneur. At the time, all of us were ready to hire him, except our PM who has concern about P’s focusing on having new and shiny tech and none about product deliverable. As a developer, I was actually favoring that thinking we want another strong voice to fight back on constant scope creep, so I was being “meh” about his concern.
What even solidified his hire was the fact that he wants to interview our dev team. This is actually the first time that I was being interviewed by someone who’s looking for a job. We are not talking about those “do you have any question for me or the team” types of questions. He actually requested a full session for each member on our team to ask us technical questions like “how many ways can you revert an array.” Frankly, it was a bit weird, but I actually liked that mentality thinking he wants to work with smart people instead of people who got hired by luck and leetcode grinding only.
P was hired as a lead engineer. We were excited to bring him to work. Little did we know, it was the beginning of a fiasco……
On the very first day of work, we were introducing him to our system and how to get the local environment running. You know, typical onboarding stuff. Granted, our system wasn’t perfect, but we made it work. However, this system somehow becomes the garbage of the garbage to P. A simple 30-minute rundown of the system turned into session featuring P doubting the validity of the system, with questions like “why does your system suck and why aren’t you doing anything about it.”
I got annoyed. All devs got annoyed. Our QA got annoyed. Our PM got annoyed. Hell, he started a fight with our CTO on day one, and our CTO was one of the nicest guys I’ve met. Still, we told ourselves, “Hey! This is good! A fresh pair of eyes and a willing voice to make a change. We’ll make this work!”
Then it came to the end of work day, again, on P’s day one, when he sent out an email to the entire team suggesting a complete overhaul of our system, estimating a 6-month with no new features and simply maintaining the system while working on improving (read: creating a new) architecture.
A little background: our system at the time was basically a Django monolith web app serving API endpoints for backend and Angular for frontend. P suggests that Django is slow and bad, and he wants to switch to Flask and ReactJS. We always had plan to abandon Angular at one point, but these transitions are slow by making the service layers usable by both Angular and React apps (some remarkable work done by our frontend devs). What P was suggesting is “we just drop Angular and rewrite everything from scratch.” If we double our headcount, we might be able to spin off a project and dedicate some developers for that, but at the time, we didn’t. In addition, Django was the backbone of the backend. Changing it to Flask is simply creating a new system. Django worked fine for us, and P did not provide enough reason to convince the rest of the team to trash Django.
Keep in mind, this is all on top of not being able to deliver new features to clients for 6 months. We were a small startup. This simply won’t happen.
Day two, P came in work late, and before he got into the office, our CTO sent out a team-wide email stating that we already have our quarterly and yearly goals and deliverables decided. Our director of engineer team told us that we are going to discuss this in standup. We all knew he was saying this to keep P on leash a bit. Because P was late, we delayed our standup. 11:30am, P finally showed up. He apologized saying he had some personal business to deal with. We were a bit annoyed but thinking this would be important like family matters, so we didn’t say anything. Standup started, and our director mentioned our goals and stated that we do not intend to change that. P seemed okay with it…. at first.
Later in the afternoon, P sent out another team-wide email stating how bad and slow Django is. He provided a few examples, but none of them would make his case stronger. For example, one item would be comparing a “INSERT INTO table…” with Django’s “get_or_create”. He went into depth and provided profiling results. Our CTO countered that by saying he’s comparing apples to oranges since these two functions are not equivalent. P ended the discussion with “I guess I have more onboarding to do. (smiley_face)”
We thought this was the end of it and could finally go onto integrating P into our team. Only if this was true……
(To be continued…)