Thoughts

Today I've found a sheet of paper where I've written some of my conlusions several years ago after implementing a relatively large subsystem of the system I was working on in a large company.

1. To learn you have to make errors. You have to praise error rather than be afraid of it. "If you speak less and less, you'll have to speak more and more" — Cortasar wrote in his "Exam" meaning that not speaking makes the language and your command of it and expressiveness theirof degrade, and losing its expressiveness it makes you build larger texts. So, the same applies to errors: if you do less of them, you'll have to do more later.
2. You shouldn't be too clever in trying to overcome a difficulty: a much more efficient way is trying to avoid it altogether. So, you need to think about the nature, the source of the problem. Perhaps *it* can be removed. Being too clever in overcoming problems, seeing at once a (long) path of fixing a problem can obscure a (short) path that bypasses it altogether.
3. Relying on data format (think XML) in many different places weakens ability to change (and to support): changes in the format will lead to changing all places of using.
4. Premature optimization is the root of all evil (see (2)).
5. Data that differ slightly (say, two similar formats) are dangerous. You have to repeat yourself or at least are very urged to (things differ). Alternatively you can work out rules of conversion, but that conversion will most probably break when some change is introduced. Say, we have one source of data and all just works, we don't even think that there's some part of the code that builds another format upon it. We change the source format substantially and things suddenly break.