Things that frustrate front-end developers

Haniel B Daniel

September 4, 2019

Things that frustrate front-end developers

When things don’t go according to plan, dejection and frustration creeps in and, if these emotions are not kept in check, they could negatively impact the quality of performance of a developer.

Common people often associate lines of code with an emotionless state of mind. But this couldn’t be far from the truth. The person who writes these lines of code is more often than not a human, entitled to their own emotions and thoughts. For any job or process there is an ideal scenario and then there is an actual one. And when things don’t go according to plan, dejection and frustration creeps in and, if these emotions are not kept in check, they could negatively impact the quality of performance of the developer, the code they write and the product as a whole.

Frontend developers occupy a quite unique position in any product development environment. They act like an interface between the visual design team and the backend development team. They are expected to produce flawless working pages of the visual design and at the same time be compatible with the backend. Like any other professional, the frontend developer can get frustrated over several things when it comes to these interactions. Here, I’ve written about some of the challenges of frontend developers when it comes to inputs and expectations from the designers.

Pixel perfect Development

Designers and developers are happy when the designs are implemented without any flaws. One such scenario is that during the review of the developed product, the spacing between the heading and the content in a section could always be 1px closer or apart. Developers get frustrated when they must make these infinitesimal changes to the website repeatedly. There might be a wide array of reasons like rendering differences between the browser and the software that the designers use, the way the same code is interpreted by different browsers and so on. Understanding that the iterations are not about pixel perfect implementation but, a step closer to the visual design can bring down the tension between the teams.

The unending flow of creativity…

Designers love to come up with fresh ideas that keep their creative ideas flowing. As a developer we are asked to make changes unto the final days prior to launch. This leads to a lot of uncertainty and can leave any developer frustrated. As a developer I do feel that the code that we write has a very high possibility of being scrapped any moment because of these never ending changes. Sometimes this also makes us feel unattached and unemotional with the final product code. It is more of a cumbersome task than something that you want to do with ease. A good solution to this would be to fix a point in the project timeline to finalize the design and move ahead with the development. Any further changes should follow a change request process and then implemented at the right time as this will affect the overall product launch schedule.

Loads of detailing and content overload

Based on a research that we at Studio Matrix, conducted in the Indian Geo, an average user spends about 15-25 seconds on a webpage. Pushing the developer to deviate from standards and spend a lot of time to include very fine details into the websites that the user might not end up finding or looking for, can lead to hectic development schedules for the developer. On the other hand, the page has its own performance metrics like load time, response time, page rendering which might be affected because of these minute details. Optimizing this will lead to longer development schedule. Long scrolling pages with lots of elements can be a huge road block to this. The designer should spend some time understanding the performance metrics used by the frontend developers as it will also help them come up with effective page designs and innovative solutions for the minute details.

Understanding Development

A simple change in the position of an element or an animation might include a bit of complicated math. A change in structure or order in different screen sizes might entirely change the structure of code and is not as simple as copying and pasting a text or image asset. This can be avoided by explaining the proper expected output to the developer. A sample animation for the type of animation the developer must produce will certainly be helpful in most cases. Designers can confirm that the developer understands the output expected out of them.

Designing only with visual aesthetics in mind

Particularly in the development of Web Apps, designers sometimes forget considering the actual usage of a section. The width of a section should be designed for the maximum length of content or the actual content that is to be made available in that section.

If the frontend breaks when actual content is brought into the designs, the developer is definitely challenged. This means that he has to adjust the CSS associated with the section for multiple screen sizes. A discussion with the development team regarding the type of and size of dynamic content can help avoid this problem.

The list doesn’t end here, and I probably will stretch it out for another couple of weeks. Most of these can be sorted out by planning and good communication between the team. See you in the upcoming weeks with more content on the same topic 😉