What Type of Developer are You?

In my 10 years experience working with companies with different sizes and industries, I see a different type of developer, programmer, analyst. But if I can put it into two different polar opposite it will end up with these 2 types. Most of them fall in between these 2 disciplines.

The first one is a Hard Core Techie, in the extreme, he/she:

  • likes to read a manual from cover to cover.
  • Likes to do things in order.
  • The code produced by them is squeaky clean and well commented.
  • Very organized with backup and file naming convention.
  • Great for strategic initiatives.

 

The other type is MacGyver style, in the extreme, he/she:

  • Always has a sense of urgency.
  • Great with deadlines, and will do whatever it takes to get the job done and on time.
  • Jack of all trades, can do a little bit here and there, enough to fix the problem. 
  • Know how to use different technologies to make things work. Sometimes the solution is a pass down from 1 tool to the next.
  • Great for tactical solutions.

 

Now, the question is which one is better? If you have a team and you need to add a member to your team, which one should you pick?

In my opinion, you need both. I'd like to take this approach when illustrating my point. When you see somebody sick and in trauma condition, you want to have an Ambulance take care of the sick first, the Ambo tech will first stabilize and make sure everything ok, he will assess all variables and the environment to make sure the patience is good, THEN bring him to the hospital to get checked by a surgeon/doctor.

You need both on your team, you need somebody with MacGyver personality to immediately fix things so production/development is not interrupted, but then escalate the issue to the Hard-Core Techie to check if it has a potential to happen again or if it is an isolated incident that doesn't need further time and resource.

What happen if you don't have a resource to have both in your team, or if you are the only developer/IT in your company. The above approach needs to be observed. First, make sure all the system is working, forget about root cause at this point. Then when all is good, go back and investigate the root cause and implement different measures so that it won't happen again.

Many times I see, developer approach issue as a surgeon, and get bogged down with complex solution for a simple problem, a problem that might not happen again.

Next week I will discuss about my experience in identifying which personality serve best for different area of the development.

To receive updates and tips/tricks on improving productivity through technology, please subscribe to  our newsletter on the right.