Become a Better Programmer by Understanding Testing and Your Fellow Developers


How it all started

I have 9 years of experience in writing professional CSS and HTML. I’m obsessed with writing good markup and saving every bit & byte of network-traffic to deliver a fast web application and a good user experience. But sometimes, we are lazy and this leads us to write bad code without knowing.

I hardly used testing & automation tools for measuring my code quality and automating tasks like minifying CSS, JavaScript etc. Today me and my teammates discussed about code linting as we are extending the quality assurance tool chain for the frontend developers. So we’ve set-up a Grunt task, grunt-contrib-csslint, to run the linter automatically and see how the CSS code is performing. The result of the first check seemed horrible!

I had dozens of errors and warnings and of course, a lot of things to improve in my code. For every developer who is confident on his work that is frustrating at first. I agree with the statement “nobody is perfect” but this case took the cake.

What am I doing here?

After running grunt csslint in the command line I started investigating every single error and warning. Starting at “too many font-size declarations” and stuff like “be careful using !important”. I fixed every single line of my CSS just to satisfy csslint and to stop annoying me.

But after a while I started asking myself: Why am I doing this?

A couple of minutes later I realized: I’m actually not doing this to make a simple tool stop complaining about my code but much more to understand the reason behind this. So the real answer is quite simple: Quality is important and makes a product much better. Writing HTML & CSS is easy but writing accessible, simple and maintainable code which performs well can be rather a challenge — especially when you are not testing and measuring the outcome.

Line by line, fixing those issues, I realized that I refactored almost half of my code. I changed and optimized CSS classes, added more abstraction to CSS classes and finally wrote better and more maintainable code, which is future-proof.

Conclusion

This experience made me learn about myself and gave me a good insight on how I should write code next time. It’s great to have people which you can learn from and it’s also great if you can rely on people when you get stuck in the process. We should all learn more from our teammates and take some of their experiences, because we all want to get better at what we do.

So, next time, before looking for excuses to cover yourself just try to understand what your teammates want to tell you and how you can do things better. With this is mind: Try by yourself and take your time to get better — it’s worth it and you will see that things are getting much better.