The first week was a gentle introduction to the programming world. The instructors gave lectures on how to pair program (more on that later) and on “how to Hackbright”. They emphasized trusting the process and the curriculum, being kind to yourself and stretching your intellectual boundaries.
Much of this week was a review of things I had studied on my own through Codecademy, Zed Shaw’s Learn Python the Hard Way and O’Reilly’s How to Think like a Computer Scientist.
It was invaluable to have seen some of this material before starting the fellowship. It was like visiting a city you love for the third time. You’ve seen all the touristy things, so this time you can dig in on the local spots and appreciate the city for its details.
Seeing Python before and understanding how to use the command line also helped me focus on things I hadn’t done before: using Git & Github and understanding how computer memory works.
Having a properly organized and professional Git repo for projects is a must - for employers who will be looking at your repository, for other developers who will be looking at your code and for yourself.
One basic principle for many coding languages that blew people’s minds was return vs. print.
Ultimately, print is for people. Return is for the program. If there were no people, there would be no reason to have print statements (the instructor may have said something along the lines of “That would be an ideal world.”)
One thing I didn’t get to dig deeper on is the concept of lambda functions. Taking some time to review, they look pretty useful for writing clean code when you need an anonymous function that will be used only once.
Other concepts that were great to cement understanding are just how interestingly Python is designed. As an example, for loops in Python know what you’re iterating through (such as a list, dictionary, etc). In JS it’s a bit more explicit IMO, since you have your initialization statement, a condition to check and a statement to run at the bottom of the loop:
In Python, you just have:
This introduced the idea of writing “Pythonic” code, and I see it all the time now. Your code might work, but it may not be using the syntax that makes it pythonic.
Being able to unpack lists is also something that comes in handy and makes for cleaner code. Rule of thumb: if something is iterable, you can unpack it.
How computer memory works completely blew my mind. The difference between checking equality (==) and checking identity (is) was a helpful concept to learn, too. Two variables may have the same value, so checking a == b may come out to True. But, the values of a and b occupy different spaces in memory. Crazy, right?
Comprehensions are something I hadn’t seen much of before. They are another example of pythonic syntax and allow for fun ways to cut down on lines of code. That said, for now I find it preferable (and clearer) to write out what the comprehension is representing.
