Starting a relationship with your backender
Published
⚠️ Wait up! The article you're viewing was published a long time ago (in internet years), it may be irrelevant or completely incorrect by now. Thread carefully!
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.
But!
You will have to infiltrate the domain of your backender. They will not allow you access to their 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, but they did already write some HTML for it. 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 have a big stake 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, the user experience will be hurt.
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 them the feeling of being in charge, but you are actually censoring the choices you give them. You can introduce the problem to them any way you want to, giving you the advantage. When they will be implementing your code, you'll get a bug report for everything you or they did not foresee, and everything you did foresee, but did not mention to them.
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 their desk and talk to them, don't try to solve everything over mail or chat. They are definitely more afraid of you than you are of them. Drink a beer with them on friday at the office! (This will cause some persuasion in most cases, but definitely worth the while!)