When you’ve been around the software programming block for a number of years, you start to gain a sense of how varied in personality and manners other software developer coworkers are.
You might think there can’t be THAT much variance between two software programmers, right?
After all, programmers are a logical, left brained bunch of folks who have a love of technology and computers, and they know how to sling code as soon as you push a keyboard in front of them, right??
Ok, maybe there IS some truth in that. Any software developer has to be at least COMFORTABLE with technology. After all, it’s our bread & butter and how we make a decent living.
Yet, it’s finally dawned on me that the things that make you, YOU, naturally flow out into the things that you do as well. Your personality quirks, your outlook on life, all seep through into your work life, like it or not.
In literature and movies, there’s a concept called the ‘archetype’ which you often see in the kinds of characters you often encounter in fictional literature. Things like the ‘hero’ archetype, are very common in epic literature.
Characters belonging to the hero archetype typically come from humble beginnings, and are often thrust into world changing events, either willingly or not, and end up being transformed into heroes that end up saving the world.
Much fantasy literature, including JRR Tolkien’s Hobbit and Lord of the Rings series, comprise of characters like Bilbo and Frodo Baggins, who are ordinary everyday common folk, who somehow end up being involved in events and actions that eventually defeat the major antagonist of the story and save the world.
Luke Skywalker is a humble kid who helps out his Uncle Owen and Aunt Beru as desert farmers on the planet Tatooine, until he is suddenly thrust into cataclysmic events that help him defeat an evil sorcerer called Darth Vader and help the rebel alliance destroy their world planet destroying satellite, the Death Star.
There are many other archetypical type characters in literature besides the hero. There is the thief, the outlaw, the explorer …. and many others. Pretty much all literature comprises of at least one or more of these kinds of archetypical characters.
If you’ve been in the software development field for awhile, you eventually encounter many kinds of fellow coworkers who seem to follow similar kinds of “archetype” type patterns as well.
I can think of at least FIVE major kinds of software developers (and i’m sure the list varies from person to person) that I’ve personally encountered during the course of my professional software career.
- The Elmer’s Glue Guy
- The Googler
- The Bleeding Edger
- The Legacy Guy
- The Open Source Disciple
- The Architecture Astronaut
THE ELMERS GLUE GUY
Sometimes we developers get caught up in all hands on deck, threat level midnight, firefighting scenarios where there’s some big production problem that means real actual lost revenue to the company.
In those kinds of situations, desperation can easily set in. When your boss is breathing down your neck and asking for status updates every minute, some developers can easily fall into what I like to refer to as the “Elmer’s Glue syndrome”.
When everything you’ve tried and know to fix an urgent production bug seems to fail, we can get into what I like to refer to as “copy paste mode”.
It’s the equivalent of the “throw the spaghetti against the wall to see if it sticks” mode of programming, where we grab ANY kind of code we can from other codebases or on the internet, to see if that fixes the problem.
Yes, it’s unbelievably dangerous to do, as there’s no guarantee copying and pasting code from something else will fix the problem. And more likely, it’ll cause more harm than good.
But never underestimate the power of desperation.
Pretty closely related to the Elmer’s Glue Guy syndrome is the Googler. Thanks to the incredible accuracy and sophistication of Google’s search engine, we software developers can pretty much find any sort of technical answer on the planet, via Google’s search engine.
And make no mistake, Google is a great STARTING place to find answers to find answers to immediate questions.
But the lure and power of Google can sometimes be deceiving.
Google is a great place to start locating the information you need. But unfortunately some developers find it the end all, be all one stop shop for all your information needs, which is simply not true.
Going to google to help me search for information is a great place to START. But there are PLENTY of other sources of information that software developers can and should rely on.
Things like technical books that really delve into subjects you want to know more about. Online video tutorials. The hands on experience and knowledge from fellow coworkers.
I find myself just as guilty as the next software developer who relies just a bit too much on google to get my information.
THE BLEEDING EDGER
I’ve come across software developers who absolutely adore trying out the latest and greatest bleeding edge technology.
It can come in many forms … software libraries, public APIs, new software development tools, pretty much anything that gets released on the internet and is available to any software developer who’s willing to give it a try.
And there is certainly no shortage of the bleeding edge technology on the wild west frontier of the internet.
Angular version 1.0? Pssh, that’s so yesterday. You need to get on the Angular 2.0 bandwagon!
AngularJS? That’s so ancient, buddy, you need to get onto ReactJS! It’s SOOOO much shinier than Angular!
And on and on and on.
I’ll be the first to say that learning and trying out new things as a software developer is one of the perks of computer programming. There is ALWAYS something new to learn, and no two days are ever the same. It’s actually a constant struggle to keep on top of all the learning and studying you should be doing as a software developer.
But the bleeding edgers continue to amaze me with their wholehearted devotion to the shiniest and newest toolsets.
THE LEGACY GUY
At the opposite end of the spectrum from the bleeding edge technology programmers are the legacy technology advocates.
They seemingly mistrust and openly disklike anything that is even REMOTELY newer in scope than whatever technology stack they have chosen to stick with, through thick and thin.
This is only conjecture on my part, but I think many of these legacy technology developers seem to equate job security with the fact that so few developers are still around that know how to use the same legacy technology.
After all, we all remember in Economics 101 that if something is in low supply but high in demand equates to a higher intrinsic value, right?
You’ll often come across these legacy developers in organizations that need to continue support a legacy application or underlying technology, like mainframe systems, because the perceived costs are considered too great to move off the legacy technology and into something more modern.
But if and when the day arrives when an organization does manage to move completely off a legacy technology, nobody should be surprised when those “job secure legacy technology software programmers find themselves with a little pink slip in their inbox.
THE OPEN SOURCE FANATIC
I love open source technology and standards, let’s get that out of the way first. The backbone of our internet has been built on either open source software or agreed upon standards which most major organizations have all agreed should be the golden “standard”.
Things like the TCP/IP and HTTP protocols are the low level foundations from which all computers and devices keep connected to each other on the internet, are based on open standards and open source software that anyone willing to spend some time and effort on, can learn as much as they want about the topic.
Probably the biggest open source contribution on the planet, is the GNU/Linux operating system and related software.
All one needs is a computer with an internet connection, and you can get a complete modern operating system and hundreds of thousands of commercial quality software without paying a dime.
There is no question that the free software foundation and open source movements have done much in the cause of empowering more people who may not have the means and resources to use commercially licensed software and operating systems … a truly noble and selfless quest for the betterment of everyone involved.
That said, there are certainly software developers and others in IT who can take that attitude and philosophy of ONLY using open source software to the extreme, almost like it’s a religious crusade.
I try to steer clear of these kinds of folks, if possible. Like the old saying about avoiding discussing religion and politics with people you don’t know, I’ve personally fallen into the trap of getting into those kinds of arguments.
All I can say is that’s it’s wasted time from my life I’ll never be able to get back.
THE ARCHITECTURE ASTRONAUT
The architecture astronaut archetype is the software developer or architect who likes to break down problems by abstracting them using concepts like design patterns and lots of theoretical concepts.
I’ve personally worked with software developers who couldn’t code something without the use of a design pattern or obfuscated way of doing something, because they read about it in the latest issue of “Architecture Astronauts”.
After all, why code something simple when you can apply a highly theoretical and questionable design pattern that will take ten times more code to solve your problem!
If it doesn’t fit, just shoehorn it! Square peg? Of course it’ll fit in a round hole!
Let me be the first to readily admit I’ve exhibited lots of these “50 shades of codemonkeys” in my history.
When I was younger, I was all about bleeding edge technology. As soon as I saw something new and shiny in a technical magazine or on the internet, bam! I quickly downloaded whatever it was to my computer.
When I first learned about the power and usefulness of design patterns, then EVERYTHING became an opportunity for a design pattern, whether it fit or not.
I’m still guilty of the Elmers Glue syndrome, especially when desperation sets in, and I get to the point where trying ANYTHING seems better than doing nothing at all.
As I’ve grown older and learned from my mistakes (which I’ve made PLENTY of, believe me!), I find myself getting a little bit of deja vu as I bump into other developers who resemble any of these programmer archetypes I’ve listed.
And before I get too incensed about encountering these kinds of programmers, I make sure to step back and remember that I was just as guilty of the same kind of programmer traits as the younger version of me.
Live and learn, as the old saying goes.
Now about that mullet I used to sport, let me explain ….