Hello, Habr! We present to your attention a translation of an article by MediaMonks front-end developer Ronald Mendes. Originally from Venezuela, Ronald moved to Argentina and built a successful career, and thanks to his strong interest in design and animation, he became one of the jury members of the prestigious FWA award (awarded since 2000).

In this interesting post, Ronald discusses how a frontendor can find his place in the sun and interact more effectively with his team.

Ronald Mendes. About the role of a front-end developer

When I started working as a developer in 2009, I spent most of my time building websites. My tasks related to the final stage of a linear process in which designers, clients and other stakeholders made almost all decisions.


Wherever I worked (in an agency or as a freelancer), developers were never involved in interaction with clients, except when it was necessary to answer some technical questions. Most often I was asked about the implementation of simple functionality, for example, how to make a slider or adapt an image downloaded from a CMS.

In the years that followed, as front-end development became more difficult and more and more new skills emerged, this attitude towards front-end developers became more and more frustrating.

Many organizations, including those where I worked, followed the waterfall development model: we had no idea what was going on until the project was ready to be programmed directly. Everything fell on us at the last minute, and we didn't even have time to insert our five cents.

Despite the fact that our team members often appreciated us, we still did not have the opportunity to contribute to projects at the very beginning of the process. Every time we shared an idea or noticed a problem, it was too late.

We front-end developers have come a long way in the last ten years. After so many years of hard work to become top-tier professionals and have more impact on projects, many programmers are now getting more moral satisfaction from their contributions to the product.

But we still have a lot to strive for: unfortunately, the work of some front-end developers with amazing skills still boils down to coding from PSD layouts to HTML. Others are getting tired of their position in the team, but they would like to play a more active role and promote their ideas in the development of the project.

While I am proud to be among the programmers who have influence on the project, I continue to fight for our place in the sun. I hope, after reading about my experience, you will want to join my movement.

My path

My role in the team began to change when I saw an inspiring talk by Seth Godin that helped me a little realize that I have the strength to change, which will allow me to receive greater moral satisfaction from work. Godin suggests demanding to be more proactive, whether you're working for a boss or a client - that advice gave me the boost I needed.

I did not expect a big leap - it was enough for me to feel that I was going in the right direction.

Small steps in a small team

One day I got the perfect chance to test the waters. I just collaborated with a small design studio, and the team consisted of five people. Since I never hid that I liked the design, it was easy to convince them that if I was more involved in the design processes, I could provide technical feedback before the layouts were presented to clients.

The results were amazing and had a positive impact on the entire team. They began to transfer design materials to me in order to get my approval for the technical part. For their part, the designers were happy to note that the sites that we launched after general agreement more closely matched the layouts.

My next step was to participate in every project from the first day. I started going to the first meetings with clients, even before any contracts were signed. I called the team's attention to things that could turn the development phase into a real nightmare. At the same time, I suggested trying new technologies that I was studying at that time.

After a few months, I felt that my efforts had finally influenced the team's projects. I was happy with my role in the team, but I knew that this would not last forever. Eventually, it was time to embark on a journey that would take me back to my classic front-end developer role, which is the bottom of the waterfall.

Entering the big stage

When my career began to develop rapidly, I found myself far from that small office for five people, where it all began. Now I was working with a much larger team and the problems were completely different. At first I was very surprised by the way they approach the workflow: all team members had a strong technical background, unlike other teams I have ever worked with. This made the collaboration very effective. I had no complaints about the quality of the design I worked with. In fact, during the first few months, I was constantly pushed out of my comfort zone and constantly tested my skills.

But after I got used to my responsibilities and started to feel more comfortable, a new challenge arose before me: to help establish a closer connection between the design and development teams. Despite the fact that we regularly worked together on high-quality developments, these teams did not always speak the same language. Luckily, the company was already working hard to improve communication between designers and developers, so I had all the support I needed.

As a development team, we switched to modern JavaScript libraries. This led to the fact that when working with our applications, we used an exclusively component-based approach. And while we slowly changed our mindset, we didn't change the way we collaborate with the creative half of our team. To create this connection between teams became my new goal.

I was in awe of Brad Frost's Death to Waterfall Concept : idea is that UX, visual design and development teams should work in parallel: this will lead to a higher level of iteration during the project.

All my team members began to take on more responsibilities and share their thoughts on each project as they were encouraged to work together. Developers started participating in projects during the design phase, noting any technical issues they could foresee. Designers provided input and advice during the development phase. When the process started, we immediately saw positive results and excellent work done.

While this transition may seem like a smooth transition, it actually took a lot of hard work and dedication from all team members. We all wanted to not only improve the quality of our work, but also to make a big leap beyond our comfort zones and old work processes.

How to conquer a place in the sun

In my experience, making real progress required a combination of two things: honing your skills as a front-end developer and motivating the team to improve their workflow.

See below for more details on what worked for me and might also work for you.

Changes in the developer's life

While the actual change in your team role may depend on the organization where you work, sometimes your individual actions can help trigger the change process:

  • Don't be silent . In multidisciplinary teams, developers are known for being highly analytical, critical, and logical, but not sociable. I've seen many developers quietly complain and claim that they have better ideas on what and how to do, but they hide their thoughts and move on to another job.After I started to voice my thoughts and come up with new ideas, I saw small changes in my team, and my motivation increased dramatically. Moreover, I have noticed that others are beginning to see my role in the team differently.
  • Always be aware of what other team members have ideas . One of the most common mistakes we make is to focus only on our work. To be on the same page with our team and improve our role, we must understand the goals of the company, the skills of our team members, our clients, and any other aspect of the area where we work, and on which, as we used to think, the developer should not spend time. Once I began to better understand the design process, communication with my team began to improve. The same is true for designers who have begun to learn more about front-end development processes.
  • Upgrade key skills . Today, our responsibilities are expanding, and we are constantly challenged to lead our team forward to as yet unknown technologies. As front-end developers, we are often tasked with researching technologies like WebGL or VR and introducing them to the rest of the team. We need to keep abreast of the latest advances in our technical fields. Our reputation is at stake every time our input is required, which is why we should always strive to be the best developers in our industry.

Changes in the company's workflow

To maximize your potential as a developer, you will need to convince your company to make key changes. This can be difficult to achieve as it usually requires getting everyone on the team out of their comfort zones.

In my case, it was long negotiations with my colleagues, including designers, management and developers, that worked. It's hard for a manager to turn you down when you come up with an idea to improve the quality of your work and only ask for small changes. Once the rest of the team supports these changes, you will have to work hard and start rolling out these changes to keep things going:

  • Engage developers in projects from the start . Many companies have high standards when it comes to hiring developers, but they don't take full advantage of their talent. Most of us think logically, which is why it is so useful involve developers in many aspects of the projects we are working on. I often had to take the first step to get informed at the very beginning of the project. But as soon as I started making efforts to make a valuable contribution to the process, the team began to automatically involve myself and other developers in the design phase of new projects.
  • Schedule a project discussion . Problems often arise when, during the first project discussions with the client, not the entire team that will work on the project is present. Once a client signs something, introducing new ideas can be risky, no matter how valuable and useful they are. Developers, designers and other key people should get together to discuss the project together and then move on to the next stage. As a developer, you may sometimes need to spend some of your time helping your teammates review their work before they submit it.
  • Get people to work together . If possible, gather people in one room. We prefer to rely on technology and insist on communicating only through chat and email, but face-to-face communication has its advantages. It's always a good idea to have different team members sit together, or at least close enough to each other to communicate with each other on a regular basis in person, making it easier to share ideas throughout the project. If your team is working remotely, you will have to look for alternatives to achieve the same effect. Periodic calls can help teams share thoughts, comments, and interact with each other in real time.
  • Take time for education . Of all the teams I have worked with, the teams that foster a culture of knowledge sharing tend to perform better.Simple and casual presentations from colleagues from different backgrounds can make a huge difference in building a variety of skills in a team. Therefore, it is important to encourage team members to teach and learn from each other.

    When we made the decision to use only component-based architecture, we prepared a simple presentation for the design team that gave them an idea of ​​how we would all benefit from changes to our workflow. Shortly thereafter, the team began providing design layouts that followed our new approach.

It's fair to say that a modern developer can't just hide behind a keyboard and count on the rest of the team to make all the important decisions about their workflow. Our role requires us to go beyond the code, share our ideas, and fight hard to improve the processes in which we participate.

As a postscript

Thanks for reading the material. At the end, we would like to add a few words of our own.

We know very well that often even a talented developer experiences a problem due to the lack of a bright portfolio. Not all of us have the perseverance to create notable pet projects, and completing freelance jobs are not an experience that would normally impress a potential employer. One of the solutions is thematic contests.

As a small impudent advertisement (may Ronald forgive us): one of these contests has just started with us. If you are familiar with React or see the strength to try yourself in writing components for React, we invite you to take part here .

Acceptance of works will last until August 28.