It seems that the primary usage of these terms is either:

  1. mutual mystification of contractors and/or clients who don't know what they are talking about or how to talk about it,

  2. the innocent and ignorant (see this question) , or

  3. laziness to avoid having to say user-interface/user-facing or business logic/database/infrastructure.

Granted, you don't always want to explain to the boardroom what the aforementioned terms mean. Is that justification for adding confusion by using these terms to generalize and mis-generalize all kinds of technologies?

  • 1
    Do you want to get rid of them completely or offer alternative/replacement terms? Aug 12, 2011 at 19:25
  • 2
    Even if all of SE would agree to this, how would you 'do away' with those terms? You can't change this kind of habit... Aug 12, 2011 at 19:27
  • 4
    delete from words where word like '(front|back)-end'; // TODO: clean up the Urban dictionary as well.
    – Job
    Aug 12, 2011 at 19:30
  • 1
    @Job - I'm all about saving characters, but when you use a word that creates confusion, the net result is many more characters.
    – Bryan Agee
    Aug 12, 2011 at 19:32
  • 2
    @Job: and after the Urban Dictionary we clean up Wikipedia Aug 12, 2011 at 19:33

5 Answers 5


This question must have been inspired by this one, and the answer is approximately the same. The "front end" and "back end" terms often make sense in a particular context. Most developers would understand the terms as they relate to compilers, for example. And the terms may also have well defined meanings in the context of a particular project. If you're not clear on what's meant by those terms in your own interactions, you should ask for clarification.

Since there's no practical way to "do away" with any particular jargon (are you going to send a memo out the the entire software development community?), the best you can do is to avoid terms that don't make sense to you. If you have some influence on your own project, you can certainly propose or dictate different terms. Aside from that, "front end" and "back end" are in common usage despite their ambiguity, and that's probably not going to change anytime soon.


In what way is it worse to say "back-end developer" than "developer who deals with one or more of: databases (coding, optimisation, design), business coding (except where implemented in the user interface), security, infrastructure, database optimisation, deployment, reporting, DR, scheduling, load balancing.

In what was is it worse to say "front-end developer" than " developer who deals with one or more of: user interface design, formulation of corporate standards, javascript, CSS and/or HTML coding, image manipulation, UX considerations, cross-browser compatibility validation.

The terms work, they are vague enough to cover a broad set of skills but specific enough to server a purpose.

I know many people (my wife, for example) who just hate front-end coding. She hates having to deal with user interfaces, coming up with the pretty - she just wants to write code to deal with a business function.


As long as they are used in the right context which does not imply or propose any ill-formed behaviors, I think they should be used until we can come up with better appropriate terms.


I see no problem with the terms. In many cases, they make perfect sense. Just because they do not meet your myopic view of the development environment you exist within does not mean they are incorrect or inappropriate in general.

In the context of which I exist, I am 100% a back-end coder. I write frameworks, tools, and API's with which our web team and internal application developers interact to get to corporate data. I haven't written any user interface code (in my job) in at least 2 years.


It's all relative. Everything has a "front" and a "back". It depends on what thing you're talking about.

The implication is that you need to define the context. Which, I thought, is important in any scenario.

Not the answer you're looking for? Browse other questions tagged or ask your own question.