If a given interaction was declared a success, avoid analyzing it. Sure, there may have been one or more awkward missteps during the course of the interaction, but this is not the place to expend you focus. Focus instead on the other 50%, the failures.

Try to ascertain key points in the interaction that, if handled differently, would have a profoundly improving effect on the overall outcome of the interaction.

As your experience with social interaction improves, gradually increase the success-to-failure ratio.

Also, why couldn’t they have just followed the C# implementation of lambas from the start?

All joking aside, for those of you not interesting in going back and reading that post, I think the following can stand on its own.</ado>

This no longer seems weird to me. Maybe I’be gotten used to the idea, or maybe I’ve achieved a better understanding of why this is true. Internalized it, perhaps.

If I may take a stab at expressing it in words… And it’s my blog so I guess so:

All objects are instances of the Object class. Everything that has a name in ruby is an object.

Class.instance_of? Object # => true
Object.instance_of? Class #=> true

And furthermore:

Class.instance_of? Class # => true

What a lovely triangle we’ve discovered.

[edit] Make that a square:

Object.instance_of? Object # => true

f.kind_of? Foo # => true
f.kind_of? Object # => true

# so far so good... now let's get in to metaclasses

Class.instance_of? Object # => true
Object.instance_of? Class # => true

mind.blown? # => true

“Measure twice, cut once.”

Taken in the general sense, both of these nuggets of folk wisdom are applicable in a multitude of situations. But in a way, they contradict each other. Should I just go for it or should I mull it over first? Should I take the contemplative or impulsive approach? The thoughtful or the assertive one? Careful reasoning or intuition?

Like so many other interesting questions, the answer to this one is “Well, it depends.”

Obviously, if you have plenty of time to think about something, you might as well make use of that time to make sure you make the optimal decision, and if you have very little time, you have no choice but to react instinctively. But there can be other dimensions to the problem. For example, how difficult it would be to atone for a wrong decision. It’s generally a good idea to think long and hard before burning any bridges. Furthermore, some situations degrade over time, meaning the sooner you make the decision, the better off you’ll be, but you still don’t want to make the wrong decision under all this pressure.

Deciding between the contemplative and intuitive approach is in itself a decision that that can be made using either the contemplative or intuitive approach. And so can that decision. Sadly, it’s turtles all the way down.

So what can we conclude from all of this? Not all decisions can be made the way a computer would make them, or your stack will surely overflow. The best I can come up with is to develop a heuristic, play it by ear, and learn from your mistakes. Try to strike a balance between the two approaches. The contemplative approach is usually safer, but overuse it and many a golden opportunity will simply zoom past while you’re too busy in your own head. There’s a time and a place for noodling, but not when an attractive stranger is making eyes at you from across the room.

Never say “can’t” and never say “that’s a lot of work”.

Instead, say, “I’ll try” and just give a good effort.

I feel like the poster’s intent is noble, but the resulting advice is quite bad in certain scenarios:

Imagine your manager asks you to perform a task that she considers trivial.

1. What she doesn’t know is that the task will take quite a few hours to get right.
2. What you don’t know is that it’s of comparatively little value and your time would be better spent working on a new feature (see below), or perhaps streamlining your codebase instead of complicating it with bells and whistles from which your users will garner precious little benefit.

I believe the ability to collaborate openly on this sort of value judgment is something conspicuously absent from too many corporate cultures. Instead, programmers just throw their hands up as if to say “You’re the boss, so I’ll do whatever you want (as long as I get paid).”

This feedback loop must be especially tight for startups, since a startup must allocate its scarce resources efficiently if it wants to stay lean and agile instead of turning into just another enterprise with a lower number of employees and dollars. High productivity focused in the wrong direction is worse than low productivity in the right direction.

In case you run out of useful features, here are some ideas to get you thinking:

• Make the user experience as effortless as possible
  • Replace full pages loads with ajax for small changes to the page
  • Don’t make the user click twice when he only need to give feedback once. This isn’t the 90s, try to avoid wizards.
• Implement better abstractions of data shuffling mechanisms as simple, stateless web services.
• Improve test coverage. NB: simple, stateless web services are easy to test, which is even better if they’re at the core of your app.
• Add useful, organized logging. Your future self will tip his debugger’s hat to you.
• More detailed analytics. It’s like farming useful feedback from your users with no effort on their part.

Just a couple points for now.

¹Pointing out that I ended this sentence in a preposition is a prime example of crossing the insightful → pedantic boundary.

I’d like to add a few annotations:

An attacker can build up a huge dictionary of hashed passwords just once, and, when he breaks into your web site, check the hashes against this pre-built dictionary.

This set of pre-computed passwords is often referred to as a rainbow table. As the article stated, salting complicates such an attack.

But it’s going to be darn hard for you to find any other document, big or small, that hashes to the same 30 characters.

[...]

In fact, you can try something that should be easier: rather than find another document that hashes specifically to those 30 characters that represent your baby, you can go looking for any two documents that happen to hash to the same thing (collide). And you won’t find any such pair. Promised. We call that “collision resistance”.

More specifically, the first paragraph refers to weak collision resistance, and the second refers to strong collision resistance. If a hash function has the property of strong collision resistance, this implies that it also has weak collision resistance, but not the other way around. In some (most?) applications, including storing passwords, weak collision resistance is sufficient. So it’s worth thinking twice before throwing out your favorite hash function (SHA1) if (when) someone breaks strong collision resistance on it.

The following two, however, evaluate to False:
False is 0
True is 1

But Python’s in operator behaves like it uses == internally, so the following expressions evaluate to True:
True in [1, 2, 3]
False in [0, 5, 6]

The above result took me by surprise today. Since I consider this behavior a wart, I came up with a workaround.