It strikes me as very, very interesting how, especially in the world of technology where everything is thought to be so regimented and precise, where a single typo can be the difference between compilation and error, that there is so much versatility in every step of the creative process. This is, of course, a result of the nature of the industry, that being a knowlege-based economy, but the observation still holds strength.
I’m beginning a new project at work where, for the first time, I’m working with a large team of developers, and not just integration developers but front-end developers like myself. Since I’m the new guy, I’m finding myself required to learn the teams established vocabulary and this is making me realize just how much of my own vocabulary I have developed myself without even realizing how large it’s grown.
It all comes down to how we organize our code and that, of course, depends very much on how we are used to thinking about things. On a team of people working together for a common goal, such implementation-specific details are much more central to the success of the project than when working alone, such as in a freelance situation.
It’s interesting to me to see how many of the the established coding standards and naming conventions are obviously built off of the same kinds of ideas that I’ve already had and have been using for quite some time, and yet how different they are in implementation. This extends beyond the obvious case of using dash-separated class and ID names instead of camel case lettering or vice versa. It goes so far as to project management and workflow considerations, file name conventions, and semantics.
In some cases, optimizations are actually sacrificed on a team in favor of clarity, but this is actually a good thing. In my freelance work, I typically squeeze every last ounce of optimization into a project by using shorter names, more optimized files, and extremely dense code to ensure the best possible result. In a project with other developers however, the success of the project is far more dependant on everyone’s collective understanding of the code, so clarity is and should be prioritized above optimizations.