The first class introduced pseudo code, which basically explains an algorithm or series of steps you want to code, in plain English. In the pseudo code, the basics of code were introduced. A variable was incremented, in a loop, as the code counted the number of people in a room.
A different video in the same lesson set taught me about binary and base 2 numbers. Like most people, I'd heard of binary and had a general idea what the word meant. This taught me how to add in binary, which was pretty neat.
The binary concept was used to explain bits, which in a computer is represented by turning transistors on and off. I learned how alphabets and other keyboard characters are broken down into binary bits. This led to algorithms. The instructor practically started with the problem solving algorithm of dividing a problem set in half. You know immediately if Mike Smith is in the first or second half of a phone book you've opened. If it's not in the first half, you can discard or ignore that section. Your problem is now half the size. You repeat, opening the remaining section to the middle, and immediately can tell if Mike Smith is in the first or second half. Repeat until you find Mike Smith. This concept was only introduced after several hours of instruction in the MIT course I started watching a few months ago. I never finished that course. Already I find this course more engaging.
Another tool I've found and have started playing with is Learn.code.org. I have not had the most positive experience with a GUI (Graphical User Interface) method of teaching code. I used a GUI program called Alice at U of Pheonix, but didn't feel I walked away with any real coding knowledge. Learn.code.org gives you the graphical interface, but you still have to build the coding sentences. You can also see the actual JavaScript underlying the building blocks you're putting together, which was not an option with Alice.
I completed the first section of Learn.code.org, where you build simple code snippets to move Angry Bird and Plants vs Zombies characters through a maze. Move Forward, linked to Turn Right will move the character forward once then turn it right. Add these into a Repeat loop and the character will Move Forward, Turn Right, Move Forward, Turn Right as often as you tell it to repeat. Ultimately you get to a point where you're telling the game, "if you have an open path, move forward, otherwise turn right. If you cannot then turn right, turn left. Repeat until you reach the goal"
I like puzzles, and have a knack for seeing patterns. If I can think of coding in that light, maybe I won't struggle as much as I have while considering it a new language.
Every Thursday at work we have what they call Lightening Talks. They are an hour's worth of 10 minute talks on just about anything. I've heard they had a talk on how to tie a bow tie, on how to survive the apocalypse. Today's talk was about the Code Mash conference held in Sandusky last week. A lot of the material washed over me in a "hope some of this sticks" manner. I do try to take notes on the things that interest me, and today's notes are on Ruby Warrior. Like the Learn.Code.org, it's something of a puzzle that you use the Ruby language to work your way through. I'll be spending some time on this site, working on improving my Ruby coding skills.
I've also been thinking about the reading I'm not doing. Why are there so few hours in a day?!? I've been avoiding "How to Think Like a Programmer" and "Clean Code" because there's code in those books I'm afraid I won't understand. I want to get the difference between functions and methods straight in my head before going there. At the same time, How to Think Like a Programmer is supposed to teach me the problem solving skills I’m hoping to find in the Harvard course. I have to ask myself the same question I asked about my art: "What would I do if I weren't afraid?" The answer is, read the books and teach myself what I need to know to understand them.
 |
| Reads "Adventure Girl" in binary. |
No comments:
Post a Comment