The current state of front-end web development is interesting with a plethora of new concepts that might even change tomorrow: Typescript, GSAT or Three.js animations for landing pages, following design patterns like a bingo card, SEO, data fetching methods, the rise of the client side rendering vs server-side rendering discussions in Reddit threads, and hobbyists and those in the industry advocating for the new shiny JS framework or npm package as the next best thing of the week for production environments.
These are all valid points as technology is continuously innovating, who doesn’t want something better or more fun to use? However, there are also valid pushbacks to these ideas such as accessibility, additional dependencies, mobile responsiveness, performance, testing, unnecessary complexity, or simply the fact that any novel change to an existing system can potentially make the whole thing unmaintainable. After all, not everything new is necessarily better.
This introduction or clash of ideas is present everywhere, especially in teams with a discussion channel, be it in open-source or client projects. It can start with a simple suggestion from a developer such as “I would like to use [xx] in this project through this feature!” to a pending pull request to the main branch due to a lengthy discussion between developers.
As a front-end developer myself, I am not immune to these discussions myself. We all strive to be better at creating great applications. Sometimes, I would like to introduce a new npm package or a new abstraction to the repository as I believe that said suggestions can make my feature reusable and more maintainable by other developers.
However, there are other times that I understand that my changes can introduce issues to the system. I may accept the feedback or I will push back and defend my work. I may also provide the same impression to the work of my fellow developers and they may also do the same reactions. As for the result of these exchanges? It can be painful or fruitful depending on one thing: communication.
com·mu·ni·ca·tion — noun — the imparting or exchanging of information or news.
In the context of front-end development, communication is the process of exchanging thoughts within a team, including but not limited to other front-end developers, back-end developers, designers, and project managers. Communication is the bridge between developers aiming to achieve a mutual understanding from both sides, making development much easier.
This non-technical skill is so crucial in every project with at least two people to the point that the manner of communication present is what either makes or breaks projects. But why is proper communication important in a field where you can just stare at your favorite text editor for more than 4 hours, you may ask? It is because of three points that I would like to raise: idea delivery, conflict resolution, and the proper transition from design to product.
Point #1: Idea Delivery
Proper communication delivers your ideas and requests in a much more understandable format. It directly goes right into your whole point behind an idea without confusing the other party with a word salad. This may be in the form of proposing new design patterns, new tools like state management or data fetching packages, or new ways to send data over to the server.
In a team with dedicated front-end and back-end developers, it is not unusual that front-end developers might request API adjustments from back-end developers to further accommodate their data needs for the user interface. Usually, the request goes as planned, continuing API integration smoothly.
However, there might be times when the other party does not understand your request at all but still tries to adjust to the best of your needs, resulting in misunderstandings, API documentation, rereads and more back and forths:
Proof of FE-BE friendship.
To further emphasize the need for proper communication for request delivery, I would like to provide a not totally real-life example during a past development cycle:
Totally Not Real Life Example #1:
Not-Me: Hello assigned BE (back-end) dev for this feature, please add [important property] for API endpoint #1.
BE Dev: Sure, adjustment done and change has been deployed to the API.
Not-Me: Hello assigned BE (back-end) dev for this feature, I noticed that the change did not affect API endpoint #2. Did you forget to add this?
BE Dev: Oh I didn’t know that API endpoint #2 needs adjustments as well for this feature. Okay, give me some time to deploy the change to the API.
Notice my totally not real-life mistake? I assumed that the back-end dev already knows all about the UI needs of the feature and they can make the adjustments as needed to the other endpoints while adjusting endpoint #1. My mistake was that I wasn’t explicit enough with my request or idea to also include endpoint #2 as well. This resulted in another back-and-forth with the BE developer, further increasing the time needed to finish the integration because of incorrect assumptions. Sorry BE Dev!
Our ideas must be expressed clearly so that there is no room for any assumptions between the parties communicating. Proper communication ensures that everyone is on the same page with the ideas or requests that we are presenting, saving time and potential headaches.
Point #2: Conflict Resolution
Proper communication solves conflicts faster before they get even worse. No one really likes to get into trouble willingly yet different kinds of conflicts are inevitable as development goes along. Complex features, difficult or non-reproducible bugs, stuff miraculously not working in Safari, request change comments in GitHub, and lots more. After all, nothing kills the flow like a sudden roadblock towards finishing your work.
Most of the issues that don’t affect others, such as simple bug fixes or works in progress, are most likely resolved by ourselves. But those that are too much for us to handle alone or that affect another person? This is where proper communication is important to turn a conflict’s nature from destructive to productive.
In this situation, proper communication is all about transparency towards the team. We can ask for assistance from other developers, raise concerns regarding unforeseen issues to our team leads or managers, or ask further questions to our clients, if applicable, for clarification on vague tasks. Communicate to make the team understand that you might have concerns that could affect the team and the project if left unresolved. Having a new set of eyes to look over your issues can give you new perspectives toward solving your problems, boosting you and your team’s productivity. You may also try the rubber duck method to practice explaining your issues.
I think it’s best to have someone assist you at this point… [2]
We should understand that conflicts do not belittle our technical capabilities as developers. Problems may stem from external circumstances but these are also opportunities for us to learn and grow our technical skills and team camaraderie especially if they are communicated well.
Point #3: Design-To-Product
Proper communication greatly helps with transforming a design into a working product. You know the usual development cycle for a front-end feature: Check the proposed design, implement it, communicate with back-end for any necessary changes related to it, integrate API changes if applicable, code review, QA, and repeat it all over again in the next feature. There may be hiccups along the way, as explained in points #1 and #2, but we front-end developers are all too familiar with the realities presented below:
At least it’s based on something terrifying.
For example, given this infamous “simple” dark mode switch to do in 4 hours:
Looks veeeeerrrrrrrrrrrry doable in hours.
Without any context of the development scope, it looks creative and very pleasing to use. Just change the color of the control and the background depending on the setting and you’re done! However, this will make any front-end developer with a tight deadline faint. There are lots of things needed to make this work consistently like advanced CSS styling, animations, and its look in varying screen sizes, browser compatibility, and the list goes on and on. The developer may not also have all the time to reasonably apply this proposed design due to a backlog of features that are functionally more crucial to the whole application.
At this point, it is really important to start a conversation with the designer and to strike a balance between the approved design and the constrained implementation, like removing the clouds and stars to cut down the required development time while still sticking to the intended color style.
Sometimes, there might be a disconnection between the expectations of the designer and the expectations of the developer towards the feature. It just happens and it is not necessarily anyone’s fault because of different conversations between client to designer, designer to developer, or even client to developer. If the approved designs are simple enough to be implemented right away, that’s great! But if the design, which looks simple in hindsight, could be seen to be quite complicated to do for multiple reasons (time constraints, responsiveness, clashes with current architecture, etc.), perhaps it would be best to propose an alternate yet more feasible approach to fulfilling the design.
Properly explaining your side in development prevents complicated designs from turning into bigger problems for the rest of the team, bringing up points #1 and #2.
Let’s avoid being this kind of person. [1]
In the field of software development, particularly in front-end development, communication has always been important in propelling us forward. We are all humans at the end of the day and our constant exchanging of ideas between fellow developers, designers, managers, or clients allows us to improve our processes and our products. As front-end developers, we should not just focus on having the best technical skills but also focus on communicating our thoughts well enough to be a great person to work with.
I believe that a great application is the result of a team understanding each other well enough.
TL;DR: Current front-end tools may come and go but communication is always the constant factor towards great software development.
🔗 Read this in Medium: The Inner Core of Front-end Development: Communication
Author: Rowmel Marco Dabon, Software Developer at Ingenuity Software | LinkedIn
Rowmel Marco Dabon is a front-end developer at Ingenuity Software for more than 2 years. A skilled React and TypeScript developer, he excels in crafting mobile-responsive designs. Continuously expanding his skill set, he explores Python and iOS development. Passionate about problem-solving, he delivers innovative and scalable solutions efficiently to meet client needs.”
Outside of software development, he dives deep into the world of ukulele, tennis, video games, manga, anime, and photography.