It might sound strange for you to hear it but it doesn't matter how good you are as a developer as far as technical skills are concerned.

I have worked with many developers in my time, some really good at their craft :computer:.

Some of them have been delivering very poor results due to overcomplicating things and then spending too much time building their over-engineered solution.

A few don't even care about productivity at all - they might spend countless hours only to deliver incredibly beautiful code... that is never shipped, because of various reasons.

So let's check a few things we all can do to avoid those pitfalls.

Understand what you need to build :hammer:

Try to get as much information as possible from stakeholders, it's very important to get out of them key aspects like:

  • getting you through all the requirements of the system (as incomplete as they might be at this point)
  • define non-functional requirements together with them (think web application load time, supported browsers, dealing with cached data, etc.)
  • time :snail: - what do they expect as when this project will be ready? try to see if they have realistic expectations

PM waiting img

Be efficient in your work if you have external dependencies

When I have a FE feature to develop, the first thing after I understand what I need to do is, If the feature has BE dependency:

Step 1 - write a WIKI doc with an API specification :pencil2:

After writing this, have the BE developers review it.

You want to know ASAP what data models will be used so you don't waste precious time having one FE model and then the BE team building an API with a different model.

If you do end up with two models... it wastes so much time as there will be discussions later about what model to use. Also you or the BE dev will have to refactor to the decided model.

In the API specification I also write:

  • the exact route, params and request type
  • status codes the API can return in various situations
  • request and response payloads

Now this gives the BE team a boost as well because they have an exact API specification and they just have to implement it.

Step 2 - Create a mock API

Having good Mock APIs is pure power. :muscle:

Because you have an API spec, you know all the edge cases of working with that API. You can configure the Mock API to support each edge case and test your components in all scenarios.

FE - Mock API pic

To give an example - you need to show a users list - you can set the Mock Api for the following cases:

  • displaying the data correctly when you have data
  • displaying correctly when you don't have data
  • handling the loading state when the API response is fast or slow
  • handling the case where the API returns a 4xx status code
  • handling the case where the API returns a 5xx status code

Done! 💥 At this time the feature is done. If both FE and BE team used this technique, the feature just works. We can simply switch the FE to use the real API.

Now take this in contrast with the bad way of doing this. It goes like this:

The FE and BE developers work on a feature without talking at all about it - and not designing their interface layer (remember the API specification). When the BE developer is done the FE developer investigates for a day or two how the API works - he suggests further modifications to the API because it doesn't behave ok in some situations or is missing some data fields. The BE deveper fixes this, pushes his new code, the FE dev tests again, and can finally integate the API. When the feature is finally ready for testing bugs related to data model mismatches could still be found. 🤦‍♂️

Why this technique works so well :sparkles:

As a FE developer you don't even need to spin up the backend, you just designed the API schema and mocked it. Having a MOCK API saved you a ton of time.

Put this in contrast with the scenario where you spend countless hours debugging why the backend doesn't work on your local, and also doing cleanups and data reseeds, or stoping and restarting slow containers or processes every time you try to develop something... that's just yucky.

Wrapping things up

So to sum it all up - the things that will boost your productivity as a FE developer are the following:

  • Understand what you need to build
  • Correctly manage expectations
  • Handle external dependencies & reduce unknowns
  • Use a Mock API

If you like this post follow me on Twitter where I post more cool stuff about React and other awesome technologies. :fire::fire::fire:

This post is also available on DEV.