[Editor’s Note: This post is a part of a new series on this blog, called Jixee Hotfix. It will feature real problems that our engineering team encounter on a weekly basis and the solutions they come up with to fix it. Posts are written by the engineers encountering the problems. This post was written by our Sr. Engineer, John Sykes.]
To the layman, front-end developers and back-end developers are all the same. They “code things” that eventually become a tangible product. But there is a lot of work that goes into building a product, from idea to release. An important part of this process is making sure the back-end and the front-end function well together, which isn’t always an easy task. Some developers specialize in front-end only, while others prefer the back-end. A few do both. But the difference between the two is how you think about a product. One is about structure with black and white functionality, the other is about how people use the product.
We have been refining the Jixee product for the past few weeks, which has resulted in changes to both the front-end user experience and the back-end code. From time-to-time, this has lead to end-user issues during our Q&A phase.
Working on the back-end generally means that you write server code, which is what I typically work on. You are behind the scenes, writing services and API’s that others interface with. In other words, you are creating the building blocks of the product. A house is built out of metal and wood frames, often not see by the end occupant. This is the back-end.
Creating back-end infrastructure often means creating a large-scale interface for the world. High amounts of traffic and user requests will be interacting with this API, so one of the most important things to keep in mind is product stability. Do the nuts and bolts of your product work? If you want to test out your stability, one method to do so is to be able to generate a crash of your system. Understanding a crash can help you determine methods for preventing it in the future.
In contrast, front-end engineering has some different dynamics at play. For starters, I feel that the repercussions of a front-end bug are less than that of an API error. If you have a front-end error, it usually means a button doesn’t work, is misdirected, or your product flow isn’t smooth. But when pushing up a fix to API, there can be a brief interrupt, which results in a restart, that will affect anyone making requests from a basic setup. Essentially the product won’t work at all. If the error on API spreads to a database storage problem, no amount of restarts can (normally) remedy this kind of issue.
I find that when developing front-end UX, you can feel like the client to the back-end engineers since much of your data handling has to go through a server. This is where project management can help keep things smooth and tasks delegated. Keeping new features on different branches can help keep the main version clean of “work in progress” defects which can become a scaling issue when the team size increases. But even the most polished tools and procedures will have an occasional gap.
Miscommunication with back-end engineers or vice-versa can lead to misunderstandings or a delay in needed changes. That’s why it’s important to have a task tracker and reliable product manager on your team. It’s also why it is important to keep modular code and side tasks that you can do in the meantime. Sometimes when writing back-end functionality, you forget the end-user experience. Therefore, it’s possible that you run into inconsistencies with the user experience.
For example, we were changing search functionality within Jixee (I’ll have a blog post about that next week) and when it came to clicking an attachment in the search results, the command was to automatically download the file. But this was a different experience when you click an attachment in a specific task. Clicking the file in a task automatically opens a new browser tab with the file. These experiences should be the same. In a nutshell, our attachment issue illustrates the difference between the front-end and back-end engineer mentalities.
It is beneficial to become familiar with the differences between front and back end engineering. You don’t necessarily have to be an expert at both, but understanding both will help you do your job more effectively.
If your team needs help with communication to eliminate as many miscommunication snafus as possible, try a 14-day free trial of Jixee.