current community

your communities

more stack exchange communities

Stack Exchange
tour help
Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.
up vote 2 down vote favorite
2

I was just googling around to find a good definition of front-end developer and the definitions that I found were pretty much "a guy that does HTML/CSS/JavaScript (jQuery)".

But I think this is no longer the case. Today we have very complex interfaces, say a single page BackboneJS app that require a lot more than just "a guy that does HTML/CSS/JavaScript" and has no background in Computer Science.

I would argue that the guy that engineers the front-end app (Backbone, Angular, etc) should be as (if not more) skilled programmer than the guy that engineers the back-end.

So in my scenario (single page webapp - say with Backbone), I have 3 people:

  1. A back-end programmer - the guy responsible for all the API calls that the Backbone app would make
  2. A "front-end" programmer - they guy that's responsible for getting the work from the designer (wireframes if you will) and turning it into responsive, cross-browser, cross-platform HTML/CSS code
  3. The "JavaScript" developer who makes everything light up, hooks up the HTML/CSS to the API and brings the app to life.

My question is: What is the most usual modern dev team structure? How is the work usually divided between the front end and back end developers.

Of course if you only have full-stack developers that can produce JavaScript and say PHP equally well, then you have less of an issue. But still, who is the front-end developer and how do you call "the JavaScript developer"?

Excuse my simple language, I tried to stay as far away from terminology as possible.

share|improve this question

closed as primarily opinion-based by gnat, MichaelT, Bart van Ingen Schenau, thorsten müller, Ross Patterson May 13 '14 at 10:57

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.
    
I made the question more objective by asking for the "usual" development structure, and wonder if the question can be be reopened in its current form. –  Tom Au May 13 '14 at 22:50
    
@TomAu, thank you! I am really curious to see what other people think. I also would like the question to be re-opened. –  Teodor Talov May 14 '14 at 2:35

1 Answer 1

up vote 1 down vote

I agree it sounds like you do have a 'modern' dev team structure. Much like the last few I have been a part of.

I think inefficiencies can arise from defining responsibilities or 'domains' as intrinsic properties of the team though, it smells too much like a collection of jobs rather than a team of engineers adding the most value they can towards achieving a common goal.

I think full stack familiarity is essential, so everyone fluently speaks the same language - describing problems and solutions precisely (end to end if appropriate) builds confidence in the direction of the project, and accelerates discussion of the hard problems. It also creates an 'us', an 'our thing' for each team member to get behind and own. If just one guy is 'the UI' you have a doorway to concepts like blame and martyrdom creeping in to the dynamic.

Conversely, shared ownership and skills, combined with having true expertise in specialised areas creates a fertile ecosystem where each member is inspired by their teammates, and has the empowering experience of building a fulfilling contribution, in which they 'led' the whole team, inspiring I turn.

Above all, my opinion is there should be a recurring focus on the user, and the design of an ''experience' which transparently 'just works'

Honesty and trust in your team's abilities can't be manufactured, however a culture with a pervasive appreciation of real customer service is what I've seen work before, to great effect.

share|improve this answer

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