A Brief Coding Aside

I haven’t yet started the core coursework for the program I’ll be using to learn software development. I’ve finished the prep-work and have sent the info requested to begin the curriculum. I am hoping to get started sometime next week.

In the interim, I thought it might be interesting to post an example of one of the prep exercise solutions I wrote. This is an exercise from Chapter 10 of Chris Pine’s Learn to Program book where you are asked to write a method to shuffle a list. If you’re familiar with the book, you’ll notice that my solution is different (I wanted to make sure that in the shuffled list, an item would never occupy the same location it did in the original list — something there is no guarantee against in a truly random shuffle). Additionally, the author’s “How I would do it” version is a single line (sans the def/end lines for the method) compared to my solution of almost 20 lines (not counting the empty lines). I could have made it shorter by removing the test after the shuffle is complete but left it in for completeness.

Although even the base solution from the book is shorter and definitely more elegant, I wanted to post my own because I think it will be interesting to me a few months or years down the road to see how I approached the problem now versus what I may do then. The code below is written in Ruby (version 2.4.0).

So, without further ado…

Is it efficient? Nope. In the author’s solution he picks a random entry and pushes it into a new “shuffled” array while iterating over the original array until it’s empty. In mine, I loop through generating a random index until it’s one that is unoccupied in the new array and is not the same index as the original location of the item. Again, not horribly efficient but it achieved my aim.


What Did I Learn?

The prep work, in general, taught me that, even beyond my need to become more familiar with the various tools that the Ruby language provides to make a developer’s life easier, one of my biggest exposures currently is a lack of experience in thinking “programmatically”. I say this even having had some experience in that realm. I am still completely in the stage of “not knowing what I don’t know” but I can see the “knowing what I don’t know” horizon from here :)

In more specific terms, the exercise taught me that, if the built-in methods don’t meet my specific criteria I can easily override them ( and “easily” does not necessarily mean “safely”). Ruby makes it very easy to override built-ins which is one of the things I like about the language but I can recognize that it’s also a potential pitfall if done carelessly. Beyond that, it was a fun exercise and, although it didn’t take long to write, it was relatively challenging and — dare I say it? — fun!

I’m sure more the more experienced reader will see issues and possibly even errors with my approach. Again, I’m just starting out so, that’s to be expected. I welcome any comments or suggestions (assuming anyone reads this :D).

My next post will likely be about the beginning of the actual coursework and some small examples of the sort of problems/challenges I’ll be working through with that content.

Thanks for your time and interest!

Kelly

Show your support

Clapping shows how much you appreciated Bit Grease’s story.