growing a pair

[JS] Functions and Codecademy

This chapter focused on functions. This was a relatively simple chapter that I got through pretty quickly. That’s not to say I’m a master of functions, but as far as understanding the concepts goes, I think I got it pretty well. 

I met with a professor at Penn earlier this week to talk about alternate (the product that I’m working on / incentivized me to understand programming better), and he made a good point of how all students learn by analogy. It’s rare for students to learn without connecting the content to something they already understand. 

In this circumstance, it’s really simple to connect functions to all the math classes you’ve taken in high school. One of my professors loved getting us to think out of the box, and in so doing, she had us create functions of our own. For example, we could create some function, x|y, that could equal 2x + y - x^y. In JS, you have to define functions the same way (except, obviously, defining those functions gets a little complicated when you’re writing them in code.) Fortunately, though, once you understand what the functions are representing conceptually, writing them makes a lot more sense. 

A few things I’ve been confused about are the difference between show() and return(), methods by which people write more complicated functions within functions or things of the like from scratch. I’m understanding the code, and with guidance, it’s making significant sense, but it’s tough to fathom writing this stuff from scratch. I’m guessing that’s why most of the programmers I know love open source code and use Quora/Stack Overflow to build their products. 

Another thing I found really useful was http://codecademy.com. Anyone reading this blog has almost undoubtedly already heard of them. Right now, Codecademy only has a few lessons of JS up, but in a very short time, I went through a lot of action items. I think this is an awesome start to get programming for a noob, particularly because it jumps straight into lessons instead of dwelling too much on theory. 

I definitely think learning theory is important, but it’s easy to start learning theory, get bored, and let the entire learning process go. Codecademy gets you straight into producing some programs (well, kinda) and laying the groundwork of some of the basic functions you’d be using in JS. It’s definitely a great start, and I’d probably start with that before even getting into Eloquent Javascript.

A tip I would definitely give to anyone starting to learn how to code is to not dwell too much on a particular exercise. As I move forward, I realize that it’s discouraging when you can’t work your way through an exercise. Letting yourself get stuck is dumb. Try working through it, but let yourself just look at the answer, copy it character for character in your own console, and understand what exactly is happening, then just go on. Getting stuck will just discourage you from continuing the learning process.

Day 2 - 4 of Eloquent Javascript

Full disclosure: Thursday was my birthday, Friday was full of meetings (with developers, so not completely unrelated), and I was in Boston over the weekend. I did, however, spend my entire car ride to and from Boston running through values, variables, and control flows in Javascript. That said, I have neglected Ruby a bit, but I’ll be back on that after this blog post. 

———

Variables, however easy they may seem, are a pain in the ass. I think this happens to be the case with my relationship with most things in programming. They seem so easy on the surface. Then you get close to them and they bite you in the leg. Funny enough, that happened on my birthday with a dog that looked like Lassie. Then I got bit in the leg. That was PLEASANT. 

I learned about numeric values, which was reasonably simple. Then started focusing on strings, which are basically variables with text values. That got a little trickier, especially because I needed to understand escape operators (I think that’s what they’re called), which are essentially backslashes you use in conjunction with other inputs to indicate new lines, tabs, quotation marks, etc. in a string value (e.g. http://cl.ly/9Jco)

Learning about different operators was also really helpful when working with boolean values that indicated truth/fallacy of different statements. They get trickier to remember as you get to == (equals) and === (equals precisely; because ‘undefined,’ 0, and “” are == to each other, but not === to each other), && and || are also tricky to use when you’re creating a program from scratch. 

What got the most tricky for me in this chapter was redefining values by using the same variable name. That is to say, if you define var Debt = 50 and later go on to say that Debt = Debt - 25, you now make Debt = 25, but unless you have a good vision of what’s going on in your program, that can get boggling (not quite in that example, but as the programs get bigger). 

What I noticed more than anything is that programs are MUCH easier to understand than they are to build. I guess that’s true of any work. You can read Dickens but not write like him. As I started getting into exercises in the chapter, particularly where I had to define loops, their beginnings, ends, and constraints on them to produce a very specific output, it was totally logical to me when I went through examples of loops. The second they gave me a situation and I had to write the loop from scratch, it got super confusing. I would be staring at my computer writing totally dumb arguments in the JS Console for a good 20-30 minutes to figure out how to get the output of 2^10 or how to draw a triangle of number signs. 

On the whole, understanding loops, variables, and whatnot is critical to actually getting things working in JS. Particularly cool was actually seeing stuff that I’m used to seeing on the web work on the browser (like creating a prompt screen that asked me for an answer and giving me responses based on my answer), but I know this is just the beginning. There are another 13 chapters of this JS book, and if understanding just the first two chapters is exciting, I can’t wait to see what the next 13 have in store :).

Again, sorry for being MIA (to my 0.5 readers), but I’m going to be more accountable moving forward.

Day 1 of Eloquent Javascript

Haverbeke takes a pretty different approach to teaching programming. He spends the first chapter (of 15) explaining the history of programming and what exactly programs are: 

A program is many things. It is a piece of text typed by a programmer, it is the directing force that makes the computer do what it does, it is data in the computer’s memory, yet it controls the actions performed on this same memory. Analogies that try to compare programs to objects we are familiar with tend to fall short, but a superficially fitting one is that of a machine. The gears of a mechanical watch fit together ingeniously, and if the watchmaker was any good, it will accurately show the time for many years. The elements of a program fit together in a similar way, and if the programmer knows what he is doing, the program will run without crashing.

He goes on to teach how code has evolved from 0s and 1s to operations like what we have in JavaScript (commands calling for specific actions) to even more advanced JS that has grown with its use to include specific operations (i.e. print(sum(range(1, 10))) calls for an output that is equal to the sum of all numbers from 1 to 10. Pretty self explanatory, but that’s not at all what that code would have looked like five or ten years ago. 

I have a good feeling a lot of this book will be significantly more theoretical, but that’s okay, as I should understand that as well. I’ll be honest in saying that I gave this book literally 45 min of attention to this point (was at an event from 8am - 3pm and was busy with some other work until now), but I wanted to make sure I got a blog post out. I’ll probably spend another 2 hours or so on it later in the night, but I’ll include lessons learned from that in tomorrow afternoon’s post. 

Also - I have a pretty long (1800 word) post about how to assess the value of a business guy in an early stage startup (as we don’t have portfolio of weekend hack projects or designs, so it’s harder to judge). If you wouldn’t mind, I’d love it if you could let me know how I should post that, as I don’t think it would be too valuable for me to post all 1800 words at once. It’s broken down into 9 criteria, so I could split it nicely if that’d be best. Tweet me and let me know what you think would be best.