Common mistakes of a Front End Web Developer

Web development is not an easy job because a web developer has to deal with not only currently available Devices (Computers, Tablets, and Phones etc.), OS Platforms (Windows, OSX, IOS, Android etc.), Web Browsers (Google Chrome, Mozilla Firefox, Apple Safari, Internet Explorer etc.) and Technologies (HTML 4/5, CSS 2/3, jQuery etc.) but also all of their future versions/updates and New Evolving Devices. But relax, no jobs are easy, difference is we don’t need to worry about them. After all, “Higher the risk, Higher the gain”. Similarly, “Tougher the job, Higher the Outcome (Income)”.

Therefore, as being a professional Front End Web Designer cum Developer, I’m here trying to evaluate some real field challenges and ways of their proper execution, on the basis of several years of experience in this field. Below are some common mistakes (with their prevention) which, I think, have to be admitted by every (not all) Front End Web Developer are making in their jobs because as they say and I believe “Prevention is better than cure” and in our field ‘Prevention’ saves a whole lot of ‘Curing’ time.

Not observing given design layout carefully
If you are a website layout designer, then you’ll code html and CSS in such way that every element of the HTML layout match with the PSD layout. But what if a developer is not a designer? Unfortunately, this is the common scenario. Most of the developers are not designers so that there is high probability of missing something from the PSD layout whether it’s margins (more or less) or sometimes small icons, slightly different colors etc. So, developers must try to convince the designer by observing every single detail in the PSD layout. If you are not sure about it, show your html layout to the designer in specific interval of time while developing because in design layouts, every margin, fonts and their sizes, boxes, colors, alignments etc. have their own essential in the particular design layout, altering or missing them may result poor visual experience to the viewers.

Leaving petty html or CSS issues to be solved in the future
Don’t ever leave small task or bugs to be completed or solved in future because they are likely to be forgotten and remain undone or unsolved forever. I’m talking about this because most of the developers do the same trying to finish main task first. Every problem/issues have to be solved whenever wherever they found. Most importantly, step forward by 100% finishing every block of the html from left to right and top to bottom of the layout to prevent rework on the same in future which may take longer period because recalling is tough job and prevents timely completion.

Ignoring exact pixel calculations, layout widths, excess or less pixels
This is the common mistake most of the developers are not aware of. Width of every element in a layout must be calculated 100% accurately in relation with the whole website width. Generally, 1 or 2 pixels (excess or less) won’t make any major issues in a website but this is the main reason of browser compatibility issues if we really care about multiple browsers. Believe it or not, you can reduce up to 80% of the browser compatibility issues by honoring the widths and the pixels. Missing even a single pixel width is also not acceptable for professionalism.

Not checking in every browser in every step of coding
Generally, developers go for cross browser compatibility check after finishing some part of website. We have to check in all browsers in addition of every single new html tag and CSS classes/ids, every step of the layout building, even if only a very tiny code added to the page. In coding, problems solving is much harder if we try to solve them later. We don’t know when and where in the code; the browser issues appear. That’s why every step of the coding must be checked in all browsers individually so that we can correct at the same time. This is time consuming at first but saves more time for future.

Unable to identify and control own coded html elements:
Control over every html elements you coded through CSS (Cascading Style Sheet) is very important. One must be able to identify which html tag he is styling, don’t just guess and apply trials using firebug. However, most of the developers are not able to do it. Common, if html codes are all yours, then why don’t u have full control over it. How can you say you’ve coded it, if you can’t control them? Be careful in every step and every new html tag you code. Name the CSS classes in such unique way that you’ll know the purpose of the html tag by the name applied on it. Remember, your own code must not confuse you if you look at the code in future.

Relying on seniors or quality analyst
Think yourself a standalone player in web development game. Relying on seniors or quality analyst won’t improve your quality, instead you’ll be always dependent to them. Work as if there is no one to help you and test your mistakes, bugs in the code. Have the capability or build the confidence to replace the quality analyst by yourself. One day extra effort of yours could save several days of debugging your own code in future. Besides, if you got problems and no one to ask, there is web search, there is ‘Google’. We believe, everything can be found online if you search in a proper way.

Not having patience on solving time consuming and harder issues
If you are a developer, you must have experienced small issues or enhancement to be made but took much longer and very hard to solve. This is the point where average developers fail to do so and finish their work in considerable situation, not making 100% perfect. It seems not harming anything at the time but perfection matters. It reflects your capability of how you perform your task now and in future.

Not using the same code, plugins for the same purpose
Same codes or plugins are likely to be repeated in web development jobs. So, we must collect such goodies in proper way so that we can use the same in future in less time with some css modifications only instead of downloading every time when we need and modifying whole lot of codes. By this way, you will be already familiar with the code and don’t have to trouble your head every time they need to be integrated. And this is the best way to use your past experience to ease current and future works.