I am a self-criticising programmer. But I think that I know my self in deep. I know my limits, how much can I bring, how much can I deliver. I know both very well. Along the time, being self-criticising is not about being masochist on thoughts, it is more like being reasonable, thinking on how to solve problems reasoning rather than using something like trial and error methods — usually described as «the process of learning where doesn’t happen from failure itself but rather from analysing the failure, making a change, and then trying again». Instead of failing, I try to solve problems analysing them.
You as programmer probably know about that — but only if you have gained expertise on certain programming language — where you have learned more stuff than it was shown to you on a classroom or course. Because you know that to reach a good level on any programming language requires more than courses. It requires book reading, exercising, reasoning on that programming language, learning about its features, its limits and how it is implemented. This clearly avoids many programming errors and reasoning errors. A code monkey, does many failed attempts to solve problems guessing which call should be used on a block of code, rather than reasoning and using the right calls where they are required. There is an old phrase that you will remember, and it is not told as joke I think: «Read The Fucking Manual». RTFM is probably one of the oldest phrases on the Internet. Almost all specifications and user manuals are public documents, you can read them online, print a copy if you want and mainly you can learn from them.
The classical example is how is being used the garbage collector on Java and similar programming languages. There are many applications reaching the OutOfMemoryError, due to memory leaks. Because many programmers are misunderstanding the concepts behind what really does a garbage collector, and they are mostly based on reference counting. So, any memory related problems on applications where the language uses a garbage collector, is just a subject of misunderstanding what really does its garbage collector. Other two errors are heap overflow and stack overflow errors, if you reach them, you still need to know in deep the programming language that you are using. So, any programmer reaching that kind of errors still requires more knowledge to be called expert. But that knowledge is public, there is no black box and there is no black magic behind those errors, you just need to read the programming manuals and related documentation. So, there is not excuse to reach that kind of errors.
So, for me if the language or the environment brings me an error, I start researching about that error until I get it solved. For me is not a subject of increasing hardware resources or similar stuff until I get a real proof that it is really required. An error for me need to be solved from my code first, not the environment, because my code is my responsibility, not the environment. An example of almost bug free software is pyxser, it does not have memory leaks in its code and it is safe to be used in production environments, you can do up to 1.000.000.000 of continuous and parallel serializations-deserializations with pyxser, without leaking the computer memory, you just need to use the proper calls. A product with that quality was obtained only because I was very strict and self-criticising. So I have created a serializer that does not crashes with cross references and circular references — which is not implemented in other XML serializers — and it is very robust because I was a self-criticising programmer. You can try to serialize, for example, a Django Model class instance (object), and you will not be able to do it with other serializers like simplejson. So, being self-criticising is not bad as you think…
Entries 