Code Every Day

One piece of wisdom I am taking to heart is Cory Althoff’s advice to code every day. As a creative writer, I know how important it is to exercise writing skills every day, including thinking like a writer. Therefore, I’m not surprised that for programming, the same ideas apply. Where I was mistaken was that I was going into programming with much more perfectionism, meaning I thought that I couldn’t sit down and write code unless it was going to be a very important and purposeful program, one that will definitely run by the time I was done.

When I sit down to write, I don’t write perfect, ready-to-publish stories or novels each time. I go through draft after draft, and aside from the actual writing, there’s a lot of thinking involved. It takes a lot of time to create something from nothing, regardless of the medium.

Now, I’ve been sitting down to code every day, sometimes by opening up a blank file in my IDE, or sometimes by working on old code. Some projects I’ve done more than once, but I’m tackling them in a different way. Regardless of what I’m doing, this method helps me learn with a more hands-on critical thinking.

It’s also important to have fun. Make something silly, something you think is cool just because. Have fun with it. Get something to work, even if it’s simple. Feel good about yourself. Sometimes it’s important to have fun amidst the learning to help us stay motivated and prevent discouragement. And, for me, I find it so fun to see how my learning continuously improves by repeating simple projects at different times.

There you have it! Code (and write!) every day!

Git and GitHub

When I first learned about GitHub, I thought it was just a website. It was very confusing and intimidating. However, I was told by peers the importance of GitHub for programming, and especially because I had found myself at a dead end during an early programming project.

I have a (somewhat embarrassing) first project up on GitHub (which is a perfect example of code that needs to be cleaned up–a fun idea for a future project). However, that first project from years ago was a great introduction to GitHub.

First, Git and GitHub are not the same thing. When I looked up “what does Git stand for?” I stumbled upon an interesting story. Git is actually not a meaningful acronym, instead it was chosen because it was most likely to never be used and mess up someone’s code. The story goes as so:  Torvalds created the software and named it after the British slang word, “Git,” which translates to “a rotten person.” 

GitHub is a website, a service, where people can collaborate and track the history of code. It’s a wonderful space for people to learn and grow. However, it is possible to be proficient in using just the GitHub website without actually working with Git through the terminal, and vice versa.

The goal is to balance usage of both Git and GitHub through the terminal and website. Prior to this post and day of studying, I had mostly just worked on the GitHub website and not the terminal. Having gone through multiple videos so far from the “Git and GitHub for Poets” video series by The Coding Train on Youtube, I’m more familiarized with working in the terminal with Git and GitHub. It’s been an interesting ride, and this is just the beginning!

Link to series playlist: https://www.youtube.com/playlist?list=PLRqwX-V7Uu6ZF9C0YMKuns9sLDzK6zoiV

Glossary of Important Terms

Here are some notes I took while watching the above tutorials. Hope you find them as helpful as I do!

Git: version control software

GitHub: web service where people can collaborate on open source code and track project history

Repository (or, “repo”): a project; a repository of files. Repository names can’t have spaces so they will include a dash as in: repository-title-example

Commit: a change to a file that is saved in the repository

Commit Hash: a unique identifier for each particular commit

Master Branch: original origin of a repository

Branch: a copy of files for experimentation before a commit is merged to the master branch

Pull Request: a way to ask the collaborators of a repository to approve your changes and merge them into the master branch

Merge: the action of a pull request successfully combining changes into the master branch of a repository

Fork: copying the repository to have under your own account for experimentation without effecting the original core version

Issues: a place to leave a comment about a problem, or to ask a question. Raising an issue means to file a potential bug

Fixes: if you use the word “fixes” in a commit changes title, the issue will be automatically closed

Remote: duplicate instance of a repository that exists on a server. When you say “git push” you need to say “git push __where__”

*Tip on Commit Hash Codes: place the commit hash code in a comment to help link to the issue

Terminal Instructions (via GitHub):

to create a new repository on the command line:

echo "# terminal-practice" >> README.md
git init
git add README.md
git commit -m "first commit"
git remote add origin https://github.com/KIBautista/terminal-practice.git
git push -u origin master

 to push an existing repository from the command line:

git remote add origin https://github.com/KIBautista/terminal-practice.git 
git push -u origin master

Practice Progress

After some trial and error, I was successfully able to push a new file into my GitHub repository through the terminal. It was very cool to see it work! I ran into some trouble shooting errors with getting into the proper place on my desktop for the repository, and for getting the remote to work, but finally, it has worked!

I found trying to change my login information through the terminal to be a little convoluted, and I was worried that an incorrect password was the cause of my push updates not going through. However, seeing my text file successfully added on GitHub through the Terminal confirms that the password and login is correct.

I feel more confident now to look around on GitHub for open source projects and contribute to them, which is the goal!

For anyone wishing to learn more, the video series I have found to be incredibly helpful is available for free on YouTube, and it is called “Git and GitHub for Poets” by The Coding Train. I very much appreciate the depth and visual interface used in this videos; they’re very user friendly and great for beginners!

Beginning Python – Course Completed!

A few months ago, I tried a free trial of Team Treehouse and then signed up for one of their basic subscriptions. The subscription let you enroll into a learning track of your choice, and I wanted to start with Python. The Beginning Python track is 9 hours long, but it took me a few months to complete. However, today–right now, I have finally passed a major milestone in my Python learning journey!

Team Treehouse Impressions

As a complete new person to an overwhelmingly intimidating field, I really loved the clean interface and design of Team Treehouse. The videos all seemed to be professional produced as opposed to well-produced home videos from other sites.

At first, even though the quizzes were a surprise, I was really happy to have them. The quizzes were also intimidating, but it helped my brain learn how to comprehend the lingo of this new realm. Also, the payoff of correctly answering a quiz question when you think you’re lost was a nice additional motivator.

Later on in the course, I quickly realized that different teachers teach different subtopics in each track, and some include different quiz methods and teaching methods.

Quizzed Out

Since I’m a stay at home / work at home mother, after a while, the quizzes were a really big disruptor in my learning process and time management. I don’t have the luxury of uninterrupted time or much quiet space. So, sometimes I want to be able to power through retaining as much information as I can during my small gaps in free time. During those moments, I was very frustrated to have a three minute or four minute video followed by multiple quizzes (sometimes five quiz questions / challenges back to back).

I should probably mention that I have years of analyzing my own personal learning process, because before I taught college I had to learn how to teach, and before I could learn how to teach, I had to learn how to learn.

I’m a visual learner. I also tend to have “bursts” of energy or “pockets” of moments where I am ready to dedicate hours to a task or subject. This trait of mine made me and Team Treehouse’s pacing very off-putting after a while

This could also be partly due to the fact that since I’m self-learning, I have my toes dipped in a lot of different areas. Some books I’ve read are ahead of the beginner tract, along with some of the projects I’ve accomplished, yet still a lot of it is new. Moreover, through my troubleshooting and projects, I’ve learned that those are my quizzes. Those stick in my brain and motivate me more.

Moving Forward

I don’t mean for this post to come off as if I am completely hating on Team Treehouse. I really do think that they’re a fantastic resource, and their videos have helped me a lot. As a new beginner, I’m happy that I chose this platform because the quizzes were strict and did help me persevere through some frustrating challenges (which I’m sure is the point, to mimic the life of a developer!).

However, for myself, I have decided to take a pause in my membership with Team Treehouse and move on over to try Udemy.

Udemy Impressions

First, I love the freedom of Udemy. I can skip forward in a course if I want and from what I can tell–there are no quizzes! I will say that Udemy is more attractive to me now because I am more experienced in this realm and have already personally decided to stick with this learning journey. However, if I was a new person and unsure, I think that Udemy’s platform could be potentially intimidating and perhaps give new students too much freedom to get in over their head.

What it really comes down to is personal preference and situation. For my personal situation, I’m excited to have the freedom to be able to utilize my time as best as possible, at my own speed. That will be a big plus for me!

Onto the next goal!

“Hello World: Being Human in the Age of Algorithms” By Hannah Fry

What an awesome and important book for this modern age! Definitely a must-read for current and future generations, regardless if you’re in the tech field or not!

Firstly, what I love best about this book is that it is a way to learn about how algorithms and code is used in the real-world, but it doesn’t try to teach it to you on a technical level. (Shoutout to my childhood best friend who read this book with me for our little book club!) I add that also because that is precisely why this book is awesome. It doesn’t matter your technical level of understanding, anyone can enjoy and learn from the examples and questions Fry explores in this book.

The table of contents lists the chapters as follows: Power, Data, Justice, Medicine, Cars, Crime, and Art. Each chapter describes specific real events that have occurred in each of those fields in regards to code and algorithms. Some key phrases I learned about were: machine learning, Burgess’s Method, random forests, neural networks, and Bayes’ Theorem. I don’t know how long it would have taken for me to reach the specifics of those topics in my own technical studies, but I’m very happy to have read about them and how they are applied to the real-life situations that have already occurred.

Let’s talk about the Cars chapter.

A couple of months ago, me, my husband, brother-in-law, and sister-in-law were sitting outside underneath the gazebo, talking about self-driving cars. My husband is a technological virtuoso and already had an understanding of how self-driving cars worked. I did not at the time, and neither did the rest of us.

However, my in-laws were both excited about the future prospect of self-driving cars. Fry mentions early on in her book the misconceptions people have when it comes to technology, and how most people tend to over-estimate the capacity of algorithms. This is true when it comes to the topic of self-driving cars because of the amount of people who are willing to put their lives in the hands of a self-driving car. Before reading Hello World, I was on the fence about my stance on self-driving cars. Now, I feel confident that I would much rather be in control of my own vehicle, and I’ll be sure to pass on that lesson onto my daughter (dramatically, of course, as if we were in a post-apocalyptic sci-fi movie).

From the start, my husband was against self-driving cars. But I should have seen that coming since my husband finds an automatic transmission as already too much interference (ha!). Point blank, he said: he did not trust a computer to make life-saving decisions. Back then, I greatly underestimated my own driving capabilities while over-estimating the accuracy of our current algorithms.

Without diving too much into the specifics, anyone who is interested in the idea of self-driving cars should read this book.

The Air France Crash of 1983 specifics are haunting enough to warn me that maintaining skills that involve our lives are mandatory as we advance with technology.

One of the largest take-aways I have from this book is that as humans advance, we need to make sure Wall-E doesn’t become a reality, to put it plainly. Essentially, we cannot let automation equal future generations loosing necessary skills, and thus begin a regression in the human species by relinquishing power over to algorithms and machines.

We need to remember that the smartest computer in the world is still the human brain.

Cue segue.

Let’s talk about the Art chapter.

Towards the end of the book, I could feel the fire in Fry’s writing, with impactful moments that definitely earned a mic drop.

One thing we have to remember about our humanness is our ability to feel. Our ability to feel, possess, and express emotions. A machine cannot contain emotions or feel them. A machine can mimic the expression of emotions through various tactics but it cannot feel. And that is what makes us human, and we need to remember that there is high value in the unquantifiable aspects of our humanness. This is why art is important, and why the creation of art can be mimicked by machines but it won’t (in my opinion) contain the same magical aspect that comes from art by a human. The art chapter and the way Hannah Fry explores this topic was definitely one of my favorite moments of the book!

I’m extremely happy to have read this book at this stage in my learning journey! My knowledge has been greatly broadened and now I feel as if I have a great starting point for further research into how code can and should be applied to our lives in the future.

In my opinion, more books like this need to be written as technology continues. By the time my toddler is in her teenage years, I’d want her to read something like this so she could understand the world she lived in, and how to progress in the future with technology as a smart assistant, not a catalyst for human regression.