During my professional career up to now, I had the chance to work with all sorts of developers. From the reasonable to the excellent ones; and talking with some colleagues this week about that fact I have to say, it does not matter how bad or good they were I must say in every case I learnt something good with them. And one thing specially was common in all the cases: how to write a more secure code.
Which brings me to another point of discussion: how do you measure yourself as a code-writer? do you think you are a good coder? What makes you such a good developer? How do you approach a problem before you start coding?
And when I stop to think about the last sentence I remember an article I read about making your code safer and a concept I've learned reading the book "Decline and fall of the American programmer" from Edward Yourdon : The silver bullet. Basically the silver bullet is the only thing that can kill a werewolf, portrayed as a software bug or a business problem, and unfortunately just like this mythical creature there is no silver bullet for the real life issues we face everyday. There is no 'exact and single' solution for our problems.
So, to make you code safer is literally up to you. Nobody else, therefore excluding the programming language you use. Just because you are using C# it does not means it will be a better product than if you were using Visual Basic 6. OK, it will save you development and release time but just the language won't make your product better or your code safer. Again, only the developer can predict and treat the vulnerabilities.
And because of this we go to another layer of the development cycle: The design. A better and safer design can do much more for the final product than the language used to develop it. Safer products are a result from safer designs and good code practices.
It does not matter how good the product is. Once it is released, it can be attacked. No, that's not a sad destiny. As a matter of fact, as a good developer you must find this absolutely normal and expected. I write code with this in mind. Everyday. And even thou the clients tell me: "this is only going to be used within our department", I still do not change my mind. It can lead to a little bit longer development time, yes, but the gains in security and stability in the application are far greater.
So, I do not worry about the securities holes the application might have in a future because the application will run in a new platform and I should have done "this" instead of "that". Again: I accept the fact the application one day will be attacked. My biggest concern here is: How my code will behave when it gets attacked?
So, spend the time you want in improving your code. We should be proud of our coding skills just like a father is proud of his offspring.
And we know sometimes the parents can be blind about their sons skills and abilities. To avoid this pitfall with your code, ask someone senior to review your code. Meet someone who really knows what's he is talking about and ask him to review your work.
If this person is really good, I have two words of advice for you: Be humble and prepare yourself. Asking someone to review your work can be an amazing learning experience about yourself and the way you see the problems.
Remember what I mentioned: you always can learn something new, from the good and from the not so good. This is a big lesson from life to those who have an open mind to learn.
Which brings me to another point of discussion: how do you measure yourself as a code-writer? do you think you are a good coder? What makes you such a good developer? How do you approach a problem before you start coding?
And when I stop to think about the last sentence I remember an article I read about making your code safer and a concept I've learned reading the book "Decline and fall of the American programmer" from Edward Yourdon : The silver bullet. Basically the silver bullet is the only thing that can kill a werewolf, portrayed as a software bug or a business problem, and unfortunately just like this mythical creature there is no silver bullet for the real life issues we face everyday. There is no 'exact and single' solution for our problems.
So, to make you code safer is literally up to you. Nobody else, therefore excluding the programming language you use. Just because you are using C# it does not means it will be a better product than if you were using Visual Basic 6. OK, it will save you development and release time but just the language won't make your product better or your code safer. Again, only the developer can predict and treat the vulnerabilities.
And because of this we go to another layer of the development cycle: The design. A better and safer design can do much more for the final product than the language used to develop it. Safer products are a result from safer designs and good code practices.
It does not matter how good the product is. Once it is released, it can be attacked. No, that's not a sad destiny. As a matter of fact, as a good developer you must find this absolutely normal and expected. I write code with this in mind. Everyday. And even thou the clients tell me: "this is only going to be used within our department", I still do not change my mind. It can lead to a little bit longer development time, yes, but the gains in security and stability in the application are far greater.
So, I do not worry about the securities holes the application might have in a future because the application will run in a new platform and I should have done "this" instead of "that". Again: I accept the fact the application one day will be attacked. My biggest concern here is: How my code will behave when it gets attacked?
So, spend the time you want in improving your code. We should be proud of our coding skills just like a father is proud of his offspring.
And we know sometimes the parents can be blind about their sons skills and abilities. To avoid this pitfall with your code, ask someone senior to review your code. Meet someone who really knows what's he is talking about and ask him to review your work.
If this person is really good, I have two words of advice for you: Be humble and prepare yourself. Asking someone to review your work can be an amazing learning experience about yourself and the way you see the problems.
Remember what I mentioned: you always can learn something new, from the good and from the not so good. This is a big lesson from life to those who have an open mind to learn.
By Edge Pereira
