Economics Study Idea

Open source software projects assume that “many eyes makes all bugs shallow.” However, the recent heartbleed vulnerability in OpenSSL revealed that showstopper bugs can exists for years.

Your paper would look at the biggest, most used open source software projects (like OpenSSL), and examine their development practices. For example, in OpenSSL, there is no proper intermediate code review step in between “random coder commits code” and “code goes out to the world.” In contrast, Chromium has a review step that the original author is completely excluded from, where multiple people read the code.

Once you have categorized review practices, you will examine the number of severe vulnerabilities that have made it past the review and been deployed to the world.

Sadly I can’t see a way to do randomized trials of software development. Coders are expensive and there are only a few projects that are as important and high-stakes as OpenSSL.


Hacker School banning “feigned surprise” is absolutely brilliant

[Since you might wonder while reading this piece what my relationship to Hacker School is: I have no relationship with Hacker School. It has been described to me, and I have devoured the blog. If I made a mistake, let me know.]

The biggest insight I’ve had as a programmer is just how often other programmers are portraying false confidence. My natural approach to problem-solving is Socratic, feeling out different ideas and taking small, well-supported steps. Compare and contrast that with making gigantic pronouncements full of bravado. Writing software is inherently an exercise in managing complexity, which is best done with caution.

The best developers I’ve worked with were willing to admit when they didn’t know something. Of course they could learn quickly. If you meet an arrogant developer who pretends to know everything, be careful. To them, their ego is more important than your software. An insecure person who mixes up their self-worth with their programming ability can be very unpleasant to work with. Sadly, some workplaces and development teams reward bombastic claims made with absolute certainty, even on complex topics.

If you have ability and a strong work ethic, people will notice. You will learn a lot from their reaction. If they react by treating with you with respect, they have strong character. If they react by taking every opportunity to belittle and undermine you, they perceive you as a threat to them. If you aren’t prone to petty jealousy and spiteful thinking, it will be difficult to empathize with people who are. Sadly, you must handle these threats. Declaring yourself “above it all” only makes you an easy target, especially once you gain more responsiblity and therefore power.

“Feigned surprise” (when someone gasps and says something like: “you don’t even know about monads?”) is a method of belittling someone and lording your superiority over them. Every organization says about itself, “we don’t have any rude, unpleasant people here. We’re different!” And during the interview process those people are hidden away. Usually you can only find out the truth by actually working there. But by banning feigned surprise, Hacker School strikes a real blow against unplesant, unproductive behavior, and drives away toxic people. That is a strong signal that Hacker School is the sort of place where someone can program and collaborate in a peaceful atmosphere, and therefore accomplish a great deal.

Edit: Join the Hacker news discussion here

“XOXO-style software”, or, What I learned from trying to build a niche site

A friend of mine is a great fan and supporter of the annual XOXO conference held in Portland, Oregon. According to their website, “XOXO is an experimental festival celebrating independently produced art and technology. We’re bringin’ the love back.” To me, XOXO is about using computers to have fun, and to entertain friends and likeminded people with whimsical software. Looking at the works presented there, I’m reminded of programming before it was my full-time job, when I spent all of my programming time tinkering and gratifying my curiosity, instead of implementing some boring widgit for the twelfth time. It’s a beautiful concept, and I coined the shorthand term “XOXO-style project” for software that would be appreciated by the folks who attend this conference.

A few months ago, I decided to try my hand at being an independent entrepreneur. I followed the directions I found online from successful people with profitable websites, which said to find an underserved market and create a website about it, whether or not you knew anything about the market. But as I was doing the research, I realized that even if I was successful making a niche site, I wouldn’t enjoy the process. I want to write software, and making a niche site requires very little programming or sysadmin ability these days. And writing trumped-up copy about products I don’t believe in isn’t how I want to spend my time, even if it means I don’t have a boss.

My vision of being an independent entrepreneur was hacking on interesting code, and doing XOXO-style projects. The reality was very different and disappointing, but I’m glad I put the time in, because I learned more about myself and what kind of work I prefer. I want to spend my time programming, preferably on my own XOXO-style projects, and given the choice between working for someone else, but writing code all day, and not having a boss but not coding, I’d rather code for someone else than run an independent business where I have to only do businessy stuff like write copy, sell, read emails from customers, etc.

Make scrollbars always visible in OS X

To make scrollbars always visible in OS X, first open System Preferences, and click on General.


Then under “Show scroll bars” click the bubble for “Always”


Start programs automatically when you turn on OS X

If you’re like me, every time you turn on OS X, you launch Thunderbird, Firefox and Terminal. You can configure OS X to do this for you automatically.

First, start System Preferences. Then click on “Users & Groups”


Now, click your username in the left column, and then click “Login Items”


Now, click the little “+” under the list of applications


And add applications to the list. They will launch automatically when you log into OS X.

Don’t forget to click the lock in the lower left corner of the System Preferences window to save your changes.


Wongi-engine syntax

Lately I have been using the wongi-engine ruby gem, which is fast and works well. In my opinion the documentation could use more examples of proper syntax, so I will provide some here. Before this project I had not used a business rules engine  or heard of the Rete algorithm before, so some of this might be obvious to more experienced coders, but I had to figure it out.

harry =
engine = Wongi::Engine.create
engine << [harry, "wizard", true]
engine << [harry, "muggle", false]
engine << [harry, "potions_grade", 1]
engine << [harry, "spells_grade", 2]

advance_grade = engine.rule "advanced to second grade?" do
forall {
has :Student, "wizard", true
neg :Student, "muggle", true
maybe :Student, "potions_grade", :Potions_grade
maybe :Student, "spells_grade", :Spells_grade
assert do |token|
token[:Potions_grade] < 3 && token[:Spells_grade] < 3

if advance_grade.tokens.size > 0
harry.grade = 2

As you can see from the example code snippet above, you can easily perform simple operations like == or != using the has and neg keywords in a Wongi::Engine rule block. However, to do more complex operations you can use maybe to put a value into a token variable, then perform operations like < on the values stored in the token in an assert block. The assert block will return true or false based on the final line in the block, so don’t do anything important in earlier lines and then lose track of it. The documentation refers to less and greater keywords, but describes their use as “obvious”, and I wasn’t able to figure out how to use them to compare anything stored in a variable.

Bitcoin reading for developers

People who discuss bitcoin can’t agree on much, but we can all agree that there is a lot of bad writing out there about bitcoin. Over the last few weeks I’ve taken an interest in bitcoin and here is the reading material I found most useful.

A short 10,000 foot overview

The PDF that started it all

A very nice bitcoin wiki

A long primer that explains cryptocurrencies from scratch

When you start doing development work, dont use real money, use Testnet. It’s a parallel bitcoin protocol that has no value but is the same source code.

If you want to buy some real bitcoins with US Dollars, I recommend coinbase. They are very likely not a scam, considering who their investors are. 

If you liked this post, you can tip me with bitcoin!