Over the years I’ve been contracting I have worked with dozens of back-end developers from all over the World. This post is about how to know you have a great one and how to work with the good and bad…
Interview and Your First Day
At the interview you want a dev present. You want them asking you questions about how you work and you also need to ask them how they work.
On one of my first interviews I didn’t have a Dev in the room and I didn’t ask for one so nothing about the CMS (Content Management System) were discussed. On my first day on the job I was told the CMS they use didn’t allow floats or positions because each block could be dragged and dropped to any other block on the page. I was told I had to make it work within two weeks or they would lose a Million pounds a day.
The project managers giving the interview didn’t know anything about the limitations I was about to face. With a dev present I would have discovered them by asking questions.
What to look for
On your first day if no-one comes to you, go to them. Be SURE that there is a way for you to do your job. A few Developers think the styling just magically works and they don’t need to give the designer any input. It isn’t up to the Dev to guess what you need, you have to be able to approach them and clearly explain it.
The worst developers
Some developers are only interested in doing their piece and they are not that interested in the process of making their work look pretty. They think that having their piece of code wrapped in a <div> is enough for me to work with. Asking for a class to be added to an element annoys them because they love clean, uncluttered code and think classes and ID’s spoil their code.
These are rare but you will need to use the tips at the bottom of the page to help explain and visualise the issue.
The best developers
The best ones ask questions, they want to know how I’m going to achieve the styling. The very best dev I ever worked with was a junior dev called Gareth. He was constantly asking me questions about how I can achieve the desired result and what he needed to do for me to achieve it. He didn’t want to know how to style, he wanted to learn how he can work with front-end designers. These people are worth their weight in gold!
The average developer
Most Developers are very happy to engage if you approach them. If you need something added they will happily do so. What you need to do as a front-end dev is explain what you need and why you need them to modify the code.
How YOU need to work
A change request by you is acceptable, repeated sudden and urgent change requests are not. Plan what you need to do. If there are several changes you need to make, meet with the lead dev and possibly the other Devs to discuss it.
I worked in Agile environments on every contract so the morning stand-ups were my time to discuss my issues in front of all the Devs. If you are working in an Agile environment listen very, very carefully during the pre-planning meetings because they WILL affect you! Be prepared to give your input about what you’ll need from them for that part of the project.
Tips and Advice
When asking for changes use K.I.S.S (Keep It Simple Stupid). They don’t need to know that by giving X a float and Y a position it will achieve Z. All the need to know is for you to achieve Z could they add A, B or C.
They really help if you can visually show what the problem looks like now and what the solution looks like with a single change by them. Browser developer tools like the one on Chrome allow you to style on the fly so it’s a quick and easy way to show the before and after to help visualise why you need the change.
If at all possible have more than one solution and ask them which solution would work better for them. If you, as a front-end dev, can show flexibility, it will go a long way to earning you the respect of the Developers.
The single most important lesson!
A change in the back-end code can be much like throwing a pebble in a pond. The change can ripple through the code base and start affecting other parts.
Back-end Developers are cautious and rightly so. Their job is to get the functionality stable. Your job is to find ways of not creating ripples in their code. You do that well and you will gain a lot of respect!