During my rather short period of Pair Programming I have learned something valuable, but there is also something I’ve learned after that. Michal Tehnik left the company and I continued to work on code we wrote and then refactored and polished together several times. It is probably the best piece of code we have now in our code base 🙂 We did not have the time to finish it, so it was my job to that.  I needed to add some need features and fix few bugs. I could have done it in two ways. One way was to do it as quickly as possible by tweaking the code or by introducing some hacks or workarounds.  It is fast but the produced code is then less legible and possible bugs are harder to trace. The other way was to invest more time and mental power to write as good code as I could and then refactor it. That’s important so I will say it again: Refactor your code. It is quite likely that the second or third time you look at your code in order to avoid duplication or badly named functions you will always find something in there to improve. Believe me, its worth it.  (Credit for lesson learned goes to Michal Tehnik)
A couple of days ago I needed to change something in some code I wrote about 3/4 year ago. It was written fast. I was quite new in the company back then and I did not want to look incompetent so I wrote it as fast as I could. So it is not surprising that the architecture is not very good. It turned out it needs complete refactoring 🙂 Partly because of how it is written and partly because of the new features.  I mention it here to encourage you to really invest the time and effort to write as good and generic code as you can. When you are done writing, it’s time to refactor. And then ask someone to review your code. It looks like a lot of work (and it is), but it will probably save you a lot of sweat in the future.
How do you measure the quality of code? Read about the Four Elements of Simple Design to learn more.