Terminology: developer vs. programmer vs. coder

De­vel­op­er, pro­gram­mer and coder are terms which are quite com­pli­cat­ed to de­fine. More­over, many per­sons just use them in­ter­change­ably, mak­ing things worse. Fi­nal­ly, de­f­i­n­i­tions from Wikipedia and oth­er sources don't em­pha­size enough the dif­fer­ence and, through long and com­pli­cat­ed ex­pla­na­tions, make things more com­pli­cat­ed they should be.

The dif­fer­ence ex­ists and is im­por­tant enough to chose a good term when search­ing for a per­son to hire. What dif­fer­en­ti­ates those terms is the scope of the tasks and the re­quired skills.

De­vel­op­ers

Mak­ing a com­plete soft­ware prod­uct re­quires a bunch of dif­fer­ent tasks to be done, and a bunch of peo­ple with dif­fer­ent skills.

While a de­vel­op­er shouldn't be nec­es­sar­i­ly able to build a com­plete soft­ware prod­uct, he should at least be able to deal with many as­pects of it, much more than pro­gram­mers or coders.

What de­vel­op­ers don't do

A de­vel­op­er doesn't have the nec­es­sary ex­per­tise nei­ther out­side the de­vel­op­ment field (which em­pha­sizes do­mains such as ac­count­ing, le­gal af­fairs, mar­ket­ing, in­ter­ac­tion de­sign, UX, pro­ject man­age­ment, etc.), but may of­ten have enough pro­fes­sion­al ex­pe­ri­ence work­ing on reg­u­lar ba­sis with ac­coun­tants, lawyers, sales­men, de­sign­ers, man­agers, etc. The more he knows, the eas­i­er is for him to un­der­stand those peo­ple and to work with them. More im­por­tant­ly, he may know when to ask those peo­ple to pro­vide their ex­per­tise. For ex­am­ple, he shouldn't be aware of the ex­act con­di­tions the prod­uct should met to use a li­brary un­der GNU Gen­er­al Pub­lic Li­cense, but it is high­ly ap­pre­ci­at­ed that he has a re­flex of ask­ing this stuff to the com­pa­ny's lawyer.

A de­vel­op­er doesn't nec­es­sar­i­ly have a deep un­der­stand­ing in spe­cif­ic de­vel­op­ment-re­lat­ed fields. He may not be able to re­cite the OWASP Top 10 list, but he's ex­pect­ed to know that an ap­pli­ca­tion where se­cu­ri­ty mat­ters should be re­viewed by a per­son spe­cial­iz­ing him­self in se­cu­ri­ty.

What de­vel­op­ers do

De­vel­op­ers are ex­pect­ed to have a broad knowl­edge of soft­ware de­vel­op­ment process in gen­er­al. This gen­er­al knowl­edge helps them de­ter­min­ing when they should ask for help to oth­er per­sons such as lawyers or se­cu­ri­ty ex­perts.

They may not nec­es­sar­i­ly know the par­tic­u­lar JavaScript op­ti­miza­tion tech­niques, but they are ex­pect­ed to know that when an ap­pli­ca­tion ap­pears to be slow to meet non-func­tion­al re­quire­ments of per­for­mance, one needs to use pro­fil­ing to find the bot­tle­necks.

They may not nec­es­sar­i­ly know how de­ploy­ment should be au­to­mat­ed, but should be able to eas­i­ly find va­grant, pup­pet and sim­i­lar prod­ucts and del­e­gate the task of au­tomat­ing the de­ploy­ment to a mem­ber of the team who is the most skill­ful in the sub­ject.

They are also ex­pect­ed to take the tasks which could have been han­dled by ded­i­cat­ed per­sons in larg­er com­pa­nies or pro­jects. For ex­am­ple, a large pro­ject may have ded­i­cat­ed ar­chi­tects. In small­er ones, hav­ing one is cost-pro­hib­i­tive. It is not un­usu­al to ex­pect from a de­vel­op­er to know well enough de­sign pat­terns, to be able to set up ba­sic in­fra­struc­ture tools such as a ver­sion con­trol, to un­der­stand things like cy­clo­mat­ic com­plex­i­ty or to teach their less ex­pe­ri­enced col­leagues how to use tools such as de­bug­gers.

This is why it is es­pe­cial­ly im­por­tant to have at least one de­vel­op­er in a team.

Pro­gram­mers

The task of a pro­gram­mer is a bit less gen­er­al and a bit more tech­ni­cal com­pared to de­vel­op­ers.

A pro­gram­mer should be able to im­ple­ment a bunch of re­quire­ments through code. While this task re­quires at the same time crit­i­cal think­ing, com­mu­ni­ca­tion, good lan­guage/frame­work knowl­edge and ba­sic pro­fi­cien­cy in the tools one should use to ac­com­plish the task, the scope is re­duced by free­ing the pro­gram­mer from the bur­den of think­ing about mat­ters which don't di­rect­ly re­late to pro­gram­ming.

For ex­am­ple, a pro­gram­mer shouldn't care if the third par­ty li­brary's li­cense is vi­o­lat­ed or if a piece of code should be re­viewed by a se­cu­ri­ty ex­pert: this is a task of a de­vel­op­er. On the oth­er hand, a pro­gram­mer who works on mak­ing a JavaScript ap­pli­ca­tion faster would bet­ter be know­ing JavaScript per­for­mance tricks or how to use a spe­cif­ic JavaScript pro­fil­er used in the com­pa­ny—tasks which may not con­cern a de­vel­op­er.

A pro­gram­mer may have a spe­cial­iza­tion which makes him a good can­di­date for tak­ing spe­cif­ic tasks from the back­log. At the same time, a good pro­gram­mer seeks to im­prove his skills by learn­ing mul­ti­ple lan­guages and can adapt him­self to the needs of the com­pa­ny.

Coders

Coders, like pro­gram­mers, write code, but the scope of their work is even more re­strained. They don't nec­es­sar­i­ly need to know de­sign pat­terns, and they don't nec­es­sar­i­ly have a spe­cial­iza­tion. At the same time, they may lack the flex­i­bil­i­ty of a skill­ful pro­gram­mer, for ex­am­ple by stick­ing to a sin­gle pro­gram­ming lan­guage and be­ing un­will­ing to learn oth­er lan­guages. This be­ing said, he is ex­pect­ed to know the lan­guage well enough.

Crit­i­cal think­ing is not a skill re­quired from a coder. Think­ing is of­ten done pri­or to giv­ing the work to a coder—of­ten by an an­a­lyst, a de­vel­op­er or a pro­gram­mer. A coder should un­der­stand the task in a giv­en con­text and know how to im­ple­ment it, giv­en that the task is usu­al­ly de­scribed in de­tail and in­cludes a de­tailed de­sign.

Some­times, they may be called by pe­jo­ra­tive terms such as “code mon­key” which tar­gets the fact that they do work on a ba­sic lev­el com­pared to pro­gram­mers or de­vel­op­ers.

This doesn't make them use­less in a soft­ware de­vel­op­ment pro­ject. Coders are in­valu­able where there is too much ba­sic work to do: hir­ing top notch de­vel­op­ers paid $100 per hour to do a job a $2 000/month coder can do is not only a waste of mon­ey, but also sim­ply bad man­age­ment which leads to low morale.

This be­ing said, one should be care­ful not to hire coders to do work which can eas­i­ly be au­to­mat­ed. Keep coders for tasks which are more elab­o­rate and ei­ther im­pos­si­ble to au­to­mate or very dif­fi­cult to au­to­mate.