The rise of the Geek
Popular culture tends to depict programmers either as antisocial geeks (such as the ones known from ”Silicon Valley” or ”IT Crowd” TV series) or as total nerds with pale skin, sitting in their hoodies by the glow of a monitor in a dark room. They have become the subject of myths and legends. Hard to understand by the mortals, with clearly insufficient social skills, and a set of weird behaviors – portrayed like that, they resemble creatures from the outer world.
This archetypal image of a programmer origins from the early hackers who were discovering the magic of computers at Stanford, Harvard, and MIT, and who shaped the technology we know:
“Hacking was a holy calling, a mission for these young men; computers were considered the magical key to the future. All that mattered about people was their »hacking ability«. Brain power was focused on finding the perfect algorithm, and the emotional realm of life was rarely explored (…) regarded as a distraction that took up precious »memory space«.”
(Jane Margolis, Allan Fisher, Unlocking the Clubhouse. Women in computing)
The image of an antisocial geek devoting his life to science and technology became stereotypical. As observed by Ellen Ullman, an American computer programmer and author, at a certain level… it is an honor to be odd.
“Strange behavior is expected, it’s respected, a sign that you are intelligent and as close to the machine as you can get. Any decent software engineer can have a private office, come and go at all hours, exist out of normal time. But to be permanently and sincerely eccentric–this is something only a senior research engineer can achieve.”
(Ellen Ullman, Out of Time: Reflections on the programming life)
Even now, when we are facing a cultural shift which merges the nerdy geek with a successful, cool guy, the old cultural image of a “computer guy” is still vivid. Geek may be the new chic, but it’s still… geek.
Why should I care?
The huge shift towards the digital technologies which lead to the triumph of nerdiness has also caused a change in the attitude towards programmers. The ability to communicate with software developers is no longer a ‘useful skill’ – it’s a must-have now. No matter if you try to manage a development team, recruit programmers or have any other opportunity to work with them – knowing their habits, preferences, and oddities will distinctly improve your chances in this league.
Surrounded by programmers, I’ve made some observations and prepared a list of the things that you should avoid when working with developers. Some of them can be omitted in an easy way (simply: don’t do them), others will require some extra effort. But we’ll get there.
The list was originally published as a Quora answer.
What do programmers hate?
- Being told what to do (or not to do)
This applies both to “Let this problem go, it’s taking too long” and “Please wash the dishes”.
- Being told when to do stuff (or when not to do)
Which again applies both to “It’s fine, we’ll stay with what we have, go home, and we’ll do it some other day” and to “Could you please wash the dishes now?”.
- Being interrupted
For the outside observer, the flow seems to be one of the most important things in a programmer’s work. When interrupted, they may either not react at all, or get angry that someone has the nerve to do it.
- Programming*
*which could, of course, go to the list of what programmers love as well.
You know it, right? “I hate programming! I hate programming! …Oh, it works. I love programming!” - Not understanding stuff
Being told what to do (or not to do) without being told why it actually needs to be done. Same with (not) knowing why something works.
Honestly, I can’t think of any other group with such a strong need to understand the world. It’s admirable.
- Boring tasks
Including both: tasks that don’t let them use their full potential, and things that are repeatable – writing components or features that are very similar to what they’ve been doing for another project.
- Technologies that they don’t use
The quarrels of developers working in different technologies are absolutely amusing to watch. “You write in PHP? That’s not even a language!” – “C#? God, why would anyone code in C#?” – “Ruby? Gosh, it’s so ugly. I can’t even look at this code!”
Read also: How to learn programming?
- Time trackers
I wish I could explain it, but I’m afraid I can’t. I think it may be related to their own sense of freedom and privacy. Tracking how long they work on each project seems to give them a feeling of being kept under surveillance. After all, it’s all about getting things done, and not about the time, right?
Luckily, there is a hack for that: make sure that they understand why it’s so important. There is nothing more frustrating than doing things only for their own sake… - HR people
Especially those who message them on LinkedIn. The longer I think about it, I get a feeling that it applies to all of the non-technical people they need to work with. Sales, marketing, non-technical project managers – we’re all guilty!
- Treating them as the “computer guys”
You’ve been there, right?
While to some parts of society to be a programmer means to spend a lot of time by computers and know them well, to programmers it’s like not seeing the difference between a singer and someone who fixes broken radios.
How to avoid doing these?
Simply: don’t do them!
Ok, let’s be serious. You can’t avoid all of them. Depending on your role in the project (or in the company), you may have to tell the developers what to do (or what not to do) and maybe even when to do it, ask them to use time-trackers, or ask them layman questions.
It would be absurdly wrong to run the project without telling your programmers what you expect them to do or setting the priorities. Or to build marketing strategy without understanding what they do. Or to recruit them without approaching them. Having the specific role, you have all the rights to do these things. It’s… generally acceptable. Unless you cross the line. Follow these basic guidelines and you will have a chance to find a thread of understanding with programmers.
“Basic guidelines to help you find a thread of understanding with programmers”
Never ever interrupt
As long as there is no fire in the building, no phone call from the hospital or from the police – it can wait. When you talk and the developer is not responding but his fingers are constantly typing something on the keyboard, he is probably in some different dimension. Respect it.
Don’t get too bossy
As long as the project sticks to the plan and your team is not wasting your budget, you have nothing to worry about. If the developers want to spend their spare working on some problem related to your project – it’s all fine. And it’s still fine when the next day they come to the office at noon. (Unless they have some meeting scheduled – then it’s not fine at all.)
Give a reason
When asking them to do something (or not to do something), tell them why it is important to you. Remember that you’re dealing with a group that has a huge need to understand the world. By the way, it was already proven that reasoning your requests can significantly improve your chances of fulfilling them. The experiment conducted in 1977 by Ellen Langer (Xerox Mindfulness Experiment) showed that as long as the request is small, giving a reason for a request, even the most nonsense one, is a much more effective strategy than giving no reason at all. Worth to remember!
Don’t be an idiot an ignorant
See what ‘programmer’ means and how it is different from the technical support or admin, make a cheat sheet of the technologies and learn the difference between a language and a framework. That should work at the beginning.
And if you really can’t avoid doing any of the above, at least show your sympathy. Make it clear that you hate doing it just as much as they do. This hatred-driven communication focused on the common “enemy” will help you find common ground.
