Let’s talk about Dysfunctional Programmers
Sarunas Savicianskas Jan 9 '17
Let’s talk about some nice keywords people in the tech world like to throw around. Let’s talk Agile and all the nice processes it offers to ignore putting processes over people. One of those keywords, and topics, following it, has been stuck in my head for quite some time now — the dysfunctional team. It’s a very nice topic to discuss and to try to understand to help any team. I won’t go over what it’s about and what it offers — you can look it up, and, possibly, it will get you thinking also. It got me thinking about the teams I’ve worked with over the years.
I’ve been working in various businesses (startups and corporates) for quite some time now — coding, creating architectures to scale or MVPs to prove a concept. I’ve noticed a couple of traits, which some engineers have and are quietly nurturing. It’s not about the teams or “dysfunctional teams”, but more about the engineers, or “dysfunctional programmers” as I would like to call them. It’s not a list to define them, but a list which pops out when I think about that the term.
What do successful dysfunctional programmers do over and over?
1. They don’t like specs
It’s not about liking or not liking the specifications per se. It is about the fact that engineers like to create solutions to problems. That’s very cool, because their passion for work comes from solving problems.
Dysfunctional programmers actually start planning the solutions and answers in their heads, without even looking into specs. Over time it leads to a lot of situations where features and solutions are constantly over-engineered, everything takes too much time and there’s a constant conflict between “the developers” and “the business”.
2. They always build for massive success
It’s definitely very important to understand and build good solutions to specific problems. But that doesn’t mean that every single solution has to scale or scale from day one.
Dysfunctional programmers like to think that every single product or feature will be used by millions of users. There is no scenario where the first iteration could actually be used by a couple of customers / users. There is no point in allowing the product to show which parts need to scale and which do not, because everything NEEDS to scale.
3. They build solutions upfront, instead of presenting ideas
It’s very important to have initiatives — it brings new and out-of-the-box ideas. Those ideas sometimes push startups to the point where pivots happen by pinpointing the solution to the problem they are trying to solve. Usually that involves good communication and talking through ideas to become solutions.
Dysfunctional programmers do not like talking through ideas. Or, what usually happens, they present it once, communicate the idea poorly and don’t get the instant hype they expect. That leads to them choosing to close off from the world and BUILD or, most likely, rush through other tasks to spend as much time on building a solution based on the presented idea.
(This is definitely not a full list, but you get the point.)
Do you work with a Dysfunctional Programmer?
Most likely you have worked or still work with someone who is a dysfunctional programmer. Very likely you are or have been (or will be) a dysfunctional programmer at some point in your career (I know I’m not only pointing fingers when I’m writing down these bullet points). They are very often pretty good technical people also. They are very often very important to their companies — the Heroes who save the day. It’s usually a mix of luck and the fact that customers and businesses do not know themselves what they want to build.
Look out for them — they are followed by pretty solid egos. They can teach you a lot of good things technically (up to a point), but they can damage you professionally also, because they never fail and know everything already. It’s exactly for these reasons I also call them team destroyers.
- Try to spot them early and don’t get overhyped by the results they (sometimes) bring.
- Build teams which can translate the business requirements to simple solutions.
- Build solutions for the scale which is needed at a specific point.
- Build teams which can communicate ideas well enough to be able to build together.
This article was originally posted here.