Home Home

Terminology: developer vs. programmer vs. coder

Arseni Mourzenko
Founder and lead developer, specializing in developer productivity and code quality
December 14, 2014

Developer, programmer and coder are terms which are quite complicated to define. Moreover, many persons just use them interchangeably, making things worse. Finally, definitions from Wikipedia and other sources don't emphasize enough the difference and, through long and complicated explanations, make things more complicated they should be.

The difference exists and is important enough to chose a good term when searching for a person to hire. What differentiates those terms is the scope of the tasks and the required skills.


Making a complete software product requires a bunch of different tasks to be done, and a bunch of people with different skills.

While a developer shouldn't be necessarily able to build a complete software product, he should at least be able to deal with many aspects of it, much more than programmers or coders.

What developers don't do

A developer doesn't have the necessary expertise neither outside the development field (which emphasizes domains such as accounting, legal affairs, marketing, interaction design, UX, project management, etc.), but may often have enough professional experience working on regular basis with accountants, lawyers, salesmen, designers, managers, etc. The more he knows, the easier is for him to understand those people and to work with them. More importantly, he may know when to ask those people to provide their expertise. For example, he shouldn't be aware of the exact conditions the product should met to use a library under GNU General Public License, but it is highly appreciated that he has a reflex of asking this stuff to the company's lawyer.

A developer doesn't necessarily have a deep understanding in specific development-related fields. He may not be able to recite the OWASP Top 10 list, but he's expected to know that an application where security matters should be reviewed by a person specializing himself in security.

What developers do

Developers are expected to have a broad knowledge of software development process in general. This general knowledge helps them determining when they should ask for help to other persons such as lawyers or security experts.

They may not necessarily know the particular JavaScript optimization techniques, but they are expected to know that when an application appears to be slow to meet non-functional requirements of performance, one needs to use profiling to find the bottlenecks.

They may not necessarily know how deployment should be automated, but should be able to easily find vagrant, puppet and similar products and delegate the task of automating the deployment to a member of the team who is the most skillful in the subject.

They are also expected to take the tasks which could have been handled by dedicated persons in larger companies or projects. For example, a large project may have dedicated architects. In smaller ones, having one is cost-prohibitive. It is not unusual to expect from a developer to know well enough design patterns, to be able to set up basic infrastructure tools such as a version control, to understand things like cyclomatic complexity or to teach their less experienced colleagues how to use tools such as debuggers.

This is why it is especially important to have at least one developer in a team.


The task of a programmer is a bit less general and a bit more technical compared to developers.

A programmer should be able to implement a bunch of requirements through code. While this task requires at the same time critical thinking, communication, good language/framework knowledge and basic proficiency in the tools one should use to accomplish the task, the scope is reduced by freeing the programmer from the burden of thinking about matters which don't directly relate to programming.

For example, a programmer shouldn't care if the third party library's license is violated or if a piece of code should be reviewed by a security expert: this is a task of a developer. On the other hand, a programmer who works on making a JavaScript application faster would better be knowing JavaScript performance tricks or how to use a specific JavaScript profiler used in the company—tasks which may not concern a developer.

A programmer may have a specialization which makes him a good candidate for taking specific tasks from the backlog. At the same time, a good programmer seeks to improve his skills by learning multiple languages and can adapt himself to the needs of the company.


Coders, like programmers, write code, but the scope of their work is even more restrained. They don't necessarily need to know design patterns, and they don't necessarily have a specialization. At the same time, they may lack the flexibility of a skillful programmer, for example by sticking to a single programming language and being unwilling to learn other languages. This being said, he is expected to know the language well enough.

Critical thinking is not a skill required from a coder. Thinking is often done prior to giving the work to a coder—often by an analyst, a developer or a programmer. A coder should understand the task in a given context and know how to implement it, given that the task is usually described in detail and includes a detailed design.

Sometimes, they may be called by pejorative terms such as “code monkey” which targets the fact that they do work on a basic level compared to programmers or developers.

This doesn't make them useless in a software development project. Coders are invaluable where there is too much basic work to do: hiring top notch developers paid $100 per hour to do a job a $2 000/month coder can do is not only a waste of money, but also simply bad management which leads to low morale.

This being said, one should be careful not to hire coders to do work which can easily be automated. Keep coders for tasks which are more elaborate and either impossible to automate or very difficult to automate.