A bit about Front-end engineers, what the job looks like, what's your responsibilities, skills and also some facts, some challenges that you have to face when being a Front-end engineer.

Hi, this is Văn Linh from the Seller Center team, Teko Vietnam.

It's very hard for Front-end engineers to satisfy the customers

Is it worth being a Front-end engineer?

Some of you must have thought that Front-end is just a simple job which is easy to achieve, the work just revolves around doing the UI for an application. For example: you only have to cut the HTML, use CSS for styling some buttons, images... of the page, and include some JavaScript codes for the functionality. That's all, sounds easy? 😎

Let me tell you a story, it might upset you but it's a truth, a true story which happened at a company in Vietnam. I will call it company X - of course this company is not Teko 😁

There's a man, he led a Back-end team in company X. There's a member in his team who made mistakes frequently and made him very unhappy. One day, he couldn't take it anymore and told that member: "If you make mistakes more and more, contact HR to see if the Front-end team has slots and join it instead". Of course, we all thought it was a joke from that guy. However, he repeated his bad thought about Front-end many times, even he organized games for his team and told other members: "Who win can code Back-end, who lose will have to code Front-end instead". The CTO of company X always troll him by telling him: "Can you code CSS?" 🙂

So, is Front-end job really as cheap as the TL from company X thinks? Is it worth being a Front-end engineer? 🤔

Myths and Facts

I will go through a few examples about something that you might think it's good but it's really not, also the facts that Front-end engineers have to face, and how are these things being applied in Teko. You will know what is the real job of a Front-end engineer. It's not as simple as you think, but it's not too complicated 😉

Front-end is not a job which you have to do in a stereotypical way, but you should work in a flexible way instead. To be a strong Front-end engineer, you will need not only to own the Front-end skills, but also to show your creativity, thinking, responsibility and even art in work.

Myth #1: It's good to design features with complex logic

Situation: Your boss defines 10 features for a screen with complex logic. He defines the requirement very clearly with a very high confidence and gives it to you 😎 Your job is to develop a screen that can meet most requirements.

Fact: After you deploy this screen on production for a while, you, your team and your boss realize that end-users only use 1 out of 10 features that's been well-defined 😞 LOL, why?

Users never use things they don't like even you build a lot

You must remember a very important principle when designing/developing Front-end features: what users think is not really what you think. You can build a very big feature that contains complex logic and you are very clear with the logic of this feature. However, users might not know how to use it, or the UX is really bad that makes them very confused, they feel that they receive zero-value when using your feature. That's why they get rid of using your feature, and they will give a lot of feedback for you/your team with an uncomfortable mood.

💡 Lessons learned

  • Think about MVP (Minimum Viable Product) first. Build as simple as possible with enough features to serve customers quickly 👍
  • Remember Pareto Principle which states that 20% of efforts bring 80% of results, and the other 80% of efforts bring only 20% of results.
Pareto Principle
  • Tracking is very important ⭐ Everything you did should have a logging/tracking system. This will help you to trace error logs to optimize app performance, trace user behaviour to optimize app's UI/UX, functionality and more.

🚀 How do we apply these lessons in Teko?

  • A lot of features have been done in MVP version to onboard quickly.
  • When brainstorming a feature, we cut off a lot of useless functions that can bring zero-value to customers.
  • Using tracker-js to trace all user behaviour and API-integration error logs to optimize app performance and UI/UX.
  • Using Google Analytics, Facebook pixel for tracking ecommerce events, conversion rate, revenue... to optimize SEO, marketing strategies, advertising campaigns... for ecommerce apps.

Myth #2: It's easy to build features to meet the UI/UX design

Situation: Your PO/designer gives you a wireframe for a feature that acts A and he expects that you build this feature to exactly act A.

Fact: You build this feature that acts B which has a different UX behaviour than A, or the feature is not really worked as expected from the PO 💔

Build a thing that doesn't match the design

This is very normal and usually happens in many projects. There are many reasons why this case happens such as missing requirements, the wireframe is not clear and does not cover all cases, the Front-end developers build the feature according to their own understanding without raising any problems...

The drafted wireframe from PO/designer is only their overall thinking of a screen/feature. Of course, they cannot figure out all the cases (especially the corner cases) for you at the beginning, because they're not the person who implements the feature, but you are. When you build the feature, you will directly experience the user behaviour and find out there will be a lot of questions that need to be answered. That's why I say "Front-end engineers should work in a flexible way".

💡 Lessons learned

  • Do not hesitate to ask as many questions as possible when receiving a wireframe. It will take your time at the beginning, but it will save much more time/effort later on, trust me 😉
  • The requirements can be unexpectedly changed at any time, and you will need to face this instead of running away.
  • As an engineer, you will have the right to raise any problems that you find unreasonable, or reject any nonsense requirements from the PO. If you can, show your UI/UX design skill and modify the wireframe or requirement to make the feature better that can bring a good user experience and more business value. So please be proactive !!! ⭐

🚀 How do we apply these lessons in Teko?

  • Increasing time for the design phase to clear all problems about UI/UX design, business, API documentation... to make sure the coding phase is clear and not to be reworked too much.
  • Front-end engineers are more proactive on raising problem when receiving a wireframe or an API documentation.

Myth #3: It's easy to build shareable components for team

Situation: You build a shared component for everyone in your team to reuse in some screens and you expect that everyone will use your component 😍

Fact: No one uses your component 😢 they build the component in their own way and duplicate this component in many variations.

Each member builds a thing in their own way and it causes confusing

There is one thing you will obviously know and I don't need to tell you: the code will be very messy and hard-maintained in this case.

For example: you build a component Price to format price currency. However, member A builds another component PriceLabel to format currency too, with a little difference in logic. In addition, member B also builds another component PriceInfo to format currency with other logic... When a new member joins the team, he will see at least 3 components that do the same functionality and a big question comes to his mind: "Which one should I use now?"

If the team scales more and more, it will be much more difficult to manage the code. Therefore, code management, responsibility, commitment and the initiative at work are very important.

💡 Lessons learned

  • Document your components clearly. You might want to use the UI component explorer for better management (eg: Storybook, Styleguidist...), everyone will use it as the component documentation of the team.
  • The TL should backup code for the team, ensure the code quality and the review-code process to make sure the code is clean and clear.
  • Everyone should have the responsibility when building/contributing to any shared components, and follow the coding convention of the team.

🚀 How do we apply these lessons in Teko?

  • The consumer-app project: monorepo teko-web which defines shared components to reuse across many sites.
  • The staff - back office project: monorepo staff-interface which defines a shared design system, layout and sidebar menu for a large system that includes many modules such as product, price & promotion, page builder, purchasing, warehouse, logistic...
  • Storybook for the shared components used in consumer-app, staff - back office, design system (eg: https://design.teko.vn)...

Conclusion

The above Myths & Facts are just a few practical examples. There will be many other situations that you will meet when you work as a Front-end engineer. Being a Front-end engineer, you will learn how to satisfy the customers who directly use your products, although it's very very hard to do. You will make mistakes, sometimes you will feel bored with your work, but the more you fail and recover and improve, the more mature you become.

Front-end has a lot of things for you to learn, to grow in both technical and soft skills. Therefore, do not hesitate to be a Front-end engineer if you want 😄