Well-thought refactoring vs coding inertia

About importance of self-recycling and slow down eventually

Disclaimer: This is not a technical post. No snippets, no examples, just thoughts. Well... just sleepless night thoughts. However, you could be reflected on them and maybe it is worth to read. If you have the feeling that your code is not good enough of it was but as long as you work again and again in the same project it is becoming an uncontrollable dragon, then Khaleesi, continue reading, you don't want to be devoured by your own spawn, I think. Let's analyze my/the typical problems when coding.

Problem 1: Reusing code indiscriminately


Something that I'm experiencing very often is the fact that I reuse my own code too much. There is nothing bad in that itself, actually, this is not a post against the code reusability whatsoever. On the contrary, this is a post about how to reuse it better because I realized that I'm not doing that in the right way. Once and again I tend to use the same approach because it worked to me and it is very comfortable to just copy-paste snippets. It works and allows you to move forward. Great! (or maybe not).

Problem 2: Refactoring only when 'this is impossible to manage'


Surely, you are refactoring your own code every now and then, however maybe you have the same feeling than me: when should I invest some of my time refactoring my code? Yes, 'when'. That's the key.

Time is the main limiting factor in our job. Tight budgets and deadlines force us to work as quick as possible which, many times, turns out into a not well-thought code we are not very proud of. Time is the main raw material in software development and nobody wants to waste it.  The result is basically that common "we'll do it later" suicidal tendency.

Problem 3: Lack of self-recycling


In my opinion, best developers (in general best professionals) are those that always try to improve, never conform to their current skills and have some healthy anxiety because they are not good enough. Again, time have the opposite effect. We tend to say "later", "I'm good enough", "There is not time for that". My proposal here is simple: invest 2 hours along your week (you choose the right moment) investing in yourself, in you skills. For me, a php/laravel developer, Laracasts.com is the perfect academy to become a better developer. Just a couple of series a week (1-2 hours) helps me to self-recycle.

Problem 4: Time


Nothing to explain here. Life would be nice if have unlimited time, but we haven't. Basically, we need to squeeze it. That's all.

Fact 1: Coding inertia


That's me. I like to make up words and concepts to illustrate things. I think there is nothing called like this (I googled it and got a website from a  guy in Idaho) but it was just a coincidence, sorry Andrew.

What I understand by 'Coding inertia' is that evil force that drives us to 'copy-paste this from that project because it worked there' without thinking if this is the best solution. This force does not depend on mass like gravity. It is a matter of hurry, though. Some other factors are important, especially, the feeling that the code your are re-using is a really good piece of work.

As an example, we in Square1 are such fans of the Repository Pattern. Even though it is so cool and handy I have done some botched jobs (I'm guilty, I admit). Just doing thing like... ok, it's working so, ...mmm let's add a method here... well a new property there... yep well let's add another private method and that's all. The snowball is rolling downhill, now try to stop it. Be careful, Khaleesi, those teeth and claws are growing too fast.

Fact 2: You're thinking too little


Yes, did you never have the feeling that coding is the same than typing? Yes, the more code you type the more productive you are. Well, absolutely wrong idea. Code must be the final result, the outcome of a well-though idea. I'd say the 75% or more of our work is thinking the rest typing in the keyboard.

Fact 3: You do not see the problem


This is why recycling is that important. As far as you learn more and you have a wider perspective you foresee problems and you are more aware of the bad quality of your code. Never stop learning.

Conclusion



  1. Try to keep yourself informed. Try to learn.

  2. Ask yourself (always) how to improve your code. Try to think of a different approach, even though you discard it later.

  3. Refactor as a daily-basis habit. Refactoring shouldn't be a solution to a big problem, it should be part of your coding routines.

  4. Reuse code, but be smart. Reusing is double-edged sword, it can save time and you have to do it but it could be the origin of bad quality code flooding.  Watch out!


Happy coding!