Taking Advice

Over the years I’ve written numerous blog posts both on my own site and around the web too. They have ranged from topics close to home and choices in life that I’ve made, to being focused on programming and technology. I’ve often used my blog to share code snippets and to ask opinion on programming methods. As a person, I’m always keen to listen to others, both in technology and life.

It’s always fascinating to learn how different people approach problems and whether I can learn anything from their methodologies (the answer to that is yes, I’ve learned a lot from others including correcting some of my own practices). I have always believed that you should take on board advice from others, especially those who have worked in the field for as long as you. There are far too many people who are ignorant to the methods of others, which cannot only cause stagnation in projects but also severe repercussions.

Consider the following scenario:

You have a project that has a login system or some form that someone else has written. After investigating further, you find a bug in this system that allows anyone to bypass the login mechanism. You report this to the developer of the application who then is adamant that they have correctly built the mechanism to their previous standards.

The above scenario is entirely plausible, XSS, CORS and other hijacks are evolving all the time, a piece of code that you wrote two years ago could easily be insecure now. In our field and world of technology, we can never sit still. Things evolve constantly on the web and if you don’t change with the times then you’re going to have issues. I’ve spoken to a few people in the past who had the same attitude as mentioned above, their code was ‘secure’ when they wrote it so why should they have to change it now? It’s an all too common attitude within the programming world. A world where the majority of developers feel the need to 1-up each other and prove that they’re the best of the best. I can remember reading a blog post on a similar topic recently, ‘Developer Envy’. This attitude cannot only lead to problems when working in teams but also can be the downfall of major projects if it isn’t managed properly. Every one wants to succeed, that’s part of human nature.

As a developer you have the right to question others and the way in which they have approached problems. When we were kids, we were always the ones who took their toys apart to see how the worked. This undying curiosity is what powers my life and my personality, I always want to know why. The same comes with the projects that I work on, if you have done something better then I’m happy to listen.