Instapaper creator and former lead web developer for Tumblr Marco Arment on David Karp:
I’ve only seen one other “product person” as good as David, and that was Steve Jobs. (Believe me, there are many parallels.)
David has an impeccable sense of what’s best for Tumblr, and he doesn’t need anyone else telling him what’s best for the product. Many people, myself included, have tried to convince him to go different directions, and we’ve been proven wrong every time.
Tumblr is David, and David is Tumblr.
Kara Swisher for All Things D:
Done (just like we said).
As long as they got more than Instagram, I’m happy for them.
In all seriousness, though, I hope this gives David Karp and company what they need to make Tumblr as profitable as it is awesome.
An etymological excursion into every programmer’s favorite metasyntactic variable.
This is part 1 of an epic 4-part conversation Bill Venners had with Ruby creator Yukihiro Matsumoto in 2003 for Artima.
I still prefer Python, but I absolutely adore Matz’s philosophy of designing Ruby based primarily on how one feels while programming rather than merely what one can do with it.
Instead of emphasizing the what, I want to emphasize the how part: how we feel while programming. That’s Ruby’s main difference from other language designs. I emphasize the feeling, in particular, how I feel using Ruby. I didn’t work hard to make Ruby perfect for everyone, because you feel differently from me. No language can be perfect for everyone. I tried to make Ruby perfect for me, but maybe it’s not perfect for you. The perfect language for Guido van Rossum is probably Python.
His emphasis on what’s convenient for the human rather than the machine is also refreshing. One of my biggest frustrations with software in general is that it often caters more to my computer than it does to me.
[C]omputers don’t mind if I must make effort to communicate with them or if it is easy to communicate with them. They don’t care if I put the numbers of instruction byte sequences in a file and feed it to them to run, or if a very high level language generated the instructions. The computers don’t care. We humans care about the effort we pay. Often people, especially computer engineers, focus on the machines. They think, “By doing this, the machine will run faster. By doing this, the machine will run more effectively. By doing this, the machine will something something something.” They are focusing on machines. But in fact we need to focus on humans, on how humans care about doing programming or operating the application of the machines. We are the masters. They are the slaves.
A truly enlightening read. Links to the remaining parts of the conversation are provided below. Definitely worth a read if you are interested in Ruby or programming language design in general. Great stuff.
Cofounder of Vectera Mariusz Lapinski shares a sobering principle that he and his cofounders learned the hard way:
A solution is a something. But a something isn’t always a solution.
We pitched a cloud Matlab. We never backed it up with a terrifying experience using Matlab (we actually like Matlab). We just said we want to build a cheap alternative because Matlab is inaccessible now (the license costs $2k). We pitched something that we thought should exist in the world. However, we couldn’t back up that it was actually needed and still can’t. The sooner you realize that you are building (or pitching) a something, the better. That’s not to stop you from working on your idea, but just to find quick and honest validation.
Michael Hartl’s Rails Tutorial is the best Ruby on Rails intro I’ve seen. Free online with options to purchase a DRM-free downloadable copy and/or a screencast series that goes beyond what appears in the book.
I’m using the online version to learn Rails 4.0 and, being someone who has abandoned many tutorials, I’m eager to make it all the way through this one. Thoughtful, thorough, and engaging.