Hi. I’m Tim Mansfield.

# Treehouse review

Treehouse is a popular site for learning website and app development.

It can be a little hard to tell with these paywalled learning sites whether it’s worth investing in a subscription. You can try the freebie content, but that doesn’t necessarily give you a full view of what you’d get if you got past the paywall.

So to save you the trouble in Treehouse’s case, I got a trial subscription myself and whipped up a little overview of their Rails development “learning trail” for you.

The first thing to figure out is just what topics they cover, over how many hours of video playtime. Read on →

# visual proofs

Here’s a neat visual proof that builds on the formula for circumference of a circle to intuitively derive the formula for the area of a circle.

It visualizes a solid disc (the filled-in circle) as a bunch of concentric circles, each of which can then be cut and straightened out, forming a triangle. The area of a triangle is well-known to be half of the area of a rectangle, or $\frac{1}{2}bh$, so substituting in $b = 2 \pi r$ and $h = r$, we have:

This visualization hints at a different lens for viewing the world, through which you see a whole, static object being built up over many slices of time from many smaller parts. I.e., the lens of calculus.

Isaac and I went through this with pencil-and-paper, as well as physically cutting up some rubber bands. He seemed to understand the idea well enough.

I think we can expose kids to interesting ideas early on, as long as we take an intuitive approach, without getting too lost in a forest of abstract symbols. This approach introduces the larger theme that math is about exploring relationships, building up and discussing arguments about why things are, as opposed to being just about computing numbers so you can “get the right answer”, so someone will give you a good grade.

# the mundanity of excellence

I ran across a cool paper called “The Mundanity of Excellence”. It’s only 18 pages long, an easy read as academic material goes, and gives lots of concrete examples from a somewhat interesting domain (competitive swimming). Give it a whirl.

## Summary of the Mundanity of Excellence

1. Talent is way over-rated. What we call “talent” is often a post-facto observation of excellent results, muddling correlation with causation.

2. Magical performances are made up of a lot of mundane little pieces, each comparatively straightforward to pick up. (Not easy, necessarily, but not at all impossible for “mere mortals”)

3. From very early on, top-class performers do completely different things, within completely different circles, than average performers. It’s not like there is a giant ladder from “beginner” to “Olympic”. Instead, there are a bunch of completely different ladders.

4. People don’t become world-class just by being intense, working 10 times as hard as ordinary people. Top performers do work hard, of course, but not as hard as you might think.

So, in sum, a lot more people have the capacity for excellence than is commonly believed.

Let’s invert these points to illustrate the mistaken beliefs we tend to fall into:

1. Some people are born with great talent. I’m not born with great talent, so there’s no point in trying.

2. Magical performances are the result of great talent. I could never do that. So I’m not going try.

3. To try to get up to that next level, I will do more of the same-old, average things I’ve been doing.

4. Great performers get that way in part by working extremely hard. I can’t/won’t work that hard, so I’m not going to try.

You can clearly see that these points embody a dead-end point of view.

# An idea for checking your understanding of tutorial content

There are a lot of coding tutorials online – it’s very cool and inspiring, how much great material is available!

But – I have the impression that a lot of that material doesn’t really “stick”, for beginners.

So here’s one small idea: What if you converted the content of a given tutorial into a simple recipe format, and went through that recipe, trying to recall how they did each thing in the tutorial? Seems like it would be a quick and reliable comprehension and retention check. (Of course you could refer back to the tutorial as often as necessary.)

# SICP Exercise 1.10

I recently began reading through the classic MIT textbook Structure and Interpretation of Computer Programs. It’s pretty cool so far, although I’m come across serious criticisms of its pedagogy, and MIT itself abandoned Scheme/SICP in its CS program a few years ago.

Anyway, while I’m at it, I’ll post anything (mildly) interesting or potentially instructive about the material.

On that note, here’s…

# So you think you’re not a real programmer

As I talk to people who are learning to code, I keep running into misunderstandings about who “computer programmers” are, usually in the context of “Well shucks, I’m not a brainiac like those real programmers…”.

# Aug 23rd, 2013

There’s a lot of interest in “coding academy” camps . The basic story is that you are fed up with your current job and want to make a career switch into programming. In theory, you could self-study and bootstrap yourself into this new career, but it’s too slow going that way, and you’d like to fast-track your learning.

That’s where the coding academies come in. They typically take from 9 to 12 weeks, and are intense, full-immersion “boot camp”-style experiences. You learn programming basics, a bunch of tools, and build multiple applications that will then go into your portfolio upon graduation. Toward the end of the program, you also typically get varying degrees of placement help to get you into your first professional job, as a junior software developer. Starting salaries in major metropolitan areas tend to head north of \$80k right now, apparently.

# Matz talks about his beliefs (transcript)

In these modern times, we’re awash in technology. It’s becoming impossible to get by without it for even a single day.

# What we can learn from FizzBuzz

In programming circles, the “FizzBuzz” interview problem has become a famous chestnut, a “can you believe how many people can’t get this??!” kind of thing.

Here’s the FizzBuzz problem statement:

# Write a program that prints the numbers from 1 to 100.

# But for multiples of 3, print "Fizz" instead of the number.
# For the multiples of 5, print "Buzz".
# For numbers which are multiples of both 3 and 5, print "FizzBuzz".


Despite being a bit of an in-joke, this question does actually get used. I was interviewing a guy recently who said that when he was interviewing at his previous job, FizzBuzz was the only question that he had been asked (!)

Like many other standard questions that you should become familiar with if you are prepping for a programming interview, it’s not a bad idea to run through it just to make sure you can do it in your sleep, on the off chance that it comes up. It’s such a simple-looking problem, but it actually does trip up a lot of people, even professional programmers with CS degrees.

Beyond that, though, it can also be useful to study FizzBuzz as a barebones driver for exploring “Interviewer Psychology 101”. What are interviewers looking for?

Let’s look at what even a trivial “weeder” problem like FizzBuzz can reveal about that.

# Hey Jeff-san!

My friend Jeff was doing some business at his company’s Tokyo office recently, and asked me how to interpret the “-san” thing. He was wondering if he was being explicitly honored when he was called “Jeff-san”.

I told him, “Yes, they are revering you and all your ancestors.”

Then I said, “Just kidding.”

The tl;dr version is that that “Jeff-san” usage is completely normal and common, and as far as you should be practically concerned, it means nothing more than someone calling you “Jeff”.

However, there is more to it than that. And anyone who knows me, knows that I won’t just leave it at that. Why use 30 words when 3,000 will do?

So let’s unpack more of the nuances.