Objections to Blockchains remind me of objections to Git

On the HN thread.

It’s just really hard for people to see beyond the present. Innovators in one cycle are often blind to the opportunities in the next. I see it in a couple of my successful friends that built their own companies on the web and mobile when it comes to crypto.

I’m reminded of the quote about the radio:

“The wireless music box has no imaginable commercial value. Who would pay for a message sent to no one in particular?” — Associates of David Sarnoff responding to the latter’s call for investment in the radio in 1921.

And then a couple of years later, for someone that made their stake in radio:

“While theoretically and technically television may be feasible, commercially and financially it is an impossibility, a development of which we need waste little time dreaming.” — Lee DeForest, American radio pioneer and inventor of the vacuum tube, 1926

And remember TV didn’t really come into its own until decades after 1926.

Yesterday, I was reading about past objections (circa 2007) to using Git vs CVS or SVN, and most of the objections were things that turned out to be unimportant. The objections focused on how their team doesn’t have a decentralized workflow that the Linux Kernel does, so they don’t need git. Or that the interface sucked, so they don’t need git.

Turns out everyone mostly uses git in a centralized way (via Github), to coordinate, but the decentralized design reveals secondary affordances that are really useful in practice. The decentralized design allows you to work and commit offline–great as laptops became more pervasive and more people worked on them. (You use to have to be online to commit, and can sometimes take minutes) The decentralized design also used content hashing with parent chains, which allows for inherent self-checking–no object modification can escape detection. Git’s data structure makes commits fast, which in practice makes fine-grained commits possible. And the decentralized design gives everyone a backup of the repo, so the central repo getting nuked by the intern doesn’t take down the org. Nowadays, in saying these things, I’m preaching to the choir. But back then, it was completely non-obvious.

The only people that got it right back then are the ones that dug into the technical details, and then actually tried it out. Notably, the guy at X.org.

And I think it’s a similar thing with cryptocurrencies, in the way that the fundamental different design and architecture of blockchains allows for secondary effects that are harder to see (until you’ve actually used or programmed in it) that aren’t available to you at all otherwise.

The trap most people fall into is that they compare the new X with what the old Y does very well. But they never consider that if it’s actually got a new underlying concept, it might suck at what the old Y has had time to get good at, but it allows for some other thing that we just couldn’t do at all before.



Marginal Cost vs Full Cost

Fallacy of marginal cost when making decisions only applies when a fundamental shift has occurred. If no shift has occurred, making decisions solely on the comparison of marginal cost works.

That means when it comes to leveraging personal skills and connections, you should double down on what you’re good at if something fundamental about the environment hasn’t changed, whether this environment is distribution, relationships, technology, culture. But when it has changed, you need to take a deep breath and fully retool, and allow yourself the time and the mindset of a beginner in order to make the transition. That also means you need to save the money and create the environment so that you can do so.

How to tell if something fundamental about the environment has changed? It helps when you can extract the concept of something from the concrete something. For example, lots of front end frameworks proliferated in 2013, so lots of people felt like they couldn’t keep up. So they threw up their hands and would joke only the cool kids knew something new. The only way they could judge something was if it was new. You should only learn something if the underlying concept is something new to you. Concepts are an abstraction or generalization of how something works.

That’s why learning about something’s concept will go a long way. Knowing the how’s and whys of something, and finding a generalize-able abstraction will help you recognize shifts, so you can better make decisions in a changing world.

Working on a Personal Relationship Manager

I got asked if I wanted to work on a Personal Relationship Manger. I politely declined, and wrote the reasons why:

On the technical side

if you’re going to be writing something to help do relationship management, it’d better be really constrained and focused in scope. Because we often use umbrella terms to mean different, but related things, it’s really easy to build assumptions into the software that doesn’t serve large segments of your users. For example, we built Noteleaf to cover ‘meetings’, but the workflow we had only meant to cover ‘coffee meetings between founders’. We had all sorts of people sign up for it that we weren’t built for, since they saw ‘meetings’, and thought it applied to them. As a result, we got a hodge-podge of user feedback that we couldn’t decipher at the time, because it was actually different segments of users having completely different needs and jobs to be done. That’s not to say it can’t be done in the near future. DNNs may be able to handle all the different variations of ‘meetings’, but that’s mostly just hand-waving on my part, than anything concrete.

On the business side

Most people don’t care enough about managing their personal relationships to pay for it, and hence, it’ll be really difficult to build a business on top of it. That’s why most relationship software are CRMs, as businesses care alot about knowing who their customers are and what they’ll buy. On the flip side, the closest we come to a personal relationship manager is facebook and other social networks. And even then, it’s not so much about the management (managing is work…no one want to do work), but getting news (pictures and text) about their friends. It seems like there’s a new social network about every 7 years or so. AOL IM ~1997, FB 2004, Instagram 2010/Snapchat 2011. 2018 might be ripe for another one. I’m not sure if it’s because teenagers don’t like being where the adults are or what, but that seems to happen. If you want to work on something related to personal relationship manager, I’d work on a new email (search for DotMail). People get tons of email and really hate their email client, and are excited for something that works better. You should really understand why people use email (i.e. people use it as a todo list rather than point to point messaging, or people use it to transfer files between their devices). before attempting it. However, be forewarned that email protocols are old and shitty to work with. It’s a lot of work to get something basic up and running.

How to take apart the Panasonic Toughbook CF-W2

From the archives. Good thing for the Wayback Machine.

1. 1 screw inside the CD/RW unit underneath the cover on left. Do this before you power down the unit. Otherwise you will have to force open the drive from the bottom.
2. 2 nut screws on the VGA connector on the top left side.
3. Take the plastic cover off the Wireless antenna near the Intel logo on the right side of the unit by prying the cover loose. Remove 2 screws at side of antenna.
4. Turn the notebook over.
5. 7 screws at back. Make a note of the screw positions in a piece of paper, since there are 3 long and 4 short screws.
6. 1 screw for the Memory Cover
7. 3 long screws holding the Honeycomb cover, next to the memory slot. These screws hold the keyboard.
8. 1 inside after the Honeycomb cover is removed.
9. Turn the unit over. Open the lid. Push The keyboard up from back under the battery. The top part comes up. Now lift up the keyboard. Pull the ribbon out underneath the TOUGHBOOK Sign. Unclip the ribbon from the unit very carefully.
10. 2 silver screws on inside just above the logo Intel Centrino under the keyboard
11. 6 black screws under the keyboard
12. Now close the lid and turn the unit over.
13. 4 screws holding the LCD Hinges at back (2 Screws each side).
14. Now slowly pull the back cover up.

Writing copy is like drawing a comic strip

Once, I remember reading that a cartoonist said that the important part of drawing a comic strip is not actually what’s in the panels themselves, but the space between the panels. The pictures that you draw are, in fact, just bookends and anchors to your readers’ imagination. If the reader can’t use your anchors to make the transition to the next panel through the use of their imagination, then you’ve failed as a cartoonist.

This is something we as comic strip/comic book readers tend not to notice, especially when it’s done well. It’s only glaringly obvious when you can’t follow the dialog or the action due to confusing camera angles between one panel to the next or a bad panel layout.

So it is with copy on your website, or an HN title submission. Like panels on a comic strip, copy is the anchor which you bookend your visitor’s understanding and imagination. If it’s not something that stirs their curiosity, or even better, their sense of imagination, then you’ve failed to carry them from one step to the next.

And as it is with a comic strip, you can’t be overt with the copy, nor should you lie to them. That’s when people get irked and call things link baits. When done right, people don’t even notice at all.

Knowing yourself

When I was younger, I often heard the phrase, “Know yourself”. I didn’t quite know what that meant. At the time, I thought, “Of course I know myself. I know that I like vanilla ice cream.” It wasn’t until I was older that I figured out there’s more to those two words.

What’s so important about knowing yourself? For one, at many points in your life, you’ll have to make decisions about your life and the lives of others. Should I take this job or should I work on this idea? Should I marry this girl or should I try to find another? Should I be the whistleblower or should I protect my family? Making these decisions is tough enough, as you oftentimes have incomplete information, your own biases, and peer pressure of others to mask you from thinking clearly. Knowing what you value will help make the decision process easier (though justifying it is another topic altogether).

In addition, the world has many different types of people in it that value different things. One way or another, they’re going to try to impose, coax, or try to convince you of their values to achieve their own goals. This happens with advertisements to buy a product, when someone asks you to go into business with them, or to go on that trip to Thailand. When your goals are aligned with theirs, then alright, high-fives all around and let’s execute. But when you are unsure of your own values, it’s easy make choices for yourself that are not actually aligned with your values. When you have a lack of alignment between your actions and your core values, it contributes to a lack of control in your life, which contributes to happiness.

So what should you know about yourself? I’m specifically talking about what you value, though Values is an often overloaded term. In this context, I mean it as not simply what you think is important, but the relative prioritization you’d give of one over another. If I asked you whether you value security, you might say ‘yes I do. I like knowing I’ll have a job next year’. And if I asked you whether you value progress, you might also say ‘yes, I like how technology moves forward to bring better standards of living’. But when security is pitted against progress, which would you choose? What if in order to make technological progress, old industries and markets disappear and people lose their jobs? What if it was your job on the line? Some might not find that decision so easy.

How would you go about discovering your prioritization of values? One way would be to take every combination of values and pit them against each other in an either-or contest. I did this exercise once, and it was not only tedious, but also relatively inaccurate. We have a tendency to lie to ourselves because of who we’d like to be (or who others would like us to be), rather than who we are. What we say is oftentimes not what we do.

How do we look at what we do in an honest light? One way is to put yourself in stressful situations and see how you react. We often don’t know what we’d do in a situation until we find ourselves in that actual scenario. You want to put yourself in situations where you are a bit intimidated but not in completely over your head, doing things that may be uncomfortable but will ultimately lead you to stretch yourself. Sometimes, we’re surprised by our own courage, acceptance, or kinkiness. Other times, we’re disappointed by our cowardice, lack of confidence, or our spitefulness.

When I finally connected the dots, I realized that’s why people choose to backpack around Europe or SE Asia. It’s an opportunity to put yourself in new and stressful situations where you don’t quite have all the solutions and will have to react to new situations. That’s how you find out whether you are okay flying by the seat of your pants or whether you like to have a plan; whether you’re too trusting of strangers or not quite trusting enough.

I see people miss this point all the time when they cargo-cult others’ path of self-exploration. I had a friend go to France to teach English, and she found herself doing the same things as she would have done back home–go to work, come home, eat microwave dinners in front of the TV. As can be expected, she reflected that it wasn’t much different living in France as it was living in the US. Similarly, I see people add to their bucket lists “run a marathon”, “go skydiving,” or “do a startup” simply as one more thing to check off, to serve as bragging rights to others, or mostly because they see other people doing it. [1]

Doing and experiencing things is a great start, but it’s more fruitful to learn something about yourself along the way. Those opportunities will not only inform later decisions in your life, but they will also enable you to see others with a keener eye. And that alone would be a pity to miss.

Time for the obligatory concluding quote.

He who controls others may be powerful, but he who has mastered himself is mightier still. — Lao-tzu

[1] Of course, there are some people who already know that they value experiences as a whole and go around gathering as many as they can. It’s perfectly fine if that is the case and they already know that about themselves.

Make tools for yourself and others around you

There’s a joke in computer science that everything can be solved with another layer of abstraction or indirection. It’s true. In our line of work, tools are essentially good abstractions for the problem we’re solving. Our craft and discipline is built with abstractions, and yet, I find it’s something hard for programmers to grasp.

Why use abstractions in the first place? We build abstractions to make it easier to work on the problem we’re trying to solve, without getting distracted by details from the big picture. We want to be able to drive a car using a an abstraction called a gas pedal, rather than timing the firings of the spark plugs in the engine, which is what actually moves the car forward. This abstraction lets us worry about that “what”–getting from point A to point B–without worrying about the “how”–the specifics of how that occurs.

I think we all know the above logically, but emotionally and in practice, we often disregard the ideas above. Ideally, a programmer not only gets the program to do what it wants, but also produces usable abstractions for other coworkers along the way. Often times we laud the quickest programmers, but I think the best programmers are ones that build usable abstractions for other programmers. The ones that build tools for others to use and increases the productivity of those around them. And yet, I’ve met programmers that didn’t like to build abstractions.

There are some programmers that like to have everything on a single page. . I suspect these are programmers that can hold an inordinate number of things in their head. They can look at all the details of which pistons are firing at which time all at once, and still understand the whole thing. But even this is unsustainable at some point, as there’s no physics capping the upper limit on the size of code bases. In addition, coding, at its core, is a social activity. If you write code that others find hard to follow because you’re mixing the “what” with the “how”, then your code is less useful to others, both to use and to maintain.

There are yet other programmers that fear it makes the code slow. I’ve seen Ruby code written as if it was C code. This is counter productive. Often times you don’t know which part of your code is the slowest until you measure and profile. Often times, your intuition is wrong about which paths get executed the most. There are diminishing returns to make a piece of code faster. If it takes 10 seconds to run, then a 50% reduction in time is great! But if it already takes 10 milliseconds to run, then the extra 5 milliseconds may not be worth it, as there are often many other pieces of code that would take 5 milliseconds or more to run. In addition, a user will not notice 5 ms as much as 5 seconds.

So while not every programmer should build tools for others, I believe it’s something every good programmer should aspire to. However, this is often a difficult skill to learn and get right in practice. It’s not easy to do under the time crunch of deadlines and fire drills. Even if you didn’t have those time pressures, it’s still hard to get right.

Why is it so hard to build useful abstractions? For one, you can often hide the wrong details. And when you hide the wrong details, the abstraction is useless because you need to manipulate the details. On the other hand you can veer too far the other way, by building abstractions that are too flexible, requiring too many new concepts for users to grasp before they’re productive.

The culprit to both problems is that we often don’t understand the problem well enough when we sit down to write. When you don’t yet understand all the different circumstances that you’d use an abstraction, you expose either too much or too little.

There are two ways to combat this. First, you should set out to write the application, and extract the framework or platform for it, rather than setting out to write the platform. I’ve seen some useless web frameworks because they set out to write the framework, rather than be informed by experience writing applications. Second, you should do something akin to sketching. You write the core of what is still unknown about the problem domain then test it. If you’re building a blog engine, you start writing the posting and commenting, not the login. Then refine it as you understand more about the domain.

Make tools for yourself that’s informed by the problems you face when you’re trying to get something done. It’s not a waste of time. It’ll make you sharper as a programmer, and you may get better technical or business ideas as a result. It’ll make you more productive, and you’ll be able to delight others once you learn this skill that requires experience and taste.

How to stream output of system process in Ruby rake task?

Often time, I use Rake to manage a number of tasks I use often, but I can’t remember the command. It’s part of building tools for yourself to make yourself more productive.

Sometimes, you use rake tasks to run servers, like so:

desc "Start the server"
task :start do
  puts `node app.js`

However, that doesn’t work. The child process blocks, and won’t return until the server exits, so that means `puts` never gets a return, and hence never executes. In addition, stdout of the child process running node isn’t connected to the stdout of the parent process running rake. Therefore, you won’t see any output from the server.

Finally, being fed up with the situation, I started looking around on google and stackoverflow, and it’s kind of an elusive question. But I finally have it. It looks like this:

desc "Start the server"
task :start do
  IO.popen("node app.js") { |f| f.each { puts line } }

As long as `node app.js` continuously flushes its stdout, we’ll get its output sent to the rake’s stdout. Yay. One less annoying thing to deal with.

[1] Reference: http://stackoverflow.com/questions/1154846/continuously-read-from-stdout-of-external-process-in-ruby

Dalton’s point

Recently, Dalton Caldwell posted an Open Letter to Mark Zuckerburg. I was surprised and disappointed by this top level comment and others on Hacker News:

I don’t understand what you think Facebook did wrong. They intend to enter this new space, using their technology and their people. As a courtesy they offered to hire you / throw a lot of money at you. What would you have had them do instead? Not compete with you, because you’re a precious snow flake? Acquire you and treat you like a prima donna, giving you your own team and allowing you to take your own technical direction? – tjlc

I don’t get it either. Last week this guy wanted to make some sort of paid Open Twitter competitor. This week he’s mad at Facebook for offering to acquire his company rather than simply build a first party feature! – temphn

Then the rest of the thread were people arguing over the more granular points about hard-ball tactics. Or about whether it was kosher to invite someone to a meeting and then change the topic of discussion. Or whether a company has a right to do whatever they please with their technology.

It’s as if many readers read one part of the article and it offended some resemblance of ‘sensibility’ in them that they had to click the back button and start ranting about things that have nothing to do with the main point, and others take the bait to feed the trolls.

His open letter to Mark is not about being acu-hired at all, nor is it at all a public complaint what Facebook did, or any of the topics mentioned above. For a while now, the main thesis of his recent blog posts is what he calls an audacious idea:

Social media platforms should not be ad-supported.

Or, if you like it in his own words:

“My thesis is that if you purport to be a platform, your business model needs to reflect your platform-ness. Because if you instead have an ad business model, and you’re not making enough money, you can end up slaughtering your ecosystem.” – Dalton Caldwell

This blog post is a continuation of that theme. The TD; DR version of the open letter is:

Facebook employees are doing asshole things to 3rd party developers[1], even though Facebook calls itself a social media platform[2], not because they’re bad people, but due to bad incentives[3] caused by a search for ad-revenue[4].

[1] “Mark, I know for a fact that my experience was not an isolated incident. Several other startup founders & Facebook employees have told me that what I experienced was part of a systematic M&A “formula”. Your team doesn’t seem to understand that being “good negotiators” vs implying that you will destroy someone’s business built on your “open platform” are not the same thing.”

[2] “Mark, based on everything I know about you, I think you get all of this. It’s why you launched FB platform to begin with. Do remember how you used to always refer to Facebook as a “social utility”?

[3] “I don’t think you or your employees are bad people. I just think you constructed a business that has financial motivations that are not in-line with users & developers.” – Dalton

[4] “your “platform developer relations” executive made no attempt to defend my position. Rather, he explained that he was recently given ownership of App Center, and that because of new ad units they were building, he was now responsible for over $1B/year in ad revenue. The execs in the room made clear that the success of my product would be an impediment to your ad revenue financial goals,” – Dalton

In fact, I’d venture to say that he’s not so much mad at Facebook, or even really caring that Mark Zuckerberg reads it or not. It’s like if you had concerns about the direction education in America, you’d write an op ed piece that is creatively written as a letter that starts with “Dear President Obama”. Of course, you don’t actually expect President Obama to read it, but you do expect Americans that read it to understand your concern for the status of education in America and address your main thesis.

For Dalton, I suspect it’s another piece of proof for him that he’s on the right track about how social media platforms shouldn’t be ad-supported. Not only that he’s looking for other people that believes this thesis.

“The only way to get fulfillment is to help other people that believe what you believe.” – Simon Sinek

And I should add, Simon is very specific about what he means by “believe”:

“We want to go to work with people who understand us, who believe what we believe, who have a similar view of the world, that has nothing to do with their opinions and the differences that we share. That’s good. that’s called diversity. That’s called advantages to problem solving, which is we can all look at the same thing from different angle and come up with solutions. What I’m talking about is why should you help each other in the first place. What are you in the pursuit of?” – Simon Sinek [emphasis mine]

Dalton is in the pursuit of this crazy (gasp!) idea about a non-ad supported social media platform, and blogged about it repeatedly [a] [b] [c] [d]. He’s trying to find people who believes what he believes. He is proposing something that goes against the current tide and grain, because he believes it’s the way forward. He believes it’s something sustainable, a public good, and the springboard for further innovation. And when you find yourself in that situation, you need to find other people that believes what you believe to help you realize the vision of the future that betters us all.

Google services being axed? Sounds like a list of startup ideas.

Google services are being axed left and right, due to Larry Page’s continual focus on what-matters to his company, via advice from Steve Jobs. It’s not bad advice at all, and I think companies have cycles of both experimentation and focus. It just happens to be in the focus phase.

And when Google decides to axe a product, it’s probably worth asking why they axed it. Is it because it’s untenable or it’s no longer needed, like iGoogle? Or is it because it no longer fits into the strategy of company?

Google Bookmarks Lists, Google Friend Connect, Google Gears, Google Search Timeline, Google Wave, Knol, Renewable Energy Cheaper than Coal (RE<C), Aardvark, Desktop, Fast Flip, Google Maps API for Flash, Google Pack, Google Web Security, Image Labeler, Notebook, Sidewiki, Subscribed Links,Google Flu Vaccine Finder, Google Related, Google Sync for BlackBerry, mobile web app for Google Talk, One Pass, Patent Search, Picasa for Linux, Picasa Web Albums Uploader for Mac and Picasa Web Albums Plugin for iPhoto, and all Slide products.


I suspect that some of them here are perfectly good startup ideas that are worth reviewing. What are small potatoes for Google may just be a mountain for you.