Return

Building code from a Front-end point of view

Floor van Wieringen

4 min read

Our teammember Floor gladly takes you along through her day of working as a Front-end developer

A work day as a Front-end developer is diverse and challenging. At the end of the day I always close my laptop with a feeling of satisfaction. This is partly because, as a Front-end developer, you end the day with a visible result. It’s very satisfying to see an application emerge under your fingers. In addition, the work is very result-oriented. There is a concrete assignment that you’ll bring to a good result step by step. What does a workday like this look like?

Morning

In the morning, I start with a new flow. We are working on a portal that enables dialogue between suppliers of a store and the head office of this store. Among other things, the portal enables the negotiation of price agreements. The flow I’m about to work on is intended to make it possible for users to add other users to the application so they can create an account. I will start with the visual aspect, the user interface. The basis for this are the designs of our designer.

Depending on the size of the application we work in teams of up to about 5 people. These teams include the designer, at least one back-end developer and at least one front-end developer.

When the user interface is ready, it’s time to fetch the data with the API that my colleague from the back end has already made.

In between, a meeting with the customer is scheduled. The contact with the customer usually gives new energy because the customer is often enthusiastic about certain things but also comes up with points of improvement or elements that need to be added. The latter is actually just as fun as the former because it means that there are new challenges waiting for us.

During the conversation with the customer it emerged that an additional component should be added to the portal. The portal has different types of users and the differences between these users are determined by the rights that each user has. The client would like to have insight into these rights. This requires a modal with an overview of the roles per user. There is no design for this yet so I seize the opportunity to think up how this piece will look. When the user interface is ready, I discuss with the designer whether he agrees.

Now comes the piece of logic. This is again a very different way of thinking. While with the first part the user is always in the back of your mind, now the challenge is mainly to figure out how to shape the data from the backend so it can be used for the modal in the front end. This means logical thinking and puzzling. Then the work is ready for peer review. A colleague will check if everything works as it should and if the code is written in a logical way.

Afternoon

In the morning, a message came in from another customer. A user of the application we made for this customer has indicated that a piece of the application does not seem to work as it should. I dive into the code and test the flow to find the problem. During the detection, you get closer and closer, step by step, to the piece of code in which the problem is located. Once the problem has been tracked down, I devise a solution. Another satisfied customer :).

Sometimes when tracing these kinds of problems it can seem like you’ve come to a dead end. When something seems too much of a challenge, it is very satisfying to find that things often work out by breaking them down into smaller steps. And if you really can’t work it out, you can always ask a colleague for help. The great thing about Levarne is that we are a team and together we do everything to delight the customer.

Because we offer SAAS (software as a service) at Levarne you as a developer really have the chance to make the application better and better. Because of the continuous dialogue with the customer you, as a developer, can deliver customized products that fully meet the needs of the customer and the user.