The most important thing for you and your team should be communication.
You might want to develop a common styleguide that defines things like "how should a date range be named". However it's very important that this styleguide is appreciated by everyone on the team. If anyone has the feeling "oh my god, I know how to do my work and now I have this stupid document telling me what to do" then the effort is doomed from the beginning. On the other hand if everyone agrees "yes, that's a good idea, now I know where to check when I don't know how to name a thing" then you'll be a lot more productive.
However such a common belief is established best, when everyone is part of the development process and feels like "yes, I contributed to that set of guidelines". If your programming team is small, as you wrote, then it's the ideal situation.
The other fact will hunt you for the rest of your development life: You will never ever write perfect code. That's been said alread. But you will never ever write code, that when you're revisiting it a few weeks later will still look good to you. Even if you're the only one having touched the code. I always find myself thinking "my god, what the hell have you been thinking when you wrote that piece of crap?". The funny thing is: I know, that I had my reasons for doing something in exactly the way I did - I just can't believe it any more.
You have to accept it, and yes, it get's worse when you're working with somebody else because - let's face it - writing software is like driving a car: nobody can do it better that yourself ;-)
So, you will always have to refactor your software. Fix the things you did wrong in the first place. That's a good thing and totally normal.
Bosses don't really ever seem to care about the quality of the code, just when we'll be able to release the next version
That may be true on first glance. Luckily not all bosses think that way, but even if they do: Code quality has a direct effect on the ability to ship the next version. Bad code leads to more bug, leads to more time needed to fix the product, and so on. The central element here is communication - once again. You have to embrace the thinking that refactoring and introducing better code is an integral part of the development. Refactoring is not just "Oh, this looks better, let's take some time and implement the change" but making the product fit and robust for future generations. This might require some backbone telling another person "No, we can't move on, we need to refactor feature X" but that's part of the job.
It is impossible to give a definitive answer to this question, because it depends too much on the particulars of the situation.
Consistency in style of the codebase is important because it helps in making the code easier to understand, which is one of the most important aspects of maintainability.
You wouldn't be the first programmer who got cursed to hell for making the code hard to understand by mixing different styles. It might even be yourself that does the cursing in a years time.
On the other hand, using new language constructs that didn't exist when the code was first written does not automatically imply that you are reducing maintainability or even that you are breaking the style of the code. That all depends on the particular language features you want to use and how familiar the team is with both the old style of the code and the new features.
As an example, it would generally not be advisable to start introducing functional programming concepts like map/reduce to a codebase that is completely in OO style, but it could work to add a lambda function here and there to a program that didn't use anything like that before.
Best Answer
1. Writing lessons? Not really.
Writing source code is different enough from writing a book.
While both pursue the same goals: being as unambiguous as possible and being easy to understand, they are doing it in a very different manner, and things a writer should learn are not the same as things a software developer should learn.
Example 1: figures of speech
Figures of speech are valuable when writing novels, poetry, etc., since they increase the expressiveness of the writing.
What is the last time you've seen an oxymoron or a litotes in source code? Would it help to have them, or would it rather be extremely harmful for any developer who will have to maintain such source code later?
Example 2: vocabulary
Rich vocabulary is highly appreciated in literature. Vocabulary of William Shakespeare, for example, is twenty thousand to twenty-five thousand words. Richer vocabulary makes it more interesting to read a novel or a poem.
When you write source code, you expect it to be read by people who don't speak English very well. Showing how well you know English would be extremely harmful for your code. If you know a fancy word which means exactly what you need but you know that lots of people don't know the meaning of this word, you should rather find a less expressive synonym or a set of words which explain the meaning. A vocabulary of a few thousands of words is often largely enough for a given project.
Note an important aspect: while Google Translate could be of a great help for a non-native speaker, there are two issues with any translator:
A pair of languages don't necessarily have a 1:1 match between the words. Some words have either no translation in other languages whatsoever, or multiple words could translate into a single word in a foreign language. For instance, in Russian, there is a huge amount of words which target specific states of snow and cold weather, and translating them in French or Spanish is usually impossible without losing their specificity.
A word sometimes has multiple meanings, and the meaning is deduced from the context. Google Translate, despite its high quality, is usually unable to indicate the meaning for any but the most basic situations.
Example 3: expressions
Expressions make prose richer as well. An author expects a reader to have a given amount of general culture, and uses this opportunity to make the text more expressive.
Similarly to the previous example, such expressions could be very problematic when read by people who are not native speakers. But if general vocabulary can usually be translated, expressions are much more problematic.
For instance, English is not my first language, and on daily basis, I encounter expressions, including here on StackExchange, that I don't know. I try to guess their meaning, and sometimes I'm right. But sometimes I'm wrong, and Googling those expressions doesn't help.
A user in her/his comment reminded me of an example which made me suffer for a long time when I just started programming: PHP's needle and haystack. I was unaware of the corresponding figure of speech, so every time when I was reading the documentation, I was wondering what is this all about. Needless to say that C#'s
sequence.Contains(element)or the excellent Python'selement in sequenceare a much better alternative. Well, at least, developers who don't know Hebrew had to suffer from PHP too, but this is a different story.Example 4: cultural references
Cultural references. In literature, it is tempting to include elements from a given culture, and this too makes the book richer and sometimes more interesting to read.
However, code is addressed to developers from all around the world. Therefore, what is an obvious reference for an Italian developer may not be that obvious for a Russian one, and what every Indian boy or girl knows may not necessarily be known by an American programmer.
The same user who talked about the needle and the haystack gave an excellent example of such cultural reference too: the Grail. Who doesn't know what Grail is? Well, I mean, it's “Graal” in French, “Grial” in Spanish and... “Kutsal Kâse” in Turkish, but still. However, how much American or European developers know the medieval history of China or India? Why would anyone assume that every Chinese and Indian programmer has to know the Holy Grail reference?
2. Lessons to write expressive source code? Sure.
Any developer should learn how to write expressive source code.
Any developer should explain why the comment in:
is bad, even aside the fact that it's totally wrong.
Any developer should be able to understand the basic refactoring and how it helps making the source code more expressive.
Any developer should remember that 20% of the time is spent developing code, and 80% of the time maintaining it. For some projects, it's more like 5% - 95%.
etc.
In essence, programming is close to technical documentation. Does a person who writes a spec sheet for a bolt need to take writing lessons? Not really. The same applies for developers. Anyone should write without making spelling mistakes in every word, and anyone should be able to communicate her ideas clearly enough. Aside that, I'm not sure how writing lessons would be more useful than, let's say, a course in Computer science or in IT security or whatsoever.
The expressiveness of the source code can be learnt by other means. superM mentioned one of them in his answer: reading good code. I can mention a few others:
Reading books like Beautiful Code or Code Complete,
Asking for a more experienced developer to review your code,
Understanding patterns and how and when to use them.