To hack or not to hack, that is certainly the question! Many programmers who are learning a language tend to follow the structure laid out in a book or provided by a class they took. This is a good thing given that the book/class teaches at least some kind of reasonable coding conventions… which most do. These conventions then tend to be adopted by the programmer and follows them for their rest of their career in some form or another. Once they get enough experience under their belt however, they turn into one of two types of programmers. One type is regimented “this is how it must be done” type of programmer that writes great code but only their way. They usually are the ones that also like to have a full out plan before one line is even written. The other type of programmer is the “cowboy” coder who just opens an editor, starts coding something with little to no plan and see where things take them leading some imaginative solutions. They often get in trouble and can end up with some pretty patched together buggy code not suitable for industrial applications.
Now neither direction is wrong or better than the other in my opinion. When I work at the office I like to have a full plan. But at other times I am not afraid to be a cowboy coder. I have opened up an IDE with a vague idea of what I am going to write and just went to town, coming up with something amazing. Perhaps it is inspired by something I saw someone else do. Maybe I wanted to see how something worked and plunked a function down and tried to wire it up to some test code. Either way, I think every programmer needs to do a little bit of hacking to keep their mind sharp and open to new ideas.
Have you ever found yourself on the phone and while talking to someone you started a doodle on a piece of paper? In the beginning you were just drawing a circle over and over again, tracing over lines you had done before and not really thinking about it. Then next thing you know, as you get off the phone, you drew the next Da Vinci and are kicking yourself that you did it on a napkin or post it note instead of something you could frame. Hacking can be the same thing. Start out with a line of code, add a little more, make it a function, generalize it, maybe refactor it, mold it into something that can handle a specific task or do something it didn’t before. Next thing you know you have a great utility class that will serve you for years. The occasional hack can do that for you!
Of course there are limitations to this and you probably should have a plan if you are working on a major project or getting paid to write a company’s next CMS. Have a plan when it counts and hack when it doesn’t. If you don’t find yourself doing both regularly, you are doing something wrong.
One last thing I can say about this is that with hacks you are going to fail a lot. Heck, most of the time you will. That is perfectly ok. Over the years I have had hundreds of hacks that just didn’t work out. But that is the beauty of hacking… when you fail, who really cares? That doodle you drew while on the phone, most of the time no one will ever see it unless you show them. Happy hacking and thanks for reading!
