How you name your functions doesn't necessarily demonstrate that you have skill or lack thereof, but rather, the names that you use should serve as a good example of how that variable or method should behave. So if I wrote a method called stringify , without you knowing the inside of the method you could probably deduce that it would convert something to a string. However if I named this method convert instead, it's a much more abstract term and you would probably have to read the method body to find out its functionality. Good variable names should describe their contents and should mean that you can hold off commenting your code with filler; it looks nice but isn't necessary: function sum ( a, b ) { // Add the two numbers together return a + b; } This code would be clearer if the parameters describe what they are: function sum ( numberA, numberB ) { return numberA + numberB; } The code is more verbose, but it's clearer that both of the arguments are numbers. You could also use something like Flow as a type system, which would make this explicit: function sum ( a: number, b: number ) { return a + b; } I tend to prefer this style over using block comments, as they can end up being overly verbose. For example, the same code using something like JSDoc: /** * Add two numbers * @param {number} a * @param {number} b */ function sum (a, b) { return a + b; } It's also good to use naming conventions when appropriate . For example, many Node-style callbacks are represented as cb : function foo ( cb ) { return cb( null , 'foo' ); } And e is often an acceptable identifier for an error: try { functionThatThrows(); } catch (e) { console .log(e); } There are others, and sometimes the language necessitates the usage of short variables so as to not confuse your variable/method name with a global keyword - e.g. fn is often used for a generic function , or str for string . Don't go overboard with custom short names though; remember at least in JavaScript there are tools you can use to compress identifiers for production code, e.g. https://github.com/mishoo/UglifyJS2 . And one thing that is a big help; don't deviate from the standard practices in an ecosystem when it comes to naming things. So for example Ruby uses snake_case for method names whereas JS projects use camelCase . In my view it's best to use these conventions, because it will keep your code looking consistent with other libraries that you may be using. It's also easier for debugging, as you won't need to remember which style you used for any given method (if you used more than one).

I prefer the plural form for collections and the singular form for each item of a collection. The new for...of makes it much nicer: const tags = document.querySelector('div'); for (let tag of tags) { tag.innerHTML = 'hello' }

Thanks! That's also a nice tool. :)

I've written a PostCSS plugin that allows you to do this automatically, instead of firing up Photoshop. Check it out at https://github.com/ben-eb/postcss-resemble-image .

I agree with most of this, but it's important to remember that we all start somewhere with respect to build automation. Grunt got me into build tools in the first place, then I migrated to gulp and finally now I'm piping CLI commands together. That progression is important; gulp & grunt exist because they are aimed at simplifying common tasks. I was definitely new to the command line before using build tools, so it was more intuitive to me to use JavaScript tooling. In short; use what you're comfortable with, but always be on the lookout for better ways to do what you want to do.

I don't think that this question is deserving of being answered by a binary choice, because like most things it will depend on the person. But I would like to answer your final question; you simply need practice. By creating projects and releasing them into the wild, you will develop skills that will help to influence projects down the road. I started my open source journey back in 2013, with writing a basic tasks list for Grunt . A few months passed and gulp came along and I was able to apply my skills of knowing how to publish node modules to writing a few gulp plugins. Fast forward a year or so and I'm writing a CSS minifier based on PostCSS , whilst my current work is involved with parsing CSS property value pairs at a very deep level. Now, a lot of this work is focused on CSS, and written in JavaScript. But I've learned how to write parsers , had a ton of experience with writing tests, fixing bugs and developing my technical skills. And I achieved this because I was interested in doing these things. The more opportunities that you use to further your skill set, the more adaptable you will become, so long as you apply your existing knowledge to new concepts and ideas. Where possible I will also try to help other people with problems; I do this in issues most of the time, but I lurk in lots of online chats and answer when I can. Trying to solve other people's problems is a great way to apply what you know in a different area; maybe you have not run into that particular problem before, so you force yourself to think how you would solve it, and then you can answer their question. This will help you develop both your technical and soft skills, and soft skills are essential for any career.