Pages

Friday, July 4, 2014

Algorithmic challenges - if it works thats not enough.


I recently started to solve problems on CodeEval thanks to my colleague's recommendation and suddenly recognized the enjoyment of problem solving. After the boring daily routine it's a really unique and refreshing feeling when your brain starts to warm-up again.
After solving few easy problems I was very proud, because it worked! But I very quickly recognized a serious issue with my code: it just works. I had an input that I transformed to the output and submitted to the site as quickly as possible.
The code was ugly. Really. Like my first Borland Pascal solutions in the high school and I felt some shame for it, so I said to myself: calm down cowboy and think on it what do you want from this? I was already seduced by the world of algorithmic challenges (I don't no why not started it earlier...), but I had no other goals with my code than to fulfill the challenge and I almost missed a good opportunity to learn something.


I thought my options are:
1.) Should I create nicely formatted, well-designed (as well as I can...) and polished code as eye candy. I'm a software craftsman who is caring for the code quality, readibility and following strict principles?
2.) oooooor should I focus only on performance and sacrifice everything for that?

When you are attending to a coding interview usually the task you get is not so well defined and they're letting you to follow your heart during the implementation. In these cases I'm usually choosing the first version, because I'd like to show my skills as a responsible, team player person who can be integrated into a development team easily and of course it helps me to convince the employer to pick _me_ from the candidates.

But now I was free, this is my game, my world, so I can do anything what I want! So I started with the second one and that was a real fun. No rules, no principles, no nice formatted methods just the pure performance and "freedom" of coding. This was funny for the next _few_ challenges, but started to miss the good style, the structure and the clean principles in my code (that performed not so badly.). It wasn't fun anymore as I expected.

So I returned to the first and right way I followed in the last few years to solve problem and when I'm finished and I liked it _then_ I started to invest effort into the performance optimizations.

I couldn't say this is the right or best thing for you or someone else, but this is the way how I enjoy the coding: make it work, make it right and then lastly make it fast. Even if I'm skipping the TDD, trying to make my code small, easy to read and flexible.

If your code works as expected is not the end of your responsibility, just a milestone toward to make the code and yourself better.



No comments:

Post a Comment

Note: Only a member of this blog may post a comment.