Re: Re: Coding standards and personal choice.
a) frustrate the engineer/programmer, who is an artist, and shouldn't be told how to hold his/her paintbrush
I didn't have a FreshMeat login, but this comment inspired me to get one just so that I could reply. I think that one of the main problems in the software industry is that programmers act like artists instead of engineers. If the value of being told how to hold your paintbrush is that someone else can read your programs for maintenance or debugging purposes, then that's a trade-off that everyone in this industry should be prepared, even happy, to make.
At the company I'm at now, we employ co-ops for short-term labour. The chances that they'll be around when I need to make a change to "their" code is very low, and so I am thankful that they are using the standard coding style, since it removes a large barrier to my understanding of their code.
I got me a freshmeat account also to reply to this as well. I agree with what Blake said, but wanted to add my own bit. I used to be a consultant developer and program for a living. I changed that this summer when I finally got fed up with the effects of various business practices have on my ability to create what I felt was a good product. But while I was there, I thought through many of my philosophies on craft vs. work that I write here.
Businesses are entities which don't always mix with allowing programmers to create art. They have other priorities, like readability, scalability, maintenence, conformity to standards. This allows them to substitute coders for other coders--move people around to get the best fit. These priorities in many cases prevent absolute coding freedom. In addition, one is usually part of a team and you have to have some team standards otherwise the team is not productive. i.e. What happens if I name all my variables in phonetic variations of Japanese? My co-workers would have beaten me with wet noodles because the standard was to use short words found in English.
I think if you want to code for a living you really have to follow standards set by the team you're working with. You're not an individual creating an artistic masterpiece, but a member of a team engineering a solution to a series of problems. In order to be a functional member of that team you have to follow standards.
I do a lot of what I call hobby-coding. My hobby projects encompass solutions for the problems I require solutions for, as well as being artistically beautiful solutions to the problems. I get to maintain my craft and my confidence as a craftsman. I have the freedom of trying new approaches, toolkits, platforms, and such. I use my own designs. I have these freedoms because I'm an individual building solutions for my problems. There aren't many other people involved.
So, I think you need to approach this like any other craftsman would. On the job you have a responsibility to yourself and your team to produce good code that follows the team's standards. But when you're not doing job-work, you can play around a bit and have the freedom to practice your craft. This then satisfies your need to create beautiful things and feel positive as well as satisfying the company's (and client's) need for a working solution that meets their criteria in a team-focused environment.
I think if you don't separate yourself this way, you will get frustrated and you'll be a huge detriment to the team. Life's too short for that. If you can't separate yourself, maybe you should code as a hobby and not as a line of work. Craft and work don't always have the privelidge to go hand in hand.