Graham Barnard

Understanding why mistakes are neccessary




Understanding why mistakes are neccessary

Posted by Graham Barnard on .

I’ve been reading a lot in the last couple of weeks, books about different aspect of development including cleanliness, organization and professionalism. I read SMACSS which will probably change how I write every line of CSS. I read Clean Coder which will change so much about how I write and interact with my colleagues, managers and everyone else on my future teams.

A noticeable theme that continuously happens when reading good books is a jealousy that I wish I knew these concepts when I was doing this specific estimate or when writing this specific module. These new ideas all seem to be so important to me now and I feel a bit unprofessional that I didn’t know some of them before. It makes me feel bad about using bad variable names or being a week behind in an estimation where it was so trivially obvious that I was just being overly optimistic. And the truth is that I was always feel this way and if I didn’t feel bad about something that I wrote 6 months ago then I’m not growing as a developer. I’m spending major part of my personal time improving my craft and if my old code doesn’t disgust me a little bit then something is obviously wrong.

The great example of this happened to me this week while I was reading “Clean Code” by Uncle Bob. I read something that he named “The Boy Scout Rule”. This is the simple idea that you should leave the code cleaner than you found it. It’s a powerful notion that you should be continuously refactoring the code that has been written even when you are just reading it or making a simple bug fix. Now it’s very possible that people could have read over this fragment of his book and not be as effected as I was, they could agree with the idea but it might be an afterthought to the other principles in the book. But it affected me a lot, as I spent the last year of my professional career maintaining projects created by outsourced programmers. And it was base code, friends of mine know that I had some hatred towards what was written as it hurt me to work on the project at times. And I spent a lot of my personal time trying to make the code better, I moved all the CSS to headers to avoid duplication in the view files, I organized the JavaScript files to avoid files being accidentally loaded twice, I removed commented code for every source file that I used and changed the indenting (or lack of indenting) so it was more readable. But the hard truth that I felt this morning was that I should have done more. I was rushing to fix customer issues, I wanted to be viewed as someone who could get things done and it’s only now that I see that I hurt the project by not spending the extra time to removing duplicated functions or not renaming variables to something readable instead of k, kk and kkk. I was so convinced that the project needed to be properly redevelop because the code base has such a crippled foundation that I didn’t want to save it. But the truth is that I could have saved it.I had this notion that it was someone else’s code, it was those silly outsourced programmers who messed it up, but the truth was that I had been redesigning it for a year and it should have been cleaner, it should have been more understandable to my replacement and I was being unprofessional by not fixing the obvious issues that existed, ignoring the 7 different Ajax calls which all did the same thing.

Now you can understand why I read the concept little tidbit about leaving code cleaner and instantly feel this pain in my gut because I finally understood all of this outward anger over the last year should have been anger towards myself for not doing a professional job of not refactoring the files as I touched them. I made the code base worse by building on their bad ideas instead of fixing it, I was the owner and the one who could have polished it up. Some many easily solution come to mind right now like adding automatic triggers to avoid some of those silly syncing issues, creating a custom controller class to remove all that duplication that existed in the or fix that helper file so it wasn’t 10,000 lines of useless functions. Yet if I hadn’t gone through that year of maintaining legacy code, I wouldn’t have taken it the advice so personally and finally be able to say to myself that I made a big mistake and I know that never again will I allow a project that I work on to be so damaged. I will never blame someone else for something that was working on, I know understand that it’s my responsibility as a professional to combine the knowledge of the original creator and myself to create the most elegant piece of code possible.

And the truth is that I have heard this advice before, I clearly remember about 2 years ago reading “The Pragmatic Programmer” and a chapter be devoted to the concept using a metaphor of a broken window in an abandoned building. My brief description of his concept is how people are extremely extremely less likely to vandalize a building without broken windows and that programmers function the same way. We use the excuse of existing bad code to write bad code instead of refactoring it. I remember reading this and understanding the importance, but not to the degree of this morning. I hadn’t felt the pain that came from not applying it in practice and it stick with me. But now I know after dealing with it for so long, I can fully appreciate it. It has been taken to heart and will change how write, debug and read code. My experience has shown me how important it is to be continuously looking for new ways to improve it. And honestly it feels like this great weight has been lifted from me because know I understand the bigger issue behind this. I understand that these mistakes and pain that I endure are quintessential to my growth. It allows me to understand me to take essential advice to heart because the mistakes have shown me the sadness of not doing. It’s very liberating to know that all I can do is be as dedicated to the lessons that I learnt already and continuously refactor my code with the new knowledge that I will learn. I have and will always find that my old code is a bit dated, so I know now that the right thing to do is update it. These ideas are trivial but it’s only after seen this concrete example that I understand that my mistakes are important to my growth.

I’ve been doing this professionally for about 2 years right now and I know that next year I will be a little ashamed of the concepts that I didn’t know at the time. Probably because I’m hard on myself, but at least now I can say that missing those concepts were important for understanding why the matter so much. And it makes me want to continuously be reread great books to be able to see what I missed when I read it the previous time. It shows how our career is like a staircase that allow us to get a better perspective through time. So don’t enjoy the mistakes that you make, but understand that they are important as long as you are not continuously making the same ones. Cascading Style Sheets (CSS) is a style sheet language used for describing the presentation semantics (the look and formatting) of a document written in a markup language. Its most common application is to style web pages written in HTML and XHTML, but the language can also be applied to any kind of XML document, including plain XML, SVG and XUL.


Graham Barnard

Senior Salesforce Developer