Some notes from PyGotham (corrections welcome)

Getting Rich with Comparison Methods 

Matt Story

the truth of x == y does not imply that x != y is false […] Mind == blown and mind != blown.

pro tip: when defining ‘__eq__’ also define ‘__ne__’ its reflection method

operators like ‘<‘ have reflection properties to handle ‘>’ when overridden
right-side reflection for left-side method

how much of life is wasted by not reading documentation first?

python has a NotImplemented error. singleton constant

MRO –> method resolution order –> use the more specific class’s methods, regardless on which side of comparison
this is the reason to use mix-ins as opposed to normal inheritance

test ALL the things
import operator module to test all the cases for bitwise and arithmetic operators

eq, ne, lt, le, gt, ge – check for existence, return the thing or NotImplemented

@functools.total_ordering – may drastically reduce the code

comparison methods are well documented. fairly robust methodology to learn which method to use on right/left side. complex so need to test.

comparison methods do not need to return bools, so you can do whatever you want. harness asymmetrical and non-boolean comparisons… useful for lazy-loaded filtering, iteration

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!

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).