100 Days later

How to Git good

TL;DR: To get better at something, practice. To form a habit, commit to do it often.

This is a story about challenging myself to get into a good habit.  About a hundred days and a week ago, I started Hacker School.  The first day there, I learned how to use GitHub.  That same day I decided to commit to committing, as part of my quest to become a drastically better programmer.

i think everyone spending a day learning to github would make a bigger impact on the world than spending a day learning to code

— Aidan Feldman (@aidanfeldman) January 15, 2014

A week later, I realized that I messed up my streak, by forgetting to commit over the weekend. Doh!

Final stretch

There are only a few weeks left of Hacker School, so I’m making lists.

Accomplished two of my goals:

1. contributed to Open Source: paired with Stefan Karpinski on an open Julia issue (pull request)
2. attended a hackathon (internet glory!)

The projects I will continue to focus on (in no particular order):

1. foodGrades: NYC Open Data analysis of restaurants violations and food poisoning
2. neural network to distinguish English vs Spanish sentences
3. sayWhat: continue to work on political bill complexity and phrase analysis, using the Sunlight Foundation APIs

Online courses I will finish:

1. Coursera: Machine Learning
2. Udacity: Web Development

How hackers learn… (for fun_and_profit in life):

Perhaps the most interesting thing I learned so far in Hacker School is that you should design learning like you design code.  This was inspired by a presentation that Mel Chua gave to our batch.  It’s a very powerful idea that I feel is worth exploring, analyzing and sharing.

In this post, I will attempt to cover how and why programmers learn, how they design code and why everyone could benefit from adopting the “design to learn” model.

Why developers learn:

In The Dark Knight, the Joker said, “If you’re good at something, never do it for free”.  Programming can be a very profitable career choice.  So it’s safe to say that some developers do it for the $money.  They understand the supply-demand curve of market economics.  To most people, computers are highly useful magic black-boxes of awesomeness, so those who wield the power to create and control them are wizards.  Mastering a language, technology stack or project implementation yields great rewards when those skills solve real-world problems.  Just imagine how much XYZ Company will pay for a level-60 Java wizard!

1. Learn to code
2. …
3. Profit

But what about software engineers who aren’t in it for the money? Their motivation is probably a bit more interesting and complex.  For some, it is the autonomy and creativity of creating novel code.  Or maybe it’s the competence felt when basking in the praise of technophobes whose desktops always need rescuing (Mom, I promise I’ll fix your Internet as soon as I get some free time).