Snowsuit Zine // issue 04

Table of Contents

The Snowsuit Manifesto

Ideas are discovered

The implementation of ideas is what brings value to society. Ideas are an ocean in which everyone should be able to swim. Protection of an idea should be given to those who are making use of it.

Long-term thinking over short-term thinking

Deep and lasting progress is made through advances over decades and centuries. One should be guided by how their decisions will affect the generations to come.

Understanding and action

One should understand the strengths, weaknesses, and unknowns of a decision before acting. By understanding one can ensure their choice aligns with their long-term values.

Technology is an enabler

Technology should aid in achieving a goal that betters oneself and those around them. Adding technology does not always make a solution better.

Profit is not the only metric

One's success should bring success to those around them as well. By benefiting all society, deep and lasting progress can be created.


Computing && Culture

Software projects typically reflect the personality of their creators both in design and subject. How someone was raised can influence how they choose a programming language. Their personal interests will choose what they work on. And along the way, something functional sometimes comes out the other side.

It then follows that the pool of available software is based on the personalities that wrote it. Perhaps easier to understand, consider that Wikipedia was once 50% in English until more people got computers, got the Internet, and could represent their languages too. On the one hand, we cannot insist that software developers do something they don't want to do, but on the other hand, we also acknowledge that gaps exist with respect to how cultures are represented in the outcomes of computing.

The gaps are not just in computing, either. Let's take a quick glance at both the top and bottom ends of society to see what the demographics of modern wealth & power look like. To understand the top end of power, we'll look at the list of Fortune 500 (F500) companies.

There are more male CEO's at F500 companies named John than there are female CEO's at the same 500 companies in total. The Sony hack revealed that Hollywood has been paying its leading women less than its leading men. The White House itself pays its female staff 84 cents for every male dollar.

Minorities arguably have it harder. As of March of this year less than 1% of CEO's at F500 companies are black. One F500 CEO is a black woman. Only 4% of F500 CEO's are some non-white race. On the lower side of the economic spectrum, we see a much a larger representation of minorities. The Pew Research Center estimates that 27% of black families live at or below poverty and only 9% of whites live in the same conditions. 40% of the 2.1m US citizens in jail are black, yet black folks only make up 12.5% of the population.

The demographics of corporate power consists almost entirely of white men and the demographics of the unfortunate disproportionately consists of minorities and women. Both with about 4% representation total, for a shared pool of roughly 8%. Right now, in 2015, it is a lot easier to rise in both power and wealth if you are a white male.

One way to address the issue is to decide it is worthwhile to make particular values succeed in ways that don't happen naturally. One can think of the amount of work required to correct the imbalance as proportional to the gap between society's structure and the structure of those in power.

Recurse Center (formerly Hacker School), a company devoted to the art of programming, constructed a manual explaining what they feel a considerate hacker looks like. Among them are appeals for fairness, to not judge people by things they don't control, and remove things that don't directly contribute to a great learning environment. The goal was to provide a written document that can be referred to for both inspiration and to shun those that violate its goals.

Underlying their manual is an important distinction between creative and personal tension. Creative tension is what happens when a group attempts to create something. Disagreements take place, ideas are thrown about, and if all goes well, something great is created. Personal tension is when people let their potentially negative views of each other influence their interactions. Name calling is an obvious sign of personal tension, but less directed tension, like towards one's sexual orientation instead of the specific person, is equally destructive and has little to do with whatever the group is attempting to create.

By distinguishing between what makes something personal vs what is helpful to your group, you can point out particular behaviors and educate each other on the things we don't yet see. Subtle'isms, as Allison Kaptur once described it, are the ones that don't go without saying. They are subtle and possibly something that nearly everyone does.

Some have claimed anything resembling rules for behavior are made of censorship, suppression, or worse. There is some truth to these claims. Codes of conduct do suppress behaviors. The goal is very much to suppress harmful behaviors and amplify supportive behaviors. They imply the opinion that not doing something about stopping behaviors viewed to be harmful is itself harmful. The goal of the rules is to make it easy to speak up and move past the inertia of past mistakes, which subtle-racism, subtle-sexism, and subtle-sexual-discrimination all are.

From the perspective of computing culture, this could mean that the gains of computing don't apply to women and minorities. Tragic, to say the least. Careful consideration of behavior, with a keen eye towards fairness, can provide the necessary opportunities for both women and minorities to take part. Computers are the most powerful tool of our time and it's perfect that a worldwide, instantaneous communication network provides the opportunity to bring everyone in.

Easy Shouldn't Be A Sacrifice

At first I hoped that such a technically unsound project would collapse but I soon realized it was doomed to success. Almost anything in software can be implemented, sold, and even used given enough determination. There is nothing a mere scientist can say that will stand against the flood of a hundred million dollars. But there is one quality that cannot be purchased in this way – and that is reliability. The price of reliability is the pursuit of the utmost simplicity. It is a price which the very rich find most hard to pay.

– Tony Hoare

A hammer is a straight forward tool to learn how to use. The difference between a novice and an expert is small. Even Thor's hammer is simple. What makes Thor is not that he is an expert hammer wielder but that the hammer has chosen him to wield it. Hammers are also highly decoupled. While there is a standard use-case for them, they can be used for things that even the inventor never intended or thought. What's more, specialization in hammer comes with almost no long term negative effects. A nail gun is cost effective but has no lock-in. One can go back to a regular hammer without concern.

Programming is different. While it takes very little knowledge to create an apparent solution to a problem, the tools used to get there have traditionally made significant long-term trade-offs. The existing tools generally favor the tangible at the cost of robustness. They also tend to be tightly coupled, making migration away from them costly.

Abandon all hope ye who enter here

One of the strengths of the Information Age has been the ease with which one can be part of it. With access to the hardware, learning to program can be done by anyone with sufficient motivation. As access becomes cheaper it means that more and more people can contribute. The flip side is that it means the industry is composed primarily of people new to it.

At the same time, the business opportunities that require software engineering has grown massively. Business opportunities are, generally, focused on delivering a product quickly in a way that will attract users. Many of those in business that also try to cross over into development tend to learn only enough programming to meet those objectives.

Combined, these factors produce an environment that values visible solutions. Software is mostly engineered by inexperienced developers or groups of people that view software as a tool for their success rather than a skill that requires mastery. The technology industry is, in a large part, composed of dilettantes and neophytes who are being driven by short-sighted goals, and they are making tools and frameworks for each other.

Ruby on Rails embodies this observation. RoR is hugely successful and a lot of value has been created from it. However, RoR focuses almost entirely on short-term gains at the expense of long-term productivity. When RoR becomes the bottleneck, transitioning out of it is expensive, requiring a lot of developer time to rewrite components rather than tune them

MongoDB also suffers from valuing short-term gains. While MongoDB is often lambasted it continues to be widely used. To someone unfamiliar with it, the database appears to be a great slice of simplicity and scalability, however many organizations, such as Olery, Test Double, and Shareaholic, that have transitioned out of MongoDB due to its weaknesses. Assuming the data is valuable, migrating databases is a time intensive and delicate operation which translates into being expensive. Many companies transitioning out of MongoDB are migrating to solutions that are older than MongoDB, namely MySQL and PostgreSQL.

The cost of some technology choices can be enough to bankrupt a company. Mt.Gox and Flexcoin are two defunct bitcoin exchanges that had to shut down due to being hacked. In the process they lost many millions of dollars worth of bitcoins. Flexcoin, in particular, is an example of shipping a product without the developers understanding the tools they were using. Mt.Gox and Flexcoin highlight the larger problem of focusing on presentation more than underlying correctness. At the time of this writing, it's unclear what was exploited in Mt.Gox's system, however it is clear that after multiple hackings Mt.Gox still failed to prioritize security, a less tangible aspect of a service.

It's easy to understand why the industry is in this situation and hard to blame anyone. While the quality of a solution is nice, much of the quality is not directly visible to the consumer. The argument for delivery over quality comes down to the claim that spending too much time on quality will result in not shipping, or shipping too late, and thus represents an existential threat to the organization and product. It's an impossible claim to argue. Most developers being so green also means they are not in a strong position to educate the business side on the value of producing quality software. As such, there is a group of people driving organizations who view the world as a constant crisis to deliver and a group of people unable to articulate whether or not working on the less visible aspects of a product adds value.

The light at the end of the tunnel might not be a train

On the surface, it seem that software engineering is between a rock and a hard place. Solutions can make short-term delivery simpler at the expense of the long-term or the delivery of a product can be threatened by taking longer upfront. The holy grail would be a tool that allowed fast solutions while not paying for it in scalability. There is a ray of hope in one programming community: Go. The Go language has shown that simplicity and scalability can be combined into a single solution that is also popular.

The Go team has approached the language through the lens of providing simple, high-quality, loosely coupled, software. The language emphasizes simplicity and composability. Two components share a contract in the form of an interface, the concrete implementation does not matter as long as the contract is satisfied. With loose coupling being the preferred style of solving problems, one can pre-composed solutions to common problems which can be decomposed as the solution becomes more complex. One can address their short-term needs without giving up the long-term. That is not to say Go is a panacea or that everyone should start writing Go, but rather that it has shown the success of loosely coupling high-quality components.

Go has achieved its success through a devotion to simplicity. The common complaint lobbied against Go is that it is not complicated enough. Whether or not Go is the right choice for a problem, the authors have had the chance to take their decades of experiences, reflect on them, and encapsulate the lessons in to tools that everyone can benefit from, and people use it.

This model is recognizable to many: it is how academia generally functions. Experience and knowledge feeds back into new students who the build on it, not having to rediscover the basics each year. Students then have the freedom to build on that experience and surpass their mentors. This feedback loop is often missing in industry. However, if Go is any indication, there exists room to slowly move the industry in the direction of being able to make use of previous experience.

The importance of software shows little indication of lessening or even plateauing. If the vision of the Internet of Things pans out, software will be present in almost every aspect of daily life. The number of business opportunities and new developers will increase as well. It is going to be a bumpy ride no matter what, but it might be a bit more gentle with a culture and tooling that allows new software engineers to make use of the experience of those that came before them. The alternative is a software industry that continues to produce complex, fragile, and expensive to replace solutions.

Monthly Consumption


  • The Player of Games (Culture Series) by Iain Banks (link)
  • Capitalism and Freedom, by Milton Friedman (link)
  • Born Standing Up: A Comic's Life, by Steve Martin (link)


  • Some thoughts on security after ten years of qmail 1.0 by Daniel J. Bernstein (link)
  • Understanding the Causes of Consistency Anomalies in Apache Cassandra by Fan et al. (link)