1. learn about semantics

And by that, I mean truly learn about semantics. Not just the simple meaning of the available html tags, but also the reasons why we aim to write semantic code. This might sound very simple, but take one of your websites and take a good look at the class names you defined. Did you give them simple names or complex computer-like descriptions. Did you make sure you applied them consistently across all the pages. Not to copy css or javascript functionality, but because the elements are essentially the same.

If you have blog posts, products, events or whatever other returning content type on your site, did you make sure that every content type, no matter what its context, received the same class name? .productList li doesn't cut it. A program doesn't make the assumption that productList is a concatenation of two words, making the list items "products". A program sees two different class names and leaves it at that, unless specifically programmed.

You once read that it's smarter to define a base class to an ul rather than place a class on each li? Sure, I've read that too. It's not necessarily wrong, but we're talking semantics here, not styling. So take a moment to consider how you handle semantic value in your documents. Are you really thinking about semantic value, or are you just worried about how to get your css in there?

2. learn about structure

html is more than semantics alone, it's also about structure. Tags like header, section and footer are there not to give specific semantic meaning to elements, but to group elements and to express relations between them. They are the foundation of your document.

Don't write html as a means to style your site or to add certain functionality. Wrap elements that belong together not because they are visually grouped, but because they belong together. If might not be useful now, but once the code is implemented in whatever cms you will notice that these elements give you a more flexible html structure.

Concepts like iterative design and scrum allow for quicker and smaller updates. Make sure that the code you write is somehow resistant to these little changes, or even complete redesigns. If you have to ask a code change for each question asked, you'll end up looking like an amateur.

3. keep your css clean

Sure, you've read this a hundred times already, but do you actually make sure that your css file is as clean as can be. Did you define general sections like grids, navigation, simple content, components, forms etc to structure your css? Did you group all css rules for each component, starting from the root tag, gradually going deeper into the component. Did you separate different components with a little title in a css comment? Made sure that your whitespace between rules and sections make any sense?

I see lots of css files pass by on a daily basis that do none of these things. The idea of keeping a clean css file might make a lot of sense to you right now, but once you start styling, it's a lot harder to actually achieve it. Take a half day off and make yourself a template for your css files. Define which sections return in each project and stick to them. Keep all the css of a single component nicely grouped and make sure that you comment where necessary.

When phase 2 of your project starts, you will thank yourself. Other people working on your code will do the same.

4. think, evaluate, improve

Usually projects are running on a tight schedule. This means you'll have to make choices during development that aren't as well-considered as they should be. This is not a bad thing, just make sure to take the time afterwards to think them over. Have a good idea, write it down and implement it in your next project. If it doesn't work out, just drop it and try something new.

Becoming a good front-end developer takes time and practice. Just make sure that you learn from your mistakes. Some parts are harder than others, but if you keep looking at a certain problem from different angles you will end up with a solution that's at least satisfactory. And if you're really stuck, ask others to give their opinion. There's a world of front-end people out there blogging about their job every single day. Most of them are very willing to help you out.

5. don't believe the hype

If you want to be good, inform yourself. Doesn't matter whether it's books, blogs, colleagues or courses, just make sure that you are following whatever is going on in our tiny world of front-end development. Just don't believe all the hypes. Many bloggers use their articles as self-justification for their own methods. No matter how many times you've read it these last couple of weeks, don't believe that css3 is ready for use. Don't simply believe in graceful degradation.

Read and ask all you want, but be sure to make a critical evaluation of what is being told to you. It's all about agreeing, not about believing. Front-end development is a pretty specific field dealing with a billion different people, using a billion different setups. Make sure that you give them an experience worth having, even if they are using crappy hardware or software. Things might look good on your screen, but if they suck on someone else's, you've lost your credit.

Using the latest technologies is fine, as long as you know where their limits lie, what the impact is on future development and how they leave older setups. People are right when they say that a single person will not compare your site in different browsers, but be sure that he will compare it to other sites. And he might be wondering why yours is so square and using solid color drop shadows. He'll probably think your site is a little sloppy compared to all those others. Is that really what you want?

conclusion

Nothing new you say? True enough, but the fact is that these pointers are still being neglected to the point where many professional companies are coming off as truly amateurish. Like most things that appear simple, mastering them can be a real pain. So make sure that each new project you tackle adds something to your skills. Read, try and think and rethink if it's not helping you, that's all there is to it.