Top 10 things I should have known when I started out as a frontend developer

Top 10 things I should have known when I started out as a frontend developer

I have been working in frontend mobile and web applications development for the last 5 years and have learnt a lot of new things in terms of frameworks as well as project management:

Here are 10 things I wish I had known from the beginning of my professional career:

1) No matter how fancy or popular a new framework or library might be, nothing can beat vanilla/simple javascript. Always solve a problem using the best possible and efficient approach and not simply by following a new framework or libraries because they go out of date quite often or npm modules undergo breaking changes most of the times. It is better to keep modules up to date and code maintainable from time to time rather than trying to fix bugs at last moment.

2)It is always better to release build to QA or production in the middle of the week rather than delaying it till Fridays fixing critical issues at last moment and even spending your weekends sometimes at the office.

3)You need to be up to date about the latest syntax, features and libraries. So following relevant technical publications on medium, glancing through questions on quora, joining relevant technical groups on Facebook and even opening hashnode feed daily or once a week can help you stay relevant on a variety of topics.

4)Never try to multitask unless and until you can do it effectively. It is always better to stay focused on one problem/module at a time rather than trying to do many things simultaneously.

5)Every programmer has some “power hours” in a day where they have maximum focus and can be most productive. Some might be night owls and others might be early risers. Irrespective of the times try to figure out solutions to complex/difficult parts of your projects in this hours and then do menial tasks like attending meetings, interacting with team members and other trivial programming tasks later.

6)Always follow standard commenting guidelines and programming styles in order to help others understand your code faster during code reviews. If your work on multiple projects simultaneously, a few months down the line you might not even be able to recognize your own code and comments can help you immensely in those situations.

7)It is always better to start working on little side projects or even contribute to projects on GitHub right from the beginning. You get to learn a lot of new things from smaller side projects which might help later in large-scale production level projects.

8)Always commit your code at regular intervals, maintain proper git branches and meaningful tags. Approve merge requests to master branch periodically rather than trying to fix a large number of merge conflicts at the end.

9)Don’t accept every damn project that comes your way unless and until you can devote sufficient time to it and don’t agree to deadlines without estimating them properly. It is always safer to keep a buffer time while estimating deadlines since you can never be too sure about the time required for even minor feature additions.

10)Pair programming can help you immensely to develop code and come up with solutions faster. Also, your colleague can help in reviewing your code in real-time. But make sure that you pair up with someone who at least matches your wavelength or expertise level. Also, keep up your ego issues aside and be open to accepting reviews/criticisms from your colleague.

That's it for today's article. You can connect with me on Twitter or LinkedIn

Did you find this article valuable?

Support saurabhnative by becoming a sponsor. Any amount is appreciated!