Just go to John Skeet’s blog and assess yourself. In short, are you really able to work in a team?
#1 - Overengineering (in complexity and/or performance)
I agree. It’s important that your algorithm/method has time complexity O(n) instead of O(en) but it’s not very often really important whether you use foreach or for loop. Mind that the first one makes code much more readable. But I have to emphasize that casting to String and calling ToString method is a different kettle of fish because if you call ToString it means you are not sure what kind of object you handle and I call it “text based programming” which I hate :).
Personal guilt rating: 5(but I’m aware of it and I’m working on it)
#2 - Not considering the code's readership
I agree. I think that there should be even a subject during everyone’s studies that deals with code maintability.
#3 - Assuming your code works
According to the quantum physics theory everything is possible to some extent – just probability. Therefore I don’t assume anything :).
#4 - Using the wrong tool for the job
I’ve noticed that if a company is Microsoft oriented then it doesn’t even consider using Open Source software and the other way around if a company comes from the Linux world it hates Microsoft solutions just because it comes from Microsoft. It’s strange but true.
#5 - Excessive code pride
I have to be proud of my code but from time to time I probably should just keep saying: It’s not my baby, it’s not my baby…
#6 - Failing to acknowledge weaknesses
I think that it’s a good habit to mention to people (at the end of the conversation) that I am not sure about this and that and they should check it on their own.
#7 - Speaking with an accent
I don’t like using any technology/tool/approach I don’t know/understand and I think that a coping of some patterns it’s really possible only if someone doesn’t know the technology/tool/approach he/she uses.
No comments:
Post a Comment