The trouble with developers is that you can never tell what a developer is doing until it’s too late.
Chris Oliver nails it to perfection when he says.
Give a man a program, frustrate him for a day. Teach a man to program, frustrate him for a lifetime.
Have you ever been frustrated by something beyond belief? Wanted to quit, give up, or walk away?
You’re not alone!!!
Welcome to the magical world of programming!!!
Programming, coding, and problem-solving are all very similar in nature: you get into a frustrating hellhole and then figure out how to get out of it. The art of learning involves becoming very familiar with the process of figuring it out when things go wrong.
But the good part is that you are not alone out there.
You have interesting companions, project mates, project enemies (or whatever else you can call them), who make sure that project execution is never a dull and boring activity. You have some code warriors who make wonderful comrades in arms and some others who are a constant pain in the ass.
However, they all have their place in the pantheon of software development. Without a healthy mix of these different programming styles you’ll probably find your projects either take too long to complete, are not stable enough or are too perfect for humans to look upon.
And here are some of those wonderful developers I encountered in my programming career.
I Douse the Fire
Bernard Williams rightly said.
“Talent is a flame. Genius is a fire. “
“Client demo is in the next 30 minutes; the damn screen is not opening.”
“Code was working in UAT.what the hell happened in production.”
“Nobody knows the purpose of this function. Why the hell was it written.”
In times like this, we need a developer who is calm, composed and street smart. He or she does not spend time in “formalities”, “best practices” or any hi-fi coding jargons. The need of the hour is speed and he will precisely identify the root cause and resolve the issue.
Nobody questions his methods; he questions nobody’s methods. The damn thing is working again. All thanks to this god-send guy!! The show must go on!!!!
I am the Code-o-Pedia
Brie Larson hits the nail on the head when he says.
“I just don’t want to stop finding things interesting. I don’t want to ever stop learning. I want to be a weird encyclopedia of bizarre knowledge.”
“I just coded a brilliant traffic light logic. The client will love this functionality.”
“The re-usability factor is very low. I am rewriting the code again.”
“I just discovered an exciting new function to do the same job. Let me try to use it now.”
So what you have here is a gold plating expert. The issue with gold plating is that while it satisfies our coding ego, it does not bring money to the table. The client will only pay for the features that are agreed. The others are just “goodwill” gestures which mostly don’t auger well in times of stiff deadlines.
These developers have to be constantly restrained, cajoled and convinced to channelize their energies towards project completion.
And if that does not work, bombard them with dates, stiff dates of completion at all times!
I am the Google
Temple Grandin gets it right when he says.
“I’m a visual thinker, not a language-based thinker. My brain is like Google Images.
His world is very simple. If you don’t know something, Google it. Never think when somebody else has already thought about it. The objective is to finish the work with the least possible effort which also includes writing the least possible code. After all, today’s world is all about code optimization and lean thinking, why not use it in real time!!
Such developers are uncanny “search” experts and have the ability to ferret out any information out of the internet. They, however, become a liability when their “thinking” cells have to be put in use and there are no options available except writing “original” code.
I love Deadlines
Douglas Adams rightly said.
“I love deadlines. I like the whooshing sound they make as they fly by.
“Client wants this functionality to be delivered by next week.”
“No problem you will have it by this week.”
“Are the requirements clear to you. Do you want to have further discussions?”
“Not required. Let me finish the work and then we can see.”
“Let us finish your code review today. When can we sit?”
“Uh, hmm, busy right now in finishing the other code due today. Any case, code is all fine and working, so why bother ?”.
The problem is shoddy delivery and poor quality of code. These guys revel in dates; the closer the merrier. They will meet all the deadlines. The client will be happy. The management is happy. The code also works as of now.
But all hell breaks loose when their code goes to production. But mostly by that time they would have “conveniently” ensconced themselves in another project away from the reach of everybody!!!
So review, code review, peer review and any other type of review are the only weapons available that can keep these guys under check. They are a real pain in the ass so watch out and take action!
I Love Requirement gathering. It pumps me up
Will Rogers correctly have said.
“Even if you are on the right track, you will get run over if you just sit there.”
That is precisely what happens to them.
They get “Run over”; by time, by schedule and by everybody
And that is just because their requirement gathering phase never seems to end. They keep polishing the requirements, going all over them again and again like a tooth-comb, giving options, creating options and thinking of scenarios that would not even have an iota of chance of getting realized in the real world.
And all this results in missed deadlines and delivery of a software with incomplete features and a constant crib accompanying the same.
“If I had more time, I would have done this the right way.”
It almost never seems to work their way in the real world.
They fail to realize that, in the real world, requirements are as fluid as ink and constantly evolving. If you try to over-engineer the requirements, you end up wasting everybody’s time. Such developers require mentoring and a very very heavy dose of time management, every single day!
Where do you fit
Always remember, there are no good and bad programmers, there is only perception. There is the event itself and the story we tell ourselves about what it means. So When you’re solving a puzzle or working through a problem set, you are not a good or bad person; you’re just a person.
You are just yet another type of developer!!!
So, which type of programmer are you? Or perhaps you know another programming archetype that is missing from my list? Post a comment below and I’ll add it to a new updated list.
About the author-:
Ravi Rajan is a global IT program manager based out of Mumbai, India. He is also an avid blogger, Haiku poetry writer, archaeology enthusiast and history maniac. Connect with Ravi on LinkedIn, Medium and Twitter.