Starting a relationship with your backender

by Bran van der Meer

I'm a frontender who works directly in the back-end template engines whenever possible. This makes me run into all the gray area in between front-end and back-end. This is the right place where quality and neat code should be made, but where often problems arise due to lack of inter-developer communication.

I work like this mostly because I've been a (evil) backender myself for a big part of my career, and I've worked with a lot of the template engines already. And maybe I like to get to know all the dirty little secrets of the back-end implementation as well.

The biggest advantage of being responsible for the code in the templates engine is being in complete control over how your code will end on the web. The backender doesn't have to translate your static code to a template engine language anymore, which most of them don't like anyway. And you won't forget about that one obscure use case your code will live in. Win-win.


You will have to infiltrate the domain of your backender. He will not allow you access to his template engine lightly. So you're going to have to explain what, why and how you're going to do it.

Take for example a page that has a table and some filters. Often the backender did not yet think about how the filter feature will actually work. There could be a redirect with JavaScript, triggered by a onchange event on a select element. But you could also simulate a http post so you can put a form element around it, which would be better for accessibility. Both solutions require implementation work from the frontender and the backender, depending on the actual solution. This means that both of you will want to have a big vote in what the final solution will be.

This makes you both dependent of eachother, and to reach a comfortable conclusion you will have to cooperate effectively. If you can't reach an agreement, mostly the frontender will bite the dust, since the backender is almost always ultimately responsible.

My approach to these kind of situations is trying to think of a few possible solutions that all make sense to you, and then making the backender choose. This way you give him the feeling of being in charge, but you are actually censoring the choices you give him. You can introduce the problem to him the way you want to, giving you the advantage. When he will be implementing your code, you'll get a bug report for everything you or he did not foresee, and everything you did foresee, but did not mention to him.

To ease communication between you two, start with the small things. Make sure you are not too far away. Don't hesitate to walk to his desk and talk to him, don't try to solve everything over mail or chat. He's definitely more afraid of you than you are of him. Drink a beer with him on friday at the office! (This will cause some persuasion in most cases, but definitely worth the while!)