tl;dr: Sometimes stereotypes are true.

I came across this rather excellent comic about how people see your resume depending on who they are and after glazing over it and appreciating it as one of my ~5-10 daily interweb funnies, I looked over it again and noticed that it's eerily accurate.

Positives

1. Has written a compiler or OS for fun.
   That'd be a yes.
2. Resume compiled from latex.
   Actually, from hand made xsl to latex. There was a time when I was all excited about single source publishing, so that's what I did here. Xml to html/pdf/txt. (Last time I checked the latex->html bridge was seriously lacking anyway.)
3. Contributes to open source software.
   Check.
4. Has written compiler or OS for class.
   Check.
5. Has blog discussing programming topics.
   You're here.
6. President of programming/robotics/engineering club.
   Nope.
7. Participated in programming/robotics/engineering contest.
   Nope.
8. Internship at Google or Microsoft.
   They know where to find me.
9. Has written non-trivial programs in dynamic languages (perl/python/ruby).
   Mhm.
10. Knows 3 or more programming languages.
    Right.
11. Previous position demonstrates similar skills.
    Not really.
12. Has internship.
    Has.
13. Founded a company.
    Only a pretend company, and we haven't been active for about 10 years.
14. Personal web page uses Rails, PHP or Asp.Net.
    Been meaning to switch from PHP to Python, but there's just no pressing need for it.
15. Email address at own domain.
    Not since 2005.
16. Has modified programs in dynamic languages (perl/python/ruby).
    That's how I started out with dynamic web stuff in 1999, found perl scripts and tried to mod them without breaking them.
17. Has personal web page.
    Welcome.
18. High grades, top of class, etc.
    Meh.

Neutrals

1. Won scholarship.
   Have never applied for one.
2. Lists job at fast food chain.
   Haven't had the pleasure.

Negatives

1. Looks kind of drunk in facebook picture.
   One of [apparently] few specimen in the human race who don't find unending ecstasy in alcohol.
2. Has Ph.D.
   Not so much.
3. Generic cover letter.
   Might be tempted.
4. Mentions skills in Excel/Word.
   Over my dead body etc.
5. Spelling or grammar errors on resume.
   My typing is a bit dodgy, but I tend to proofread.
6. Resume font too small.
   Let's hope not.
7. All programming experience in class.
   Nah.
8. Knows only 1 programming language.
   Once upon a time.
9. Resume more than three pages long.
   I try to make it in two.
10. Includes irrelevant objective section.
    Never knew what the point was of that one.
11. Took certification course in a technology.
    Never occurred to me.
12. Low grades in relevant courses.
    Nah.
13. Lists visual basic experience first.
    Don't have any.
14. Topless in facebook picture.
    Only by mistake.
15. Resume uses combination of tabs and spaces to indent sections.
    I'm clean, narc. (Actually, if you use Tab in vim with wildmenu, it's tricky to type a tab without a space first, because it will try to auto complete the current token. Haven't tried to fix that yet.)

Axiom: SRS is by far the most effective vocabulary learning method I've ever seen.
Corollary: There is no way I could have learned nearly as much vocabulary with my usual laid back attitude.

Don't get me wrong, I'm happy spending most of my life propping up the idea that "if a word wants me bad enough it will find a way to attach itself". It's modest reward for scarce effort and I like it that way. There is so much more worth doing in life than learning lots of words. But there are times when a quick uptake of vocabulary is pretty crucial, namely in the opening stages of a new language. It's when you put in a lot of effort and consequently, where seeing results matters a whole lot. But it matters not only for motivation. It also greatly impacts the quality of your early learning process if you can absorb the core vocabulary quickly.

I found this out last year when I was starting on Italian and I realized I had learned lots of not-all-that-interesting-but-important words that would have taken me several times longer without SRS. To my good fortune, I knew about Anki and I had read enough plaudits to try it.

Still, there is a problem. Anki may be effective, but I wouldn't call it fun. In fact, it's awfully tedious. So much so that even though I appreciate how helpful it is, most days I just can't persuade myself to click the icon that launches it. I get little thrill from returning to the same words that I saw yesterday and couldn't remember then. Plus the interaction itself is highly tedious; clicking those buttons like it's some kind of psychological survey, trying each time to pick the most appropriate choice.

Making it more fun

Alright, how? Khatzumoto writes about timeboxing and SRS tirelessly, and after reading through most of that I was ready to try it out. The idea is to go from "man this is boring, how much longer?" to "I only have 5 minutes, how much can I get done?" and it sounds like it's never going to work. And yet.. okay, have you ever stayed at a nice place on vacation for just a bit too long, so much so you get bored? The idea is to leave wanting more, it's basic showmanship. Timeboxing, believe it or not, adds that element of urgency to the mix. You give yourself 5 minutes for Anki and that means you only have 5 minutes, however many decks you have.

Yeah, it's weird. But here's what it looks like to me. Before timeboxing I would start up Anki, gaze at all the decks I have and all the cards that are up for review and sigh. "What a pain it's gonna be to review all that." Now, all of a sudden, I have a different reaction. "Alright, I have all these decks, which one do I most want?" Then I start on one and keep going for a while, but not for too long since I also want to cover other ground. The 5 minutes is almost up and I still want to get more done so it ends up being 7 minutes. 7 minutes,  which prior to timeboxing, seemed like a century of Anki.

Decks - how to plan them out?

You could just put everything in one giant deck, but I don't like that idea. I did that at first and I found out that I like to have some notion of the context where the information was from. Is it from a textbook, a vocabulary list on a particular topic, from reading or watching stuff (ie. passive learning) or what? That gives me a choice; I can pay close attention to some vocabulary set that's important right now. And if a particular deck is just annoying me I can remove it completely.

It's also a way to manage my morale. If I review lots of cards from a tough deck and I can't remember anything (ie. the thing that makes me unhappy), I can counter that with an easy deck where I win easy points.

The title is too vague and not very good. The subtitle is much better: Language as a window into human nature.

Go read it!

Dry and minute at times, but very rich. Don't get discouraged by the wikipedia page, it doesn't begin to do justice to the content between the covers. Neither does Pinker's google talk where he's selling the book and gives a superficial impression of it.

A non-exhaustive feature list:

• Why can you not interchange "give her a hand" with "give a hand to her"? Is there any logical explanation for these quirks? (Answer: yes. In fact, language is far more logical and far less arbitrary than we imagine most of the time.)
• Linguistic determinism. Is it really true that our language/vocabulary is the language of our thoughts, and thus it can empower/limit what we are able to think? (Answer: no.)
• Why do you say "the stars are out" when you can see them and "the lights are out" when you can't see them? (Answer: don't remember the explanation for this one, but it's a neat example, no?)

And so on. But Pinker doesn't just explain a whole bunch of riddles, he reaches deep into a whole range of topics, like how language routinely states time in terms of distance (and vice versa), how language expresses causation (and what this implies for our perception of causation) and many more such topics. In short, he does exactly what he's promised to do, he shows how language codifies our human nature.

If I never read a second book about linguistics, I still think this one will have been a pretty good choice.

If you're a coder you probably try to modularize everything to death on a daily basis. If not, your practices are a little suspicious. :nervous: Alas, it's not so easy to knock out something that I can say with confidence will be reusable in the future. One piece of functionality I keep reimplementing is output in colors, because it's hugely helpful to making things look more distinct. The first time I wrote this module I knew I would be using it again and I wished to make it nice and reusable, but I didn't know what the future uses would be. So I put that off until "later". In the meantime I copy/pasted it a couple of times into other projects. Shameful, but effective.

I finally got around to organizing these types of bits that have no specific place of their own into a new github repository, appropriately named "pybits". It holds the pretty printer and this rewritten ansicolor module, and it'll probably grow with the ages.

But to business. Anyone spitting out ansi escapes who has figured out the system knows it's trivial to make a color chart. So to keep the tradition going, here's proof that ansicolor is able to enumerate the colors:

Notice that section at the bottom about highlighting colors. As you might be able to deduce by sheer logic, black and white are not great colors for highlighting something in a terminal, because they are typically used respectively as the background and foreground of the term (or vice versa). (The colors of a term can actually be anything, but black and white are the common ones. Ideally, code should detect this at runtime, but I don't know of a way to check for this. Besides, lots of programs [eg. portage] do make this assumption also.) So the highlighting colors are supposed to be useful for when you want to output a wall of text and mark something in the middle of it, so the user can spot it.

Suppose you are (as I have been in the past) developing a regular expression and you can't get it right on the first try (yeah, unbelievable, I know). Well, what you do is highlight the string so you can see how the matching worked out:

Regular expressions tend to get hairy (yes way) so it helps to compare their results when you're trying to unify two half-working variants into one. Adding a second regex will show the matches from both. Where they overlap the styling is bold:

Think of the green highlighting as a layer of paint on the wall. You then paint a layer of yellow on top, but you don't cover exactly the same area. So where the green wasn't painted over it's still green. Where the yellow covered it, the paint is thicker. And where the yellow didn't overlap the green it's just plain yellow.

Adding a third regex potentially produces segments highlighted three layers thick, so there the color becomes reverse.

And then bold and reverse.

ansicolor doesn't support background colors, but that's a product of my use so far, I've never needed it. I don't think they improve readability.

You will find this cutting edge technology in the repo:

• pybits