Whether an organization has a single engineer or a team of thousands, there should be a coding standard for that organization. Coding standards ensure that all developers are writing consistent code and meeting the minimum standard of quality agreed upon by the organization. For more information on developing your own coding standards, check here. An additional consideration beyond syntax and style is that the standard should incorporate best practices for performance. There are often many ways to solve the same problem, and using a tool like jsPerf will help a group to determine what method is best suited for the browsers or devices being targeted.
There should be a system of code review. Code reviews allow a group of developers to catch each other’s mistakes before they become bugs in the final product, as well as giving developers a chance to learn from each other. Code reviews can be jarring for those who haven’t done them before, and there can be many bruised egos as one’s mistakes are pointed out in front of a group. The thing to remember is that by first establishing a standard for an organization, the review becomes less about the developers competency in programming and more about his/her adherence to the standard. Additionally, even seasoned developers are apt to learn new tricks and techniques by seeing how other developers solve problems. In my experience, performing code reviews makes everyone involved a better programmer whether reviewing or being reviewed.
Additionally, an organization should employ unit testing. There are many schools of thought on unit testing. Many believe that the code should be derived from the tests; that one writes the tests with the knowledge that the code will fail and then write the code to pass the tests. Often these tests are designed to ensure that there is a specific function to accomplish a given goal, or that a variable with a specific name is defined. This is known as Test Driven Development, or TDD. Many others believe that specific tests may miss the desired behavior of an application and so focus their tests on the desired outcome rather than the presence or absence of specific functions or variables. This is known as Behavior Driven Development, or BDD. Still others, perhaps the majority of developers, believe that tests are a useful tool for checking code once it has already been written. These developers write the code and then write the tests to ensure that there are no unexpected conditions. In general, these philosophies tend to become strongly held convictions for developers and more than a few fist fights have come out of arguments on which method is best. Be sure to work with your engineering team to see what works best for each individual.
These are just a few ideas that can be quickly implemented within an organization to help ensure the quality of a product, as well as to improve the competency of an engineering team. Hope that helps!