Bad types of coworkers
If you feel like in a zoo when at work, you are not crazy and you are not alone. You will find few people discussing this, for obvious reasons, but I will share with you 16 types to get started, in the order in which I met them. Note: The quotes are approximate, I am not trying to be literal but to capture the spirit of the moment.
- The rushed: “We use SVN, I don’t have time to learn GIT”. If you waste your time with bad tools, you will not have time to learn the good ones. It is an investment with good returns and great compound interest, so start with as much as you can afford, e.g. learning GIT is about 5 minutes.
- The elevator: The elevator pushes any kind of complexity to the upper layer, ludicrously. What would be two function calls becomes one with the union of the parameters, e.g. “you have to specify a path for a temporary file”. Most languages today have a library to create temporary files without requiring the developer to specify a potentially clashing path (or to delegate to the developer using the corresponding function). Ideally, functions would not communicate by serializing through pipes, much less through files. But that is another topic.
- The indecisive: Particularly dangerous when combined with the former, a conversation could go like this:
— I am getting an error from your function, could you check it?
— I changed nothing, the error is internal to your function.
— Yes, I changed it.
The indecisive makes random and irrelevant changes, possibly to have a nice calendar with commits every day. Changes cascade into other changes, which eventually overflow beyond the limits of their piece of code. Interestingly, strongly typed languages may force code refactoring while weaker types may remain compatible with some changes, e.g. a function receiving JSON may receive a JSON with unused information and work seamlessly, while Rust may have issues when a former f32 becomes a u32. - The Luddite: “I am going to show you how to edit the file between both functions — *opens editor*”. Luddites are the human-in-the-loop, in every workflow they find a way to add a step requiring manual labor. In some cases, they may be doing something that may be easily automated, e.g. with regular expressions, but in some cases they may want to be sure that you are not a filthy robot, e.g. two factor authentication to your phone, every day.
- The Royal Highness: “I don’t write unit tests, I am not a software developer, I am a data scientist”. Unit tests help you to save time in the bug hunting, write your unit tests, be sure to have your code in working condition, and find something else to be busy (absent) when deadlines approach. It is at this time of the development cycle that royalty entertains the sport of bug hunting, without tests, and there is only one thing that they enjoy more than that, extending the invitation for the bug hunting to the colleagues that have done a good job and warned them about the consequences of their bad practices.
- The delegator: it is a worse kind of the Royal Highness. A conversation could be like this:
— There is no space in the HDD of the shared server, could you check it?
— I have no use of it this quarter, could you check it?
— Maybe… — *searches for the next candidate*
A delegator does not need to have a managerial position, a delegator may have nobody to delegate to, and yet search for excuses to delegate anything on anyone, the CEO if necessary (through an “elevator” approach). If delegators get to be managers, their experience and efficiency at delegating makes them very dangerous, as they are able to create unlimited amounts of busywork in an insatiable obsession to seem useful. - The fast-doer: “That would take one month, I have already solved it in two days”. The fast-doer takes a fast approach to a problem, with a toy architecture that is good for nothing, and then wastes indefinite amounts of time in futile attempts to make it work, because the good approach “would take too long”. Fast-doers use the short-term success to take the lead of the team, by jumping in the tar-pit of sadness. — Side note: There might be a connection between fast-doers and rushed (1), but I have personally not found bridges between them or deeper similarities.
- The fortune teller: “I have solved this kind of problems many times, we only need to fine tune BART with our data”. The fortune tellers know nothing, they will ask you to rephrase your questions until they can use the information that you provided in the questions to build an answer, peppered with something they have heard before even if they did not understand. Imagine a salesman, using the questions from one potential customer to make promises for the next one, with an ever growing set of slides.
- The aspiring lawyer: “Yes, but that is the accuracy, we need to check the mean error, it is completely different”. Aspiring lawyers find ways to ignore any evidence against them and make their point, just to delay their failure. In fact, failure may be avoided by buying enough time for the goals to change, as every organization has a component of headless chicken running and nothing lasts indefinitely.
- The positive: “Yes, and in addition of training a BERT classifier, we can make a GAN to extend the dataset”. The “yes, and…” is in theory a Google approach to meetings, but in the wrong hands it may mean constant and brutal derailments, to the point of making the meetings worse than useless. The positives only “add” in the meetings, never subtract. Normally, they add distraction, confusion, mistakes, and duration to the meetings.
- The pragmatist: “ha!, you speak like a professor!”. Pragmatism is powerful, and requires responsibility. Responsibly, pragmatism will help you to focus on what matters. Irresponsibly, pragmatism will be an excuse to focus on what you are comfortable doing, and ignore the threats that today are theory and in a few weeks time will be insurmountable obstacles to continue reporting progress. Pragmatists are similar to fast-doers (#7), except that they drive the team towards a “slow fast-doing”, and may not do anything themselves other than talking. A pragmatist is in fact a bridge between a fast-doer and “brief” (next point).
- The brief: “Explain in a simple sentence!”. When a fast-doer or pragmatist reaches the management level, there is not any “doing” in their world, only talking. The fast-doing becomes fast-talking, and therefore brief-talking. They are good friends with the positives, as they may participate in meetings through three word sentences: “yes, and GANs!”, which makes for an optimal addition of a buzzword, a technology, and a bulletpoint, in a fraction of a second. The briefs have a peak efficiency in pushing PowerPoint presentations up and down in the organization, and any thinking is just a waste of time.
- The artist: “20% of the time goes to the backend, 80% to the frontend”. It is aiming directly for lipstick on a pig, and in a sane workplace that would mean wrong priorities. However, in a madhouse, they may please managers, leaders, and even customers. If you just want to stay in the madhouse, those may be the right priorities. I have to admit: I am not even mad, if you enjoy the frontend, there is nothing wrong with that. Nevertheless, if you want to escape the madhouse, be careful with this trap. An artist is not harmful in isolation, but in a team, or when presenting traits from other groups, it may be an aggravating circumstance.
- The know-it-all: “A classification problem, best solved with random forest”. The only way to know everything is to misunderstand anything unknown as something known. The degenerate case of the know-it-all is a man with a hammer, only seeing nails. The know-it-all is a more general case, having several tools, they may find nails, screws, and bolts, and wrongly classify anything else. Worst cases may even mistakenly classify between two things already known to them.
- The time traveler: “I have noticed that problem, and I have already taken actions to solve it”. The time traveler speaks in the past tense about events that in the timeline of everybody else have not happened yet. Time traveling allows them to know the future, and to know all. Time travelers can create a greater mess than know-it-all by being the next step in their evolution and a worse case at that. Alternatively, time travelers may evolve from fortune tellers, normally less harmful, especially when combined with delegator traits.
- The hermit: “here is the URL with the OpenAPI spec, you are welcome to use it”. The hermit has had enough of all of the above and will seek isolation in as much as possible. Hermits want to work on their own projects, develop their own microservices, have their own repositories, and reduce interaction with coworkers to the minimal amount possible. The occasional link to the documentation of a new API would be the best possible scenario. Nothing wrong with them, they are neither good or bad coworkers as they are not coworkers at all. Added here for completeness.
There are several ways to escape coworkers to a greater or lesser extent, like freelancing, entrepreneurship, and becoming a hermit (16). Alternatively, you may choose to keep changing companies, for salary improvements or at least to see different parts of the zoo. Personally, I know I still have a lot of fauna to explore.
Take care, here be dragons.
