The critical situation of frontend development. A bubble that we have to stop
Tags: career, productivity
Published: 2019-05-27 12:24:24

**Sorry if in some occasions my English is not good enough.**

![Bubble wallpaper](https://media.istockphoto.com/photos/colorful-bubble-picture-id852145138?k=6&m=852145138&s=612x612&w=0&h=AonlX6RRpbedrs7JHRYfvWTlB-u7DDgNrA0E0kk_e_U=)

*The goal of this article is to make people of frontend development aware of the high self-demand, exceed of content and the unsustainable rhythm that exists in our community. The urgency to change things and adopt a "me-first" attitude that guarantees personal well-being.*

<hr>


I have been in this profession for almost 4 years and although it is not a long time, it has been enough to realize several things that I dislike and affect and concern us all.

## There is too much content to learn

The first problem that frontend developers💻 have is that there is too much to cover. The increase of responsibility that is being transferred to our role and the frenetic progress of the Javascript ecosystem are the two main reasons.


This is so, that specialization has already emerged within our role named UX Engineer, which is a position that is more focused on design knowledge, user experience and the implementation of these.

What does it mean to be a front end developer in 2019 🤔? [I asked the community](https://twitter.com/victorException/status/1113767944100753408) about what knowledge they believe to be related to frontend development and the following list resulted 📃: 
- Hierarchy of contents.
- Semantic HTML
- SEO
- Schema.
- Accessibility.
- CSS and its billions of functionalities.
- Preprocessors and their millions of functionalities.
- Images and their formats (jpg, png, svg, etc ...).
- Animations.
- Accelerated Mobile Pages (AMP).
- Emails
- Javascript.
- ECMAScript and its new annual functionalities.
- Transpile code with Babel.
- Make bundles with Webpack and Parcel.
- Understand the asynchrony.
- Reactive programming.
- React / Vue / Angular and its new periodic functionalities.
- Redux, Redux-thunks, Redux-sagas for state management.
- API Rest.
- GraphQL.
- Web Sockets.
- WEBRTC.
- Server-side (SSR) and client-side (CSR) rendering
- Billion bookstores for any nonsense.
- Analytics tools such as New Relics, Sentry, etc ...
- SOLID principles applied to micro and macro design.
- Design patterns.
- Testing (unit, integration, acceptance, etc ...) both visual and logical.
- Test-Driven Development (TDD), Domain-Driven Design (DDD).
- Paradigms: Functional programming and object-oriented programming.
- Performance (css, javascript, npm, network, http petitions, etc ...).
- Progressive Web Applications (PWA).
- Node.
- Node Package Manager (NPM).
- Docker.
- Agile methodologies.

And as we can see, we have a problem. With so many things "that we must learn" it is impossible to focus. It is impossible to decide what to learn. It is impossible not to demand too much. **It is impossible not to be scared**.

## A frenetic rhythm in the ecosystem

*How many of you have considered knowing almost everything from the previous list? And how many do you think you should know almost everything?*


While it is true that we are happy with the increase of new functionalities 🆕, tools 🛠️ , and libraries 📚 that enrich the ecosystem, this also means that we must understand, internalize and know how to use to be in this sector.

People who have worked longer in the profession are less affected but, those who have just started and have so much to learn ... They are highly exposed to:
- Stress
- Anxiety.
- Lack of confidence in oneself (impostor syndrome).
- Do not value the learning process.

It's stressful to see every time on Twitter or Linkedin new libraries, new features, new concepts, new methodologies, new names ... This sends a message to our subconscious of **Still do not know it 😱? Get on!** And this is bad in the nose because even if it is very little by little, it affects and influences our happiness and inner peace.

Linkedin and Twitter, among other things, are social networks where people want to show off. Not everyone has read the article they shared. So do not punish yourself for not reading it.

Although you like it or not, slower or quicker, we have to learn all the things that come out mainly for two reasons:
- Own satisfaction
- Opt for a better job


And unlike other sectors, software development is one of the few with a very high percentage of people who their hobby is the profession as well. This means that we:
- Read
- study
- Have one or several personal projects
- Attend meetups
- Look at conferences
- Create content

And this is awesome! But at what price ⚠️?

## We need a sustainable rhythm️

We have reached such a point that we want to learn how to organize the week to be productive in order to have the maximum hours️️ available to dedicate them to grow professionally 🎓.

Do you think you can hold on with this rhythm until the end of your days ☠️? Will you be happy with your life in this way? Don't you think you would have lost many other things 😔?


We are ignoring the aspects that we should also attend:
- Socialize more.
- Discover new experiences such as painting, music, dance or gardening
- Study communication.
- Personal development.
- Meditation.
- Ethics.
- Philosophy.
- Financial intelligence.
- Emotional intelligence.
- Practice physical activity.

These activities provide us with different types of mental arousal. They help us to know each other better, probably to broaden our circle of friendships and, therefore, in addition to helping us to disconnect, they bring us happiness.

These activities provide us with different types of mental excitement 🧠. They help us to know each other better, expand our circle of friendships and, therefore, in addition to helping us to disconnect, they bring us happiness 😄.


We should understand that each one has his life and therefore has different contexts and obligations. That means that some have more time than others for their activities and that is why we should not compare ourselves. Live as we want and not as the current wants to take us 🌊.

## Imposter Syndrome
 
*The impostor syndrome is a psychological phenomenon in which people are unable to internalize their achievements and suffer a persistent fear of being discovered as a fraud.*
 
**The Imposter Syndrome is a big problem** that we have to fight if we want to avoid major psychological problems and precisely, the current landscape of frontend development does not help at all, but quite the opposite 🙎.

The strong rhythm of shared resources in the network creates a strong current that seems to be that we all have to follow because if not, we are out of the picture.


Has it ever happened that you walk on the subway, and you want to walk slower but there are so many people around us walking a lot faster than it's impossible to go at the pace we want? Well with this happens the same.

## Solution: Apply the Pareto Law
*Pareto's law says that 20% of our effort gets 80% of the result.*

The large number of topics to be learned and the little focus we have today are the main problems, but perhaps we are not being practical enough.

If we apply Pareto's law to the list 📃 that we mentioned at the beginning of this article ⬆️, it would be such that:
- Semantic HTML
- Accessibility.
- CSS.
- Preprocessors.
- Javascript.
- ECMAScript and its new annual functionalities.
- Understand the asynchrony.
- A framework (React, Vue, Angular).
- API Rest.
- SOLID principles applied to micro design.
- Design patterns.
- Testing (unit, integration, acceptance, etc ...) both visual and logical.
- Object-oriented programming.
- Performance (image optimization, CSS selectors and access to the DOM and/or variables in Javascript).
- Basic NPM commands.
- Agile methodologies.

As we can see, the list has been reduced a lot 👌. To be honest, there are elements in the list that although they give good bases for the future, should not be of interest to a person who has just started in the sector, because he should have other goals in mind. For this reason, we will reduce the list further:
- Semantic HTML
- CSS.
- Javascript.
- ECMAScript and its new annual functionalities.
- Understand the asynchrony.
- A framework (React, Vue, Angular).
- API Rest.
- Testing (unit, integration, acceptance, etc ...) both visual and logical.
- Basic NPM commands.
- Agile methodologies.

Pareto's Law can't be only applied at a high level as we have just done, but it can also be done for some of the things. For example, in the case of `css`, we have a thousand things to learn. How would we apply the Pareto Law to learn `css`?

From my point of view, the 20% of the knowledge that contributes 80% of the value is:
1. Know the most used selectors.
2. Understand that the browser interprets styles from right to left.
3. Specificity.
4. Flex and Grid.
5. Media queries (mobile-first)
6. BEM

By learning this knowledge, we would have a very good CSS base and we would have achieved them in a practical and fast way.


Only in case you need it, I would learn `@support`, complex animations or transitions because although they are very interesting and useful for many things, I do not think they will be useful to you on a daily basis.


## Solution: Change of mentality
 
Another solution in which I firmly believe to combat this frantic rhythm and the imposter syndrome is a change of mentality both with ourselves and with others.

Something I like from our profession that others doesn't, is the fact we have a we-must-share-knowledge mentality. It doesn't mean though, it can't be improved.

How would you act if John Doe 👦 who works on your team, has to make some animations with `css` and you know about the subject? Sit with him and play a mentor role in this task! Sit down together. Maybe he tells you that it is not necessary because he does not want to bother you, or he does not want you to judge him but insist him a little more. Maybe you get a surprise and the one who learns something is you 😏.


Some things we can do to combat this frantic pace and, in turn, improve the community are:
- Have a personality and know how to differentiate between what we should learn, what they want us to learn and what we would like to learn.
- Share knowledge (Workshops or talks during working hours of knowledge that are needed in brief).
- Be practical and try to apply the Pareto Law to locate what to learn and how to do it.
- Help colleagues without asking.
- Have empathy.
- Don't be surprised when someone does not know something, that does not help.
- Learn the knowledge of software engineering that you can learn in different languages and/or frameworks.
- Constantly learn to apply the compound effect.
- Learn as you need.

<hr>

To finish, I think we should think about what we've read on this post and take action to improve things. 


**Namaste** 🙏