Månadsarkiv: oktober 2016

What do to?

One thing that tend to be a bit problematic for me whenever I want to try out a new programming language or technique is coming up with something meningful to do. ”Hello, world!” is obviously a good place to start, but where do you go from there? Perhaps you have some functionalty that you kind of always implement as a kind of reference, and that’s great! That approach hasn’t quite worked out for me as of yet.

For me, the ideas that get me going are commonly too complex and ill-defined to be suitable being new to a programming language. The result is most often a pile of code far from the grand and not very clear vision I had from the beginning. And that’s not very fun.

Now, a couple of months ago, a former colleague of mine told me about some programming challenges posted weekly by Jamis Buck. Prior to that, I had spent a couple of evenings trying out Clojure, but as ususal my idea was too grand with respect to my limited skills in the language. I decided to leave the pile of code to rot and instead start hacking away at the current weekly challenge, which was about finding the shortest path through various mazes.

It took a couple of evenings for me to complete the challenge, but in the end there it was (and here it is on GitHub). The problem to solve was crisp clear, and the solution, implemented in a language new to me, fullfilled the given requirements. The code was far from perfect, but it worked and the solution was complete. And that felt pretty good when compared with the usual pile of code that doesn’t really do anything.

I guess you can find programming challenges all over the web if you look for them, but for me the format that Jamis Buck have come up with is pretty sweet. After some thought I think the reason why this format works for me can be summed up by the below three key points:

a) The problem to solve is well-defined and limited
b) There is a deadline
c) No pressure, just fun

I think I’ve made my argument about well-defined problems and being new to the programming language at hand pretty clear above. Along with being well-defined, the scope in his challenges are limited and require not too many hours to complete. The normal mode for solving a challenge usually takes an evening or two of work, depending on how comfortable you are with your language and the algorithms to apply.

Another key thing is the deadline. To have a date when you need to finish means that you can’t polish your code forever. You have to let it go and, before the time is up, publish it somewhere (e.g. on GitHub) in order to submit your solution. And I think that is something valuable as well, to practice in being comfortable with exposing your code publicly.

Moreover, you get to see the same problem you’ve been working on solved in various languages and with different approaches. The way you ”hand in” your solution is by posting a comment in a web blog post, so you can have a look at all the other attempts there as well. It’s pretty cool to see the challenge implemented in Javascript, Clojure, Haskell, Elm and whatnot.

And finally, it’s okay if you don’t get there. You don’t actually have to post your solution at all, so there is no pressure at all.

Just fun.