Expressive Voting published

Ever since my high school years, I have been interested in approval voting, and convinced that it could generate better results than our normal election system. After the two elections that George W. Bush won, I grew more frustrated with the status quo, and continued thinking about election reform.

Today I am excited and humbled to announce the publication of Expressive Voting, my short book on election reform. It begins with a quick discussion of approval voting, which I have re-branded as expressive voting. This system is simple to explain: the only rule is that you may vote for as many candidates as you want. From simple rules, though, a complex system can emerge. Although I have opted for brevity, the advantages I can see in this scenario are numerous. I believe that expressive voting could leave us with smarter candidates, more voter turnout, a shorter and cheaper election cycle, and a more accurate appraisal of the most pressing issues we face.

The book, which also introduces several other reform opportunities, is available for free as an iBook or PDF. I will continue to update it, so the iPad iBook version is recommended (so the updates will come to you when ready).

Expressive Voting is actually a lot like Liking things on Facebook. You can Like as many things as you want, but only once each. If something loses your respect, you can Unlike it at any time. We could apply this simple formula to our elections, releasing us from the games and the politics, and letting us see who truly has the respect of the most people.

As part of this project, I have planned to create a site that people could use to host elections of this form. While this is not yet ready, the coding is underway, and the system for counting votes is mostly in place.

Thank you so much for your interest in the book. I know that we each have limited time for reading, so I have kept the book short enough to read in 20-30 minutes. I hope you take advantage of the next half hour to take a good look at Expressive Voting. After that, if you feel comfortable, please share the link, or even just the title, with friends, colleagues, and people in your life. Since the book is free and no one is making any money off of it, we're all in this together. We have a beautiful country, as do many of the nations of the world, and we have a lot to lose if we don't heal our political diseases. We also have a lot to gain if we take the care to run our elections in the smartest way we can. No matter what, we are definitely all in it together.

Working on this project has given me a renewed love for this country, and the freedoms we have in the political arena. I know that if I lived somewhere else, I might not get to freely speak and write about reforming the government. But, the freedoms in the Constitution are a gift from our ancestors, and we can honor these gifts by continuing to perfect the incredible systems they pioneered.

I recognize that reforming a system is difficult, as it should be. My hope is just to start a discussion, or to bring these certain thoughts to th discussions already happening. Read the book with an open mind, and then use your critical faculties to evaluate the reforms I advocate.

Lastly, I appreciate voters, and I'd like to thank you for voting this November!

Ruby Class - tl;dr

I am teaching a Ruby class focusing on beginner techniques and tools for making Rails sites. The class is in Brooklyn and meets at 1:30 on Sundays during January 2012. Five 3-hour sessions for $295 (or $245 for 3rd Ward members).

Sign up here.

Introductory Lecture/Q&A about the class: 7:30-9, 12/13/11

My blog post about what I will teach

Anticipating my Ruby class (1/8/12-2/5/12)

For the past six years, I have written Ruby code, and almost every day brings new trips to the web to learn new techniques. Ruby lets you get to the point so fast, that you are constantly immersed in integration with everything from census data to SMS servers to Facebook. You can implement world-class design patterns in a dozen lines of code - this is not a language where you write hundreds of lines of boiler-plate, day after day, just to define classes and structures. This is the future of white collar (or hipster collar) work, where you leverage dozens of systems in a way you can completely understand and customize - on your own or in any kind of group.

The flexibility of Ruby means that there are dozens of flex-points every moment. To really understand what is happening it helps to know a bit about how these are used. That is why my upcoming class will focus on teaching good habits and tricks for debugging and examining code. You will learn how to tell the difference between different kinds of errors, so you can find and fix them in a fraction of the time.

We will also learn about the Rails framework. Rails is a set of tools that help you create and deploy web sites. It comes with most everything you need, and offers plugins for almost anything else you could ask for. The rapid rate of improvement in this ecosystem has only increased as its profile has grown and grown over the past six years. Rails is opinionated software, informed by cutting-edge advances in business theory as well as security, technology, and design. The good news is that each part can be learned, and used, separately - but there is still a big vocabulary to catch up on for the newbie.

While getting familiar with the best desktop and online tools for shepherding our projects to prominence, we will also practice basic programming skills (like using objects and variables) and get more advanced if the class can handle it. As a class, we will collaborate on a couple projects so that the link between theory and real-world is as visible as I can manage.

This class is intended for beginners with no programming experience. If you've ever wondered what programming is like, please join us this January. If you are more advanced, I'll offer you more details to keep it interesting and do my best to answer your questions - but be aware that we will spend as much time as necessary going over the basics.

The class will be five 3-hour sessions, on Sunday afternoons at 1:30. We'll start on the second Sunday of the new year (1/8) and wrap it up just in time to head to a Super Bowl party (2/5). Each class will have a break in the middle, in case you were wondering. 3rd Ward is an artistic, educational, and fabrication facility in an industrial part of Brooklyn. If you haven't been there before, you are in for a real treat!

3rd Ward is also the site of a short lecture/Q&A I will host on December 13, to help you decide if the class is for you. That will be at 7:30.

To be sure, $295 is a pittance compared to most classes of this type. In addition to the 15 hours of classroom time, there will be opportunities to get help and feedback on any work you do between classes. There may also be opportunities to shadow me at work and help with some of my projects. And the whole thing will be a barrel of fun.

Seats will fill up quickly, so be aware of that. After this session there will be others, but they haven't been scheduled yet, so I'm open to hearing which days and times you might prefer.

Lastly, thanks in advance for supporting this class and making it fun and exciting for your fellow students and myself. I can't wait to see the inaugural group for this new endeavor!

I was just thinking about how I would write some test-first code in an interview, and it reminded me of using factories and mocking, and how I couldn't defend mocking to a smart young developer who had just given a talk about optimizing the performance of tests. I tried to explain why I liked it but my reasons seemed too abstract for him to buy into it. He said that letting his tests run through his whole app, it made him think everything was really working. I think he also suspected mocking would lead him to have to do more work on tests. Keep in mind that this was someone who had clearly already rewritten his tests many times in a relatively short testing career.

What if I told him it was like your app is a car, and you're testing the car. Wouldn't you want to test the individual parts, instead of waiting until the car is built? Unit testing does this, but what about when you are testing the conduit between two complex tools? Without mocking, you sacrifice your ability to inspect what is happening inside those two tools as they interact. I see the mock as a piece of specialized machinery that is designed to simulate part of your car, but is also letting you watch and measure things with as much precision as you need.

The app is also like a car in that some parts of it are there to go fast, some parts are there to keep you safe, and some parts are just there to smooth out the ride. They all need to be tested for different reasons, and sometimes it will make sense to test them in different ways. Conventions are important but if you think about it, every object has the potential for doing something unique; and you may be better able to express and use that potential if you don't hold to any presuppositions about how you are going to test something.

Cars have been made great largely because of the simplicity of decoupling the individual parts, at least to a certain extent, and seeing how each one performs in different environments. Maybe rubber tires were first used for horse buggies, and steel wheels were first used for streetcars. The tires for the Model T were sort of a hybrid; and the wheels for every car or vehicle made since then have been further hybridizations of that same tool. The point is partly that if your business is successful, your application is going to develop enough complexity to keep you coming back to the code and adding new ways to handle things. The real world is complex, and to make something truly useful you have to really marry it to the real world. Think of all the new safety regulations cars have had to meet over the years. Cars today can have 3000 or more parts. But a production application can have 3000 or more files. If you are successful, it depends on the app, but I'd bet most projects will get there if they are celebrating their tenth or twentieth birthday. Think of all the times you'll have to rewrite your tests to get through the next ten years. I think that's just how it is in a successful business, there's a lot of changes involved in achieving that appearance of stability. But that's one of the reasons that mockists like being able to describe their needs in more general, or abstract, terms, instead of only working with the side effects of a particular implementation. There is a circular logic problem, so using mocks does leave you the onus of verifying that your app pieces can actually work together. Even so, mocks can be the perfect method for combining several components in a test, and for limiting it to the ones you want. This is also a big reason why I like rr ("double r"). You can use mock.proxy to make sure your method is called the right way, and also pass the method down the chain to see what happens, right there in the same test. It's quite amazing.

So maybe this is just more abstract bs, but I think that mocking makes my app better by letting me see to it that everything makes sense, not just that it seems to work for some reason. Spending more time with the surfaces of my objects may be a hefty trade-off, but I think it will end up saving me time in the long run. Hopefully I will have a better idea after 10 more years of experience.

another patience lesson

Apple has really come to prominence, and a lot has changed this decade. But, not all that much. They are still doing most things in pretty much the same way that they were in 2000. In particular, they have a relatively slow, long-term rollout of new features. They would rather release a feature quietly and let it go unused for years, while people gradually figure it out, than promise a new feature that they end up failing to deliver.

One example is the accelerometer. Apple notebooks have had it for a long time, but it is only used to protect the hard drive if the computer is dropped. It has been possible for quite some time to install software that allowed you to use the accelerometer as an input; a couple of examples would be tilting the mac to control steering for a flight simulator, or tapping the side of the screen to start your favorite applications. It may be that the laptop is a little too heavy to make those applications useful, but I still think that one day they will surface and prove useful. The iPhone has, of course, made the accelerometer much more prominent, and uses it frequently. However, the use of the accelerometer is still rather primitive; it should be possible to devise a rich vocabulary of controls that are initiated by subtle movements or tilts. But, the public need time to adapt to that reality, and Apple seems to know this better than many other companies. The foundation of their success is shipping features that are polished to a shine, but not flashy in the least.

This is a strategy that has also been clearly communicated by 37Signals, which is a small company that specializes in design but also has published several of its own web applications. Both in their stewardship of the Rails platform, and their books and blogs, they explain that simple solutions are just more effective. There are many facets and corollaries to this thesis, but the most salient one may be the annoying trend that people will give up on trying to use a web app if it is not immediately intuitive. Although there may be complicated business logic hidden in there, the interface of it should be as natural and unfettered as possible. It's relatively clear that they learned this wisdom from Apple, and the two platforms have both benefitted from recent advances in the other (for example, Apple's Objective-C 2.0 incorporated several of Ruby's most time-saving features; Ruby only became popular after 37Signals began to use and evangelize it).

Keeping my product simple, and my interface natural, is a challenge for me. There are just a whole lot of features I can add that seem powerful to me. I know that I should wait until my user base has mastered a few things at a time, and I am striving to do so. I just wanted to mention that Apple's event this week provided another reminder of their enormous patience.

When they debuted the new iPhone this summer, the most suggestive remark was that they planned to ship X millions of "FaceTime devices" this year. It was pretty clear that this videoconferencing technology would be part of the new iPod, but many wondered if it would also be incorporated into the AppleTV box. There are several big advantages to having it there - for example, your TV is usually in a spot that has a very strong WiFi signal. It has a big screen, and you don't have to hold your arm out in front of you to see it. For users, like grandparents, that might not get the point of an iPod, or might not be able to find it if they have one, the TV is a less threatening interface. And, the enclosure of the AppleTV is big enough to house a good camera, with zoom, without a miracle of engineering.

Yet we will have to be patient to see that come our way. I think Apple preferred to keep the price point down, since the first AppleTV was a bit of a failure. There may have also been awkward issues with camera placement that Apple opted to avoid, or defer for now. After all, it is "face" time, not "edge of the coffee table" time. Apple is enhancing the beauty of its product with the beauty of faces. And, although it will be years before video calling is an everyday experience, they will patiently wait for us to catch up, and just keep working on their new ideas in private.

your language controls your morals

In school I was lucky enough to study two languages that are relatively uncommon subjects of study for my generation, and for Americans in general. First I studied Russian, and later I took a year of modern Greek (a year's not much but I had a Greek girlfriend who helped me understand a lot of etymological, idiomatic, and historical details that enhanced my ability to appreciate the way the language is used). I didn't master these languages, but towards the end of my study, while I was in college, I gained enough of a fascination with them to marvel at the drastic differences in grammar between them and English, and the logic in the speech patterns of foreigners that I could only apprehend after being so exposed.

For example, hearing my girlfriend speak English in a way that made sense to her Greek mind was always cute to me, and it gave me a lot of clues about how to speak Greek. In Russian, the ordering of words, and the types of words that are included or excluded, is quite different from English, so when I was in Russia trying to communicate with Russians, even if I was speaking English I would sometimes speak it in a way that was heavily influenced by Russian grammar. It's like the trick of speaking English with a Chinese accent - I think that really does make it easier for Chinese people to understand you if their English is not that strong. Think about the languages you studied and how hard it was to understand native speakers - if they spoke with an accent like yours it would be much simpler right?

Learning these other languages changed the way I spoke English. It also changed the way I saw events and agents in my life. Greece and Russia both have long histories with some very sad chapters, and I believe that I gained more patience and resilience after being exposed to their cultures. On the other hand, there are also moral codes that are mostly respected by Americans that Greeks and Russians regularly flout. There are economic, political, and historic reasons for many of them, but there are also patterns and biases in the languages themselves that lead to these consequences.

This article gives a number of examples of how your native language impacts your cognitive abilities and thinking patterns. They do devote some space to questions related to blame and culpability, which I find to be one of the great crutches of American intellectualism and politics. I worry that people assume a problem is solved once they find someone to blame (banks, BP), and they fail to step back and observe the rest of the ecosystem that contributed to the failure. I think this culture is buttressed by the legal system's treatment of admissions of guilt. Although I am not a lawyer, my understanding of tort law and, to a lesser extent, criminal law, is that if you admit that you were at fault, the court doesn't make much of an effort to examine (or deny) your culpability; rather it relishes the opportunity to "call it a day" and just let you take the fall. This atomic view of agency (i.e. each crime is the "fault" of exactly one person) not only leads to elaborate and irrelevant machinations in the courtroom, and pathetic framings and cover-ups, but it also makes people behave in a truly shameful way just so they can avoid being under the gun at the wrong moment. Seeing a disaster about to happen, Americans are less likely to lend a hand, lest they be standing closest to the pit when things collapse. (Conversely, if everyone stepped in and grabbed on, the thing wouldn't collapse at all).

I think the oil spill in the Gulf is a great illustration of how we miss the point. When the explosion first happened, the survivors were isolated for days until they signed papers exonerating BP - their families had no way to know if they were alive or arrange care for their injuries. This is barbaric but it makes perfect sense in light of the American laws under which the company was operating. On that topic, part of the reason the rig was so unsafe in the first place is because it was registered as a vessel under a foreign flag that you've never heard of - a nation whose safety standards for oil rigs are essentially non-existant. Now, the issue of America regarding the sovereignty of other nations is complex, but to an extent I think it's accurate for me to portray the situation as follows: by mandating a full safety inspection for American vessels, but allowing unsafe vessels under other flags to operate in the Gulf, our government is encouraging businesses to skimp on safety-related investments, and simply shrugging and passing the buck when the other shoe falls. This time, the penalty for this short-sighted approach will cost us dearly in many ways. Is this the idiot tax we pay for speaking English?

BP's spokesperson, Tony Hayward, has been roundly criticized for not being more apologetic. Yet, in both cultural and legal terms, this was exactly the right course for him to take. Legally, his non-admission will make it much harder for courts to rule that BP was negligent and not merely unlucky. Culturally, the withholding of a memorable moment of denouement will make it harder for Americans to remember BP in a negative light.

I want to take a quick digression here to clarify that I understand why courts and laypeople refer to admissions as reliable indicators of guilt - in the aftermath of a tragedy, no one typically can ever reconstruct events with the same clarity that is available to the perpetrators. If Tony really thinks this was just a fluke accident, that is relevant information with regard to our attitude and policy on other underwater oil wells (which are mostly managed by BP, incidentally). If he, deep down, knows that they were taking too many chances with their safety policies, then that's an indication that we will potentially be able to prevent more disasters by running a tighter ship.

So yes, an individual's assessment of his own guilt is often the most reliable information on what can be done to prevent future tragedies, and it rightly has a prominent place in an investigation. Yet we must make more room for revision and elaboration - especially when you consider how faulty our memories have been shown to be, and how irrational our motives actually are (refer to Arielly and Vedantam for more exposition of this topic). We do want to know whether BP knew the practices were unsafe - but we don't need to know that so we can punish them. We need to know it so that we can figure out how to keep the other wells managed by other companies safe. I am really worried that Americans and our politicians are just going to focus on BP and allow this and other disasters to happen over and over. The masterful job that BP has done at deflecting the blame (replacing Hayward with an American, keeping journalists away from the Gulf without raising a stir for doing so) will prolong the obsession with nailing them to a cross, and postpone the process of doing the cleanup and reform that actually matters. And since BP only sells oil to other oil companies, not to consumers, there is nothing to boycott and really no action we can take. It is a British company. (Don't be fooled by the BP branding on gas stations, it's a vestige).

As you may be able to see, the entire company is set up in a way that is ideal for deflecting culpability, and the laws governing their operation have just the same orientation. Sadly, many American businesses are set up this way, and this leads to massively wasteful business practices. Most of us can understand that in the long run, it is more profitable to respect the environment, both natural and social, even though doing so incurs many expenses in the short term. Yet American businesses are mostly focused on the short term, and this is, in a nutshell, why our economy has failed to take care of us and our happiness despite the tremendous natural and intellectual resources we have at our disposal.

So what does this have to do with the language we speak? English sentences put a lot of emphasis on the actor, the agent, the responsible party. We are in the habit of specifying who does things, and this tendency helps us forget that they are acting within a set of circumstances that were created by thousands of other agents. It tricks us into thinking that people plan and intend to do whatever they end up doing. And it leads us to thoughts of punishment rather than prevention. English is great for things like scientific investigation and storytelling. But, for maintaining a civil society, we would have a lot to gain from the viewpoints cultivated by languages spoken in places with a longer history of keeping themselves safe by keeping their neighbors content. Remember, although English is not as young as America itself, the British Isles are physically isolated from all of their contemporaries, which is a situation that could have cultivated something of a blissful arrogance, an attitude unworkable in a truly huge society.

All these are some of the reasons why I think learning language skills should not be an undertaking of learning words, so much as one of learning sentences (or lines, if you will). Words can mean any number of things depending on how they are used - so seeing how they actually have been used gives you way more information about what they really mean.

lost iPhone: might not be a coincidence

An Apple employee lost an iPhone at a bar. Now, maybe it was done on purpose, but that's kind of unclear. If we assume it wasn't, I think it's quite possibly an indication that this phone is easier to lose than the current iPhone. My reason for thinking so is because of repeated observations about the way people use their iPhones and the way they use their BlackBerries.

Basically, BlackBerries aren't as thin (front-to-back) and the corners aren't as smooth, so it's harder to shove them into your pocket . Also, the buttons and scroll wheel can get caught on creases or seams in the fabric of your pants, such as the fifth pocket that most jeans have inside the front right pocket. As a result, people are way more likely to just set the BlackBerry on the bar instead of putting it in their pocket. Then they get drunk and leave it there.

This is also related to the fact that BlackBerries cultivate more addictive behavior by virtue of the push email. Sure, the iPhone has had push email capability for a year or two but I don't think most people use it. Conversely, most BlackBerry owners don't know how to turn it off (if it is even possible; I don't actually know). The consistent interruptions create behavior patterns where people are addicted, and check for new messages every few minutes (that is why they are so frequently called CrackBerries by people who have had them for a while). Combine this with the chore of shifting your weight so you can dig it out of your pocket and you have a device that people can't help losing, all the time.

The new iPhone looks like it might be significantly boxier, and somewhat harder to shove into your jeans while seated at a bar stool. Also the buttons look like they might have a bigger profile (so they can get caught on the fabric). The result may be a phone that people are bound to lose.

This could be a really big problem. iPhone owners are often social people (one of the strengths of the iPhone is the simplicity with which you can manage contact lists that stretch into the thousands). They are also typically people who have a few extra bucks to spend at the bar. If this is indeed a characteristic of this new phone, it will rear it's head many many times.

Losing phones has become extremely common, and I have always felt that the iPhone is a great phone to lose because if you are even remotely responsible about connecting it to your computer, and have told it to sync with your address book, you don't miss a beat. You plug in your new phone and it has everything including the history of your text conversations. If you use MobileMe and have push notifications enabled, you can also erase the data on the iPhone you lost. There is no need to respond to every text with "Who is this? I lost my numbers" and no need to make a BS facebook group begging your friends to take the time to have pity and send over their numbers.

I don't blame Apple for giving people reasons to get new iPhones. However, traditionally, they have been positive reasons that people could feel good about. Losing a phone that costs $500 to replace is a relatively negative experience for many of the young people who adore their iPhones. I understand that a bigger enclosure facilitates better computing, but at what cost? I trust Apple to find the right trade-off here but I just wanted to add this note of warning because the thin profile is one of the things I love most about my phone. What can I say, I wear tight pants sometimes! And I like shoving it in my pocket while web pages are loading so I'm hands free and ready for action, not standing around like a tool.

There is probably a better design coming for the next iPhone, but what do I know about that? I just hope it works for my needs.

In my dating life I have been trying to pay attention to what I can do to find and meet women who are really attractive to me. One piece of advice that I came across was that keeping notes on the conversations you have is a really good way to diagnose your weaknesses, especially when you share your notes with a coach. My project lineoftheday is designed for exactly this process, and I have really high hopes for it's potential to help people improve their conversation skills.

Even if you're not delivering handwritten notes, one principal reason having a coach is helpful is because you have someone you have to tell if you don't practice your skills. Being accountable to someone you trust is a powerful motivator for almost anyone. In my youth I felt guilty telling my piano teacher that I hadn't practiced. She encouraged me to diligently write down my minutes every day, not do it from memory later in the week. She was showing me how to manage my guilt, by allowing my accountability to release the pressure on me to make decisions.

Being accountable at work is an area I've had to explore because I've worked in a few situations where my managers weren't especially proficient at evaluating what I was doing, and I wasn't always interested in taking the time to translate it into their terms. I have tried out a couple different approaches for bridging the gap, and I'm definitely starting to think that there are some good ones out there.

Github provides a simple way to view the chronology of my work, although the timestamps aren't very precise in the commit history view. Pivotal Tracker also keeps timestamps for when you start, update and finish stories. And you can use pickler to synchronize your tracker stories with the passage of your cucumber tests. Using a similar tool to synchronize tracker stories with rspec examples would be great, but I'm thinking about taking it one step further, and using the spec log to analyze every time the spec is run, not just the first time it passes.

Apart from making you accountable, the other primary reason that having a coach accelerates your progress is that he has been there before and he knows what you can do to address your mistakes. He's probably seen it a few times before in other guys as well, and seen what eventually enabled them to get around it.

If you shared every attempt you made to get the spec to pass, a coach would be able to point out which approaches were more reliable for the future, or explain what was missing in your earlier attempts. And simply by being exposed to the problems you're trying to solve he would be able to recommend alternative approaches you may not have known about. It would be like watching instant replay of you writing the code.

Git definitely provides the technology for making instant replay possible. Integrating it with spec runners that run specs on every save, or those that run individual specs or groups, would be the pivotal step in making coders accountable to their coaches. Now that github is so fast, it might be the preferred method of reviewing the code, but others could definitely be devised that focused on the individual histories of specs.

Accountability to your business associates could also be generated by the timestamps and metrics of your journey. In a normal workday you might only commit code five or ten times, and there's no evidence that you weren't on youtube for an hour in between. But you probably save a file every thirty seconds. And maybe you always get your specs passing within three tries. After running the repo and spec data through algorithms that make graphs of it, these strengths could be visible to your managers at a level of detail that would make you very much accountable for the quality and consistency of your effort. To measure the effectiveness of it, instant replay mode for Pivotal Tracker could be implemented, perhaps via the api.

I learned recently that watching yourself on video is such an effective means of correcting mistakes that sometimes you don't have to do anything at all to unlearn them. Simply having seen it once is enough.

Viewing your own replays could give the same results. Being accountable to yourself and others helps you work smarter because there are manufactured consequences for writing lazy code. And being able to see new patterns can help steer you in a direction of not even having to write much code. But it's something you have to see many times before you can write it sometimes. Your brain is always busy learning patterns that it doesn't tell you about.

When a famous coder publishes changes to a library he knows that they're going to be read over by lots of people, so his accountability is in place. When a famous pickup artist talks to girls in front of a camera, or just a microphone, he knows people are going to listen. And in both cases, part of how he got so good was by establishing that accountability so that he had to be good. You can establish it faster if you use artificial tools to manufacture it, simply by layering abstractions on top of it. I know this approach seems frivolous to some purists but to me it's just observing and regarding the natural phenomena that motivate people to act.