Types of IT developers

IT developers are a strange breed. They’re geeks by nature, peculiar in their ways but, at the same time, very different from the old geek stereotype of 20 years ago. In all my years working in IT, I met many different types of developers. When I say “types” I do not mean skill level, that’s easy to identify. What I mean relates to their way of working in the business, their way of solving problems, their way to get the job done. Over the years, I realized that it’s easy to understand if I need a Junior, a Middle, or a Senior developer but it’s not so easy to understand what “type” of developer is better suited to take on a specific position in a project.

Full stack vs Specialized

The first distinction I want to point out is between full-stack and specialized IT developers. A full-stack developer has a functional, and sometimes robust, knowledge of all areas of development. Full-stack developers can grab your idea, analyze it, develop it, deploy it, and support it almost single-handed. If you’re a startup with a new idea, limited resources, and you need to go to market asap, then having a couple of good full-stack developers is your best bet. On the other hand, full-stack developers are not a good idea if you plan on building a solid application for years to come. Full-stack developers won’t give you the level of commitment that is required when you are building a product that needs high maintenance and  support.

Specialized developers spend their time improving their skills on one specific area. The knowledge that a specialized developer brings to the table is much higher. Nowadays the segmentation of software technologies and tools is so big that full-stack developers cannot keep up with everything. If you are building a product that supports several technologies, devices, and a big user base, then you need specialized developers to support each part of your product individually.

Developer Personalities

Another area that I want to describe is the different personality types you may find when hiring IT developers. Hiring developers, especially to become part of an already existing team, requires analysis not just of hard-skills and seniority, but also of personality and chemistry. Here’s my list of the 5 main developer personalities you may come across:

1. The “Workaholic”

workaholicThe workaholic practically lives at his desk. Even if you don’t ask for it, the workaholic will put in extra-hours, do all-nighters, work on weekends and neglect any other aspect of his life to work on your project. His free time is spent reading up on new “cool things” related with his area and he takes pride on the sheer amount of lines of code he commits. The workaholic does not mind the mundane repetitive tasks that your project require. He’s more than happy to bug fix, and will spend hour after hour writing thousands of lines of code on your application.

Having workaholics in your team is great if your project is huge, but don’t expect them to make decisions related with architecture. They are working bees, not leaders.

2. The “Researcher”

researcherThe researcher is more interested on identifying approaches than actually making a decision and writing some code. While his knowledge is extensive, he needs to define every single possible outcome before committing to anything. He can talk for hours about all possible ways to implement a field validation, and when he is done, he’ll review everything all over again.

If you are building a ground-breaking application, and you have a fairly loose timeframe, having a researcher on your team is great. He will make sure your team analyzes all the possibilities before implementing any feature. The downside is that you may have an obsolete application when you are done.

3. The “Architect”

architectThe architect is a leader by nature. His extensive knowledge and experience makes it easy for him to convince you and the team that his way, is the right way… even when it’s not. The architect thrives on solving problems, give him something simple and he will lose interest in 5 minutes. The quality of his code is far from perfect, his goal is to solve the problem. Mundane tasks like validation, testing and quality assurance are for someone else. He usually takes the lead on everything complicated and his communication skills make him a good choice to replace a project manager and/or a business analyst.

If you have limited resources, strict timelines, or unclear requirements, hire an architect for your team. He will turn your idea into an application. But be careful, two architects working in the same project is a recipe for disaster.

4. The “Google-it”

googleitThe motto of this developer is “don’t reinvent the wheel”. He will almost always find a library, framework or tool that “almost” does what you need. He will argument on how much time may be saved by using someone else’s code instead of writing everything from scratch. The result of his approach is, most of the times, quicker but it is also limited and hard to extend. His actual contribution to the overall code-base is minimal and, most of the times, detrimental to the quality of the application.

A “Google-it” developer is great when your project is 99% similar to something that already exists, or if your project is basically a mashup of several open-source projects. Startups can benefit of having these developers in their team but if you are thinking of growing your project without completely rewriting it, then watch out.

5. The “Quick-fix”

quickfix

If you have a tight deadline, or legacy code in production, this developer is a must-have. He will build and keep the machine running by himself if he can. The problem is that sometimes the machine becomes too big for him to handle alone, and that’s when the real problems begin.

Depending on your project, the state of your specifications, and your overall skills to manage the project you may need one or several of these types of developers. When hiring a developer, make sure you know exactly what type you need and consider all its aspects when interviewing. Remember, the quickest way to project failure is an uneven team that can’t work together.

 

Daniel R.

PHP developer and consultant. Enjoys solving problems, building apps and (occasionally) breaking stuff. Currently lives in Poland and works for an american startup focused on data-gathering.