Top 5 Common Mistakes On Your Frontend Career Start
When I started my career as a markup developer 10 years ago there weren’t any courses, mentoring institutes, conferences or videos on YouTube. We had to deal with every bug by ourselves which included long nights of experimenting with the console to fix IE. There weren’t any debug tools and IE6 was the main browser. Can you imagine that? I remember when the firebug console appeared in the first Firefox version. We bought a bottle of wine and celebrated all night long. Nowadays people have all of the good stuff for a quick start in their career as a QA/FE/BE/PM. However, on the way to the dream city you’ll notice there are a lot of hidden treats under the hood.
Let’s find out what the most common cases look like that can knock you off the path to being a Frontend developer.
1. The Basics
Based on my personal experience you will gain more profit if you invest your time into the basics. Everything is constantly changing, frameworks come out with new documentations every 2–3 years, leaving a lot of reading in between updates. Do browsers change quickly? Thank God — no. Issues, protocols, and architectures has been pretty much the same in the last 5 years.
Take a look at the Frontend roadmap https://github.com/kamranahmedse/developer-roadmap, it’s perfect :)
Here is a shortlist that will help you get a good start in your career:
- If you write HTML then you must know tags. You can find a lot of articles on the internet about Doctype but I prefer the original source https://www.w3.org/TR/2014/REC-html5-20141028/
- For every page, styles are necessary so CSS is truly important https://www.w3schools.com/css/
- Also, you can find some basic about the web in general https://internetingishard.com/html-and-css/basic-web-pages/
- Not one project could be developed without a version of control. The most popular now is https://githowto.com/
- JavaScript https://javascript.info/ I like that site, there are a lot of example with explanations
- Of course https://stackoverflow.com/, here you can find answers to any question but be careful, almost 90% is not good if you’re looking for a quick “copy-paste” solution for your code.
- Almost 60–80% of webpages is images, so you have to deal with image optimization and formats. There is no perfect site that I can recommend as there are dozens of them, but you have to know web formats JPG, SVG, PNG, WebP as well as which cases you need to use one of them.
- Nowadays everything needs to automatize, so there is a 99% risks that you will use gulp/webpack in your project. You can easily build your own build https://gulpjs.com/docs/en/getting-started/quick-start or use one of the most popular. For example, https://github.com/justcoded/web-starter-kit
- CSS with superpowers hehe :) https://sass-lang.com/ Just try it and you will never have to use CSS again. Guidelines from Hugo https://sass-lang.com/ also helps you build a flexible architecture for projects.
I can continue this list with hundreds of links, but it is not the main task for today. Just try to ask yourself how everything works under the hood and you will open the magic world of the WEB ;)
2. In a Nutshell
Let’s take a look at simple contact form:
Which fonts are used in the design? What about indents? Where are the rollovers or focus states? These are the most common questions that we ask when we see forms similar to the one above. Lets dive deep into it and review a few uncommon questions:
- Where should the data should be stored?
- Is the data sensitive?
- What will the response be from the server? We have to keep in mind that validation on the frontend could be easily removed by turning off JavaScript on the page. So, validation should always be on the server too.
- What should be shown after the form is submitted?
As you can see there are a lot of questions that come to mind even for a simple contact form. Always be conscientious and better understand business needs.
3. Estimate Your Work
Always estimate your work. You can try a simple approach that always works for me. Before you start any of the tasks create a simple google sheet with at least two columns: Realistic and Pessimistic. You should separate each of the pages or modules into small components and estimate them http://prntscr.com/od6lsu. Realistic is the time that you’re expected to finish if all goes well, while the Pessimistic column estimates how long it would take to finish everything plus risks.
This simple pattern helps you to see your real velocity and deviation coefficient from your estimate. Also, it can show you the bottleneck of your development process.
4. The Project Starts Not From the Code
It’s true. Based on my personal experience, you’re very lucky if at least 60% of the project time is spent on the development. Meetings, project setup, architecture are not just “PM words”. It is a nightmare for every PM and developer to find out that a component doesn’t work at the end of the project and you have to re-write all of your code. These small steps will help you not fuck it up:
- Know your customer. What is the main purpose of the website/application/form etc. What is the customer’s business? Remember that all IT products solve business needs, and I’ve yet yo meet someone who wanted to develop something without a purpose.
- Questions are everything. Take a look at the design, read all the documents carefully and prepare questions.
- Develop a roadmap for your project. You have to have a project plan that describes what has to be done and how long it will take.
What is expected from the client? You should have a clear idea of their expectations. Acceptance criteria are really important. You do not have to write long scroll documents. Just a couple of lines would be enough.
Do not forget about the Pareto Principle! :)
5. Start Small
People always want to try something new and much bigger than what they’ve got. Frameworks and libraries can give you this fake feeling that building an application is no big deal. All you need to do is copy the code and paste it into your editor, right? Wrong. In some cases, this is the last resort approach but on a daily basis, it doesn’t work that way and you will have tons of code that no one can support.
There are some easy tricks that help you build a space rocket:
- Always separate modules into small components. Each of the components should do some easy part of work. There are a lot of patterns even in CSS. For example, you can use BEM methodology or some JS Patterns.
- The Component should be finished. Don’t take it all in a row. Select components and finish it completely. For example, navigation. It could be a really big component with a lot of drop-downs or additional items. Anyway, try to finish it in one day with responsive, scripts and PX-Perfect.
- Test your code every day. Open your webpage, resize, check the console. There are dozens of checklists for every type of project. You can use your own. Even when using a modern framework a broken button can easily fail on your demo.
- Performance. People want to see results as quickly as possible. Google decreases page rank for slow pages. Your page should be loaded in 2–3 secs. You can use tons of approaches for page speed optimization (lazy loading, responsive images approach, etc.). Performance starts from the optimization of each of the components :)
Make it simple. If jQuery is enough for your project then use it. Businesses don’t normally care what technology has been used in the solution, so if it works and it’s easy to support than use it.
Of course, there will be a lot of walls you’ll need to break on the way, however, what’s most important is that you like what you’re doing. You will be always surrounded by other people who can help you on your way.