tag:chrisburnor.com,2013:/posts Chris Burnor 2016-09-16T17:31:04Z Chris Burnor tag:chrisburnor.com,2013:Post/764223 2014-11-04T05:53:10Z 2016-09-16T17:31:04Z Weekly Thoughts

I found an interesting blogging idea today to simply write down 5 of the things I've been thinking about lately. Like Nadia, my ambitions for my blogging far exceed my capacity. However, as with most skills, increasing capacity comes through excercising such capacity as already exists.  So I'm going to try to at least once a week, write down a list of the 5 things that have been on my mind during that past week.

  1. Robots vs Sweatshops: I've been hearing a lot about the automation being a driver of the current depression in good job creation and the ails of the middle class. However, it occurs to me that a lot of our consumption is made by hand, just in parts of the world where labor is cheap. Maybe that growth of emerging middle classes is having a downward pull on middle class wages in places that were previously more competitive markets for manufacturing?
  2. Rest vs Decay: I've noticed that when I'm not 'working' (whether on projects or errands or my employment), I fall into one of two stats: rest or decay. In my rest state, I emerge, rejuvenated and energized, whereas in my decay state I emerge - well actually I don't emerge, I just continue to be in a low energy, lethargic state. I still haven't fully explored the difference between the two.
  3. Process and Scale - There is a sense that small teams and individuals have an advantage over large organizations because they are more agile and have less process and formality. I wonder though if that might be backwards. Because they are small they can actually have much *more* process and ensure a much higher degree of devotion to tight and agile development cycles. Maybe the real problem at scale for organizations is not lack of process but the difficulties in actually doing it correctly.
  4. Improvement and measurement: Not much to say here other than the observation that you can't improve what you can't measure.
  5. Philosophies of blogging: what exactly am I trying to achieve with my writing? Am I trying to make factually based claims that I require research to do? I think thats not usually the case. More often I'm trying to structure my thoughts and create paradigms and frameworks for more effectively thinking about problems I and others face given imperfect information.
]]>
Chris Burnor
tag:chrisburnor.com,2013:Post/607470 2013-10-09T19:34:09Z 2013-10-09T19:34:09Z Life's Too Short to Work at a Boring Company

Note: This is an opinion piece that I wrote for the Amherst Student school newspaper.  The original post can be found here.

This is the time of year when I miss Amherst the most. The few orange or yellow trees I see along the road are a sad imitation of the colors that radiate in the hills of the Pioneer Valley. I am now far from that place, here in a different valley — one known more for silicon and software than puritans and poets. I recall my last autumn in Amherst, when I wondered what I was going to do with this liberal arts education in the dreaded “real world.” There were all sorts of companies, schools, fellowships and internships wooing seniors throughout the year, but the path I chose did not have any career fairs or pamphlets promoting it. I would like to advocate the “unpath” of entrepreneurship, for which, I believe, Amherst grads are uniquely suited.

At the time, I thought that I wanted to go into non-profits. After four years of classes, I had no desire to go on to yet more schooling, and I was suspicious of the business world. Wasn’t that all just greed and, um, more greed? During the financial crisis, I ended up spending several months in Sierra Leone, volunteering with a non-profit (OneVillage Partners) that used microloans to help bring self-sufficiency to rural farmers. With a microloan, a farmer could sell his cocoa for a better price and send his kids to school. With wealthier farmers, the government would be able to raise enough taxes to pay for roads and police and clamp down on bribes and corruption.

It was there, in the midst of the biggest meltdown of capitalism in a generation, that I came to a shocking realization: business can be a social good. Fundamentally, businesses are supposed to create value — for the owners, for the employees and for the customers.

This totally changed my perspective. Since that trip, I have embedded myself deeply in the start-up culture in the Silicon Valley. I’ve seen start-ups and met people, who use businesses as powerful tools to make a huge, positive impact on the world. Undoubtedly, entrepreneurship is something that Amherst uniquely prepares its graduates to do.

From orientation until commencement, we were told that the liberal arts education was not just about learning, but learning how to learn. Amherst doesn’t just teach facts, but how to synthesize ideas and think creatively about problems. This is exactly the challenge that a founder or early start-up employee faces every day! Almost by definition, every problem a fledgling company faces has never been dealt with before. How can ScienceExchange better connect researchers with labs? How can OpenGov promote more efficient municipal governments? How does Minerva Project bring the college into the 21st century? No one really knows the answers to these questions, including the founders and employees of the aforementioned companies themselves. However, they are continually in the process of discovering those answers and figuring out how to create that value they see lacking in the world.

I can hear the question through your head, through the page in your hand and back to my computer: Is entrepreneurship worth a try?

Statistically, most companies fail. With a little bit of seed-funding, a founder can make enough of a salary to live on, but it still seems that for all the work involved, there is a lot of risk in playing the start-up game. For most people, start-ups are, quite honestly, not a particularly good way to get rich.

Start-ups are much better suited for people who want to do them for their own sake. Aside from the value created by the business, start-ups continue the learning experience beyond the classroom. You learn planning, leadership and communication skills. You also learn how industries, people and organizations work. Perhaps, most importantly, you learn that those industries, practices and organizations can be affected and changed. You also learn to work with people firsthand and in-depth. Your co-founders and co-workers are a unique sort of family, strongly bonded together by experience.

So what’s next? How does one actually explore this career path? The best way to get involved is to get plugged into a community of like-minded people. I hear that Amherst has an entrepreneurship club now. Go join! Also, go to a StartupWeekend and make a startup in a 52 hour period. Sign up for StartupDigest in your area and find start-up events in your hometown (full disclosure: I am a StartupDigest curator). If you have a great idea, apply to YCombinator or 500Startups.

The most important thing you can do to prepare for the start-up world is something that is not limited to this or any career path: don’t be satisfied with how the world is. Change it. Mold it. Make it better.

]]>
Chris Burnor
tag:chrisburnor.com,2013:Post/596295 2013-08-21T03:53:16Z 2013-10-08T17:28:50Z The Abyss From Which There is No Return

"The big deal is simply this: once you allow the government to start breaking the law, no matter how seemingly justifiable the reason, you relinquish the contract between you and the government which establishes that the government works for and obeys you, the citizen—the employer—the master. And once the government starts operating outside the law, answerable to no one but itself, there’s no way to rein it back in, short of revolution."

John Whitehead

]]>
Chris Burnor
tag:chrisburnor.com,2013:Post/596094 2013-08-20T16:09:03Z 2013-10-08T17:28:48Z Groklaw is Shutting Down

I am deeply saddened to learn that the tech legal blog Groklaw.net is ceasing operations due to concerns about the security of their email.  

...the conclusion I've reached is that there is no way to continue doing Groklaw, not long term, which is incredibly sad. But it's good to be realistic. And the simple truth is, no matter how good the motives might be for collecting and screening everything we say to one another, and no matter how "clean" we all are ourselves from the standpoint of the screeners, I don't know how to function in such an atmosphere. I don't know how to do Groklaw like this.

I am sympathetic to PJ here.  Email has always been terribly insecure and the shutdown of the two secure email hosting sites (Lavabit and Silent Circle) due to government tampering has been a big blow for those who wish their communication to be between them and no one else.

However.

I also disagree with this decision quite vehemently.  For service providers who would be unable to provide their services in an environment of snooping, I understand, but this is fundamentally an issue of law and of politics for which communication, audience, and expertise are going to be of utmost importance.  Groklaw embodies all three and would have been a valuable allied in the upcoming (and protracted) fight that these revelations are going to involve.  

All of this has come to light through the self sacrifice of individuals: Edward Snowden, Glen Greenwald, David Miranda. However, to win this, we do not need more principled suicides.  We need a different sort of sacrifice: to know that they are listening and to speak anyway.  

]]>
Chris Burnor
tag:chrisburnor.com,2013:Post/589716 2013-08-19T19:00:00Z 2013-10-08T17:27:29Z You Can't Have No Process

Process is a concrete instance of that effervescent multiplier in a startup: execution.  It certainly is not execution itself, but is a repeatable (and repeating) building block of a current execution strategy -- especially in a particular aspect of the business (sales, dev, market validation, etc).  It is the day-in and day-out patterns of behavior that your team makes into habit until they are virtually invisible. 

A lot of teams think that you heavy process is bad and os they aim to be 'lightweight' saying things like 'we don't want to come up with a process to slow us down, let's just do stuff'.  This is half right.  A heavy process is unnecessary and distracting early on and most processes you make up beforehand are going to suck for your actual workflow, becoming a perfect example of premature optimization.  

That being said, there isn't any such thing as 'no process'.  Regardless of whether you say it or not, you're going to fall into a  routine that will end up being your process. This is a relief to know at the beginning.  You just start off with your Minimum Viable Process and don't have to get bogged down planning one out.  (I think it is this process planning more than the process itself that gives process a bad name in really early stage teams).  However, like your product, sales and every other aspect of your business, you need to iterate on that process to improvement.  This is where thinking 'we have no process' is dangerous.  How can you self reflect and improve something you don't acknowledge is there?  

It is helpful to reflect and discuss your processes with your team every so often to figure out what is working, what is not working and how to move forward.

]]>
Chris Burnor
tag:chrisburnor.com,2013:Post/585593 2013-07-22T22:00:00Z 2013-10-08T17:26:42Z Walkers

When I was in elementary school, there was a division among students based on the mode of transportation used to get to school.  Those who took the bus were called 'Riders' and those who walked to school were 'Walkers'. As I lived so that our backyard adjoined the schoolyard, I was, naturally a walker.  The first week or so, my mom would walk with me to school, but after that I was pretty much on my own for the five minute stroll.  

We moved a few times when I was in middle school but again when I was in high school, we lived just down the street and again, rather than drive (which actually took longer due to traffic), I walked to school.  Sometimes it was crisp and dry in the autumn.  Sometimes it was late at night after a rehearsal. Sometimes it was super early for a pre-school activity.

I walked to my first job after college. (College, of course was a walking bonanza).  I couldn't afford a car and was working at the college so it seemed to make sense to just get an apartment close by.  I'd walk back from work, parties, concerts and dates. 

When I look back at my life, I realize that the vast majority of my transportation has been walking (at least by time, probably not by distance). It's never really been a form of exercise or something I do for environmental reasons (though I'm happy it has those benefits). It's more that once you get used to the idea of walking somewhere, distances don't seem so great.  It may take a bit longer, but it's also the simplest and most straightforward way to go somewhere.

There is a sort of meditative quality to walking.  It's a time where my mind goes free and makes crazy connections between disparate ideas.  It's a time to call up a friend I haven't talked to in a while.  It's a time to reflect on the wind and sky and it's denizens.  

I'm glad that I'm a walker.

]]>
Chris Burnor
tag:chrisburnor.com,2013:Post/589651 2013-07-19T16:05:05Z 2013-10-08T17:27:28Z Terminals: Finally a New Hope

I just wanted to make a quick follow-up to my previous post ranting about the state of modern terminal emulators.  Hacker News recently had a link to an awesome project called FinalTerm. I can't say that I think it's perfect (not thrilled exactly about terminal autocompletion -- that should be the shell's business), but it's the most promising terminal improvement I've seen in a long time.  Sadly there's no OSX support on the horizon.

Just to be clear regarding my previous rant. I know all the tricks for intermingling the system clipboard with the shell (xclip on linux and pbcopy/pbpaste on OSX) but these to me seem hacky to me and I've had varying success with them depending on the display manager i'm using. Also, this seems to me to be properly the domain of the emulator, which is the ambassador from GUI land with which I visit TTY land.  More practically, all of those tricks only work in the command shell (bash, zsh) and fall apart when I actually need them in other shells (irb, the python repl, posgres, etc).

]]>
Chris Burnor
tag:chrisburnor.com,2013:Post/589312 2013-07-17T15:45:50Z 2013-10-08T17:27:25Z Humility, Technical Skills and Context

When I started blogging, I imagined that my blog would end up like many of those that I follow and value: filled with little technical tidbits, tutorials and analyses.  Starting off out of college, I recall being in awe at those who knew All The Things and would so generously share them with the world.  At that time, I was reading blogs more about how to set up a Wordpress site or install Google Analytics.  So, as my career progressed, I quickly learned that those people were not the real repositories of knowledge, as that sort of stuff was easy.  The real heroes were those who could tell you how to extend Wordpress with modules and plugins As you might imagine, this pattern continued. My reading focus grew from Wordpress to php, from php to Java, from java to Ruby & Python, from programming to Unix tools, from basic tools like the Ubuntu Software Center to apt and aptitude, from Gedit, to Gnome Terminal, from Bash to Zsh and so on.  

As my technical skills developed and my familiarity and comfort with technical systems grew, so did my reading materials.  Meanwhile, the things that I did know and was comfortable with, I began to take for granted.  What I was doing was defining context.  In the context of geeky science majors just out of college, setting up your own website, felt pretty edgy.  Once I defined myself as a technical professional, setting up memcached clusters, seemed pretty ordinary and blogging about it would be rather pedantic.

I'm not exactly sure where I'm going with this other than to remind myself to take stock of how I've grown, where I am and what I've learned and to not forget to pass it along to that next generation.

]]>
Chris Burnor
tag:chrisburnor.com,2013:Post/588276 2013-07-11T21:42:56Z 2013-10-08T17:27:14Z Grand Expeditionary Forces.

​I played a lot of Risk as a kid (well, actually as a teenager and adult too) and observed the emergent strategies that players take in that game.  Most players, after the first few terms tend to be holed up in one area of the board: Australia, South America, Europe.  They don't have a continent per say, but they at least control a foothold in an area, which they defend vigorously, dumping all their armies on every term.  This means that after a few terms the game has already fallen into a de facto stalemate.

The people who are most successful at the game though follow a different strategy.  In addition to their stronghold, they create a 'Grand Expeditionary Force': A group of armies cut off from the main stronghold which conquer new territory and explore new strongholds somewhere else on the map.  This allows them to both hold on to a stronghold that protects their defensive positions while still exploring and growing their influence.  Sometimes the Grand Expeditionary force doesn't work out at all, but they've built enough cards while weakening the other players that it still pays off.

Businesses also need Grand Expeditionary Forces.  In the early stage, arguably that's all that a business is.  Even after the initial traction and validation, a company still needs to put some of its resources towards exploring other options and avenues.  I'd argue this is the most important time to explore (just like a late game expeditionary force isn't as useful as one early on) because a young company has no idea the size of the hill it's climbing.  It's all too easy to get some early traction and immediately try to start scaling an idea rather than a business. Ideas don't scale; businesses do.

I think it's still important at the largest levels and the companies that are most successful in the long run -- Google, IBM , AT&T (in the mid century -- not the current iteration --also Xerox) -- spend time exploring crazy options.  If you don't disrupt your market, someone else will.

]]>
Chris Burnor
tag:chrisburnor.com,2013:Post/586239 2013-06-28T18:08:05Z 2013-10-08T17:26:49Z The Criminal NSA Great Op-Ed piece in the New York Times

"The N.S.A. has intentionally acquired information it is not allowed to have, even under the terrifyingly broad auspices of the FISA Amendments Act."

Remember that the Patriot Act was highly controversial when it was originally passed even in the form that it was originally interpretted.

Leave aside the Patriot Act and FISA Amendments Act for a moment, and turn to the Constitution.

The Fourth Amendment obliges the government to demonstrate probable cause before conducting invasive surveillance. There is simply no precedent under the Constitution for the government’s seizing such vast amounts of revealing data on innocent Americans’ communications.

The government has made a mockery of that protection by relying on select Supreme Court cases, decided before the era of the public Internet and cellphones, to argue that citizens have no expectation of privacy in either phone metadata or in e-mails or other private electronic messages that it stores with third parties.

This hairsplitting is inimical to privacy and contrary to what at least five justices ruled just last year in a case called United States v. Jones. One of the most conservative justices on the Court, Samuel A. Alito Jr., wrote that where even public information about individuals is monitored over the long term, at some point, government crosses a line and must comply with the protections of the Fourth Amendment. That principle is, if anything, even more true for Americans’ sensitive nonpublic information like phone metadata and social networking activity.
One of the greatest things about the Constitution is that, unlike most of our contemporary laws, it is clear and straightforward.   
]]>
Chris Burnor
tag:chrisburnor.com,2013:Post/585698 2013-06-25T16:29:16Z 2013-10-08T17:26:43Z The Poison is Secrecy

Why we’re all conspiracy theorists now

(This is a cross-post from my first post on Medium)

In the past few weeks since the first release of the Verizon phone record subpoena and the subsequent releases of PRISM and other covert federal activities, much of the debate has focused on the particulars of the programs — whether they are legal/illegal, whether they go too far, how they relate to historical surveillence systems, and so on.**

Usually the debate does not get very far in such conversations. One side breathlessly worries about how deep and pervasive the surveillence is and how the imposition impinges upon our civil liberties. The other side urges caution, pointing out that not all facts are known. However, in this response, lies the root of the problem: secrecy. This is the root of the scandal, and the root of a potent toxin that I think is much more dangerous than whatever actually may or may not be happening at the NSA.

The root of the scandal is the secrecy that all this has been clouded in. Yes, it was strongly suspected that the government was carrying out large scale surveillence on Americans. Yes there was legislation passed that had the potential to be misused for large scale spying. So, in a sense, the NSA leaks are not a surprise to anyone who has been paying attention. However, the revelations are still important because they are hard proof of the abuses. It is one thing to know your neighbor is creepy, but quite another to actually see the bodies in the basement.

It is important to note just how pervasive the secrecy is around this. The programs are secret. The courts are secret. The subpeona’s are secret. Even the rulings on why this is legal are secret. That is to say nothing of the ancillary secrecy that has surrounded this administration (extrajudicial killings, drone programs, secret no-fly lists, secret trials for whistleblowers like Bradley Manning). Literally all that we have to go on is the administration’s admonition that we trustthem.

In some sense, this has always been the case with covert operations. They are by nature secret and some level of trust is necessary for their existence. However, in this case, that trust has been entirely eroded. These programs were not supposed to exist. The president ran (twice) on a platform of openness and rule of law. The programs that we did know about were supposed to be targeted, limited in scope and direct for immediate threats. Instead, we find that they were broad, indiscriminate and hidden.

The poison of this secrecy is already visible. We are willing to believe just about anything now. Everyone is now a conspiracy theorist. Is the NSA recording voice calls? I wouldn’t be surprised. Are some people on the no-fly list for data in this program? Probably. Is there evidence that is secret because it covers up government abuse? Highly likely. As the New Yorks Times put it “The administration has now lost all credibility on this issue.”

Without truth, there is not even the possilibity of democracy, justice or freedom. There is simply a sort of gallows-trust born out of fear and impotence.

Welcome to the land of the free and the home of a brave new world.


** I am strongly on the side of privacy and civil liberties. However, I am also a realist and understand that as more and more commerce, communication and even property moves to this space, legal frameworks need to be re-understood in this new context. It may be that sovereignty extends into cyberspace and countries have the right to form an internet border patrol. I’m dubious, but it’s not crazy.

]]>
Chris Burnor
tag:chrisburnor.com,2013:Post/582031 2013-05-24T19:02:00Z 2013-10-08T17:25:59Z Rocket Powered Bicycles

I gave a talk back in February on how to avoid under or over engineering your product. I was heavily inspired for some of these ideas by my good friend Preet Anand.

]]>
Chris Burnor
tag:chrisburnor.com,2013:Post/582030 2013-03-14T21:27:00Z 2013-10-08T17:25:59Z Terminals: A Rant

First let me start off by saying that I absolutely love my terminal. I spend literally all day with a terminal window open, and it's usually in the foreground. Honestly, if it weren't for the fact that most of my work is implemented in the browser (and that the best developers are the first to Google), I could probably ditch the GUI entirely.

However, it is because of this love that I would like to rant for a moment on the state of the modern terminal and provide some suggestions for how terminal emulators might be brought into the 21st century. I particularly want to focus on features that would make terminal emulators better for experts. Most 'features' on terminals seem to be for making it easier for newbies to get started with the terminal, rather than to make the terminal better once they've mastered it.

I would like to see more than 256 color support in the terminal. This one is a no brainer.

Terminals should have better integration with the system clipboard. Why is selecting text so difficult. I should be able to use the system clipboard, not just for inputting and selecting text, but be able to pipe and modify that text.

Terminals should integrate better with the system content types. Apple has done some good work here with the open command. Linux should take some inspiration here.

I realize there are some tools out there that do some of this, but these seem to be features that should really be part of the terminal itself, not some half-baked weekend side project that never gets updated.

]]>
Chris Burnor
tag:chrisburnor.com,2013:Post/582029 2012-12-21T22:05:00Z 2013-10-08T17:25:59Z Thoughts on thinking about the End of the World

Like many others this week, my Facebook and Twitter feeds have been full of 'end of the world' posts and my social aggregation sites have been full of doomsday sales and promotions. Also, like so many, I have responded to such discussion with a roll of the eyes. Clearly the world is not going to end based on some prophecy or misunderstanding of an ancient calendar. Why waste our mental energies on such nonsense.

I wonder, though, if there is more going on here than simply widespread superstition. I know my friends and circles and though there is a wide distribution of intellectual abilities and social and political persuasions, I think I can accurately say that none of them actually believes that there is any chance of a civilization-ending event this week or this year.

There is very little room in contemporary society for us to express our existential fears. Yes, depending on our political persuasion, we may worry about global warming, or nuclear arms, or terrorism or the collapse of traditional American values, but we tend to see those more as problems that require solving rather than a true out-of-control doomsday scenario.

Nevertheless, as we struggle through live in the shadow of our own transience, we also realize that our world is similarly transient. Through some means, it will not last forever and some subset of our progeny will have to deal with that end.

We do not like to ponder such fears, but they haunt us and sometimes an ancient portent of doom allows us the freedom to obliquely grapple with them.

]]>
Chris Burnor
tag:chrisburnor.com,2013:Post/582023 2012-11-18T12:00:00Z 2013-10-08T17:25:59Z Incremental Decision Making

I found this article in the New York Times a while ago and it got me to thinking about how we actually make decisions and the different philosophies that we use to govern our decision making process. This is vitally important to start-ups as 80% of the work amounts to making decisions. The funny thing about those decisions is that most of them are inconsequential, but a few of them turn out to be vitally important. Unfortunately, we usually do not know ahead of time which decisions are the important ones and which aren't. This means that each and every decision could turn out to be extremely important down the road -- a paralyzing situation.

I think the solution to this is to take an empirical approach to decisions. As much as possible, don't make big decisions all at once, in some cases you have to (take this investor on or not, hire this person or not), but as much as possible, but break them into processes that you can guide as they happen rather than that lock you in.

This is what I mean by 'empirical decisions':

  1. Make a hypothesis of what you think you should do and why
  2. Run experiments to test those hypotheses
  3. Compare the results of your experiments with your hypotheses with your experiments and use that to revise your hypotheses.

Each of these steps is actually vitally important. It is not enough to simply run experiments without first creating some sort of framework as to what those experiments are testing. And unless you actually compare the results wo your hypotheses and use them to refine your hypotheses, you are just going to be forever shooting in the dark.

]]>
Chris Burnor
tag:chrisburnor.com,2013:Post/582021 2012-11-14T12:00:00Z 2013-10-08T17:25:59Z Users, Customers and Community

Jack Dorsey posted last week on reconsidering the use of the term 'user.' He proposes replacing it with the word 'customer' in the general sense, and 'buyer' and 'seller' in the specific Square context. While I agree in the general sense that the term 'user' is somewhat disparaging (though not as bad as some terms I've heard -- like 'muggle') , I think that replacing the term with 'customer' is a step backwards. It focuses too much attention on the actual money transaction part of the person's interaction with the product, which obscures all the more important characteristics of the person.

The problem with the term 'user' is that it's too simple. It pushes us into a model where we think of company, product and user. In reality, we have multi-tiered communities that interact with our products. At StartupDigest we had Curators, subscribers, VIPs to name just a few. At GroupTie we have members, organizers and groups. At bigger sites like Facebook and Google, they have advertisers, developers, members, users and so on. There are too many to name. It becomes very difficult very quickly to think or talk about them in general without resorting to a word like user. It becomes even more difficult because with these various roles comes an interplay between them. Doing something to improve the advertiser experience, may hurt the member experience. Making it easier to buy may hurt the seller.

I think the solution actually is to forget about trying to use an archetypal single individual as our model for thinking about how our product interacts with our community. In fact, that is the word that we should use: community. Companies have communities of people that interact with them. They have different use-cases and different interaction models and no one word will describe them. What we need to do is define our community, define the roles that exist within that community (including the role of the company) and then determine what is best for that community.

]]>
Chris Burnor
tag:chrisburnor.com,2013:Post/582028 2012-11-12T04:35:00Z 2013-10-08T17:25:59Z What's the Deal with .*rc Files? ⚓

Modern POSIX operating systems are littered with .rc and rc. files. Apparently these stand for 'run commands' and the term actually dates all the way back to 1965 on the MIT CTSS system (the precursor to Multics which was the precursor to Unix).

I love the overwhelming weight of history that you find in a *nix system.

]]>
Chris Burnor
tag:chrisburnor.com,2013:Post/582027 2012-11-09T07:29:00Z 2013-10-08T17:25:59Z Upside vs. Downside Risk

Risk is usually discussed in one dimensional terms, as though it is a scalar that simply has a value in a particular situation. Sky diving is risky. Leaving the root MySQL account without a password is risky. Starting a company is risky. I think this is a mis-modeling of how risk works.

What is risk? Fundamentally, it is simply a probability -- the chance that a particular outcome will manifest itself in a given situation. However, it passes a value judgment too. We don't talk about the risk of winning a particular hand in poker or the risk of being blue-eyed vs brown-eyed. Risk is therefore the probability of a negative or undesirable outcome.

This is where the aforementioned 'risky' concept comes in. However, we need to be smarter about how we define that undesirable outcome. Our minds are attuned to very strongly weigh bad things that could happen to us. We generally are much worse at thinking about missing out on good things that could happen to us.

I get asked a lot by friends and family if I think it risky working for a start-up rather than a big company. This is focusing on the 'bad thing that could happen' scenario. I call this downside risk.. It misses the upside risk that comes from working at a big company and missing the opportunities of a start-up. As an engineer, I think that I have much higher upside risk than downside risk. There will always be jobs and demand for engineering, but the specific jobs that I choose to work on are the difference between a decent salary and an awesome payout.

We need to think more about risk in this way. Don't just think about what could go wrong, but what you might be passing up by avoiding that negative outcome.

]]>
Chris Burnor
tag:chrisburnor.com,2013:Post/582025 2012-10-28T21:01:00Z 2013-10-08T17:25:59Z Success is 80% Not Screwing Up

There was a poster in the the hallway of my middle school that said 'Shoot for the Moon: Even if you miss, you'll land among the stars.'

I always hated that poster.

My cynical eighth grade self, thought "It should read: 'Shoot for the Moon: If you miss, you'll slowly suffocate to death in the cold loneliness of space.' " Cynicism aside, it seemed patently false. Success wasn't about shooting for the moon, but doing your homework, studying for tests and not being a dick to your friends.

As I've gotten older, I think I understand the idea behind the poster a lot better. Those without high ambitions fail to achieve high results. However, I think that my adolescent objections still stand. While it's all very well and good to 'aim high,' it still matters quite a bit exactly what you are aiming at. For example, if you start a company, it may fail, but you will still have learned valuable skills and have new connections and street-cred. However, if you drop out of school to try and become, say, a pro baseball player, your chances of success are far lower and you are left with far fewer options if you do not succeed with your primary goal.

To put it in tersms of start-ups, it's hard to see which companies are going to be wildly successful, but, generally, it's much easier to see which are definitely not going to be. Over confidence, poor thinking of the market, over-reliance on magical 'technical' solutions, over-reliance on name-dropping connections are all bad signs. What is amazing is that if you hang around Silicon Valley or any other large tech community long enough, you start to see the exact same mistake being made over and over again.

This leads me to believe that most companies and people fail to succeed because they continue to make the simple fundamental mistakes. I think this is why we see people that 'create their own luck.' Once you've mastered the art of not screwing up, success is simply a matter of searching through that remaining 20% to see what sticks.

]]>
Chris Burnor
tag:chrisburnor.com,2013:Post/582019 2012-06-12T12:00:00Z 2013-10-08T17:25:59Z Space Colony Art from the 1970s

Link

I remember seeing these pictures in a book in my local library and being absolutely enamored of them. The juxtaposition of New England-style countryside inside of gleaming, bright cylinders looked like the most wonderful world to my young eyes. I recently re-watched Stanley Kubrik's 2001: A Space Odyssey and was amazed how it, like this, despite how dated it is, still is my vision of 'the future'

]]>
Chris Burnor
tag:chrisburnor.com,2013:Post/582014 2012-06-01T13:47:00Z 2013-10-08T17:25:58Z I created a monster

Sometime in April of 2012, I came into work to find out that my crazy co-workers had, over a bottle of scotch, spent the previous evening throwing together an experimental dating site called CupidCurated. I admired their audacity and congratulated them for pulling it off and then chuckled to myself as I went back to 'real' work on StartupDigest VIP. You may have read about this a few weeks ago. This is the story of what comes next and what it really means to build a minimum viable product -- from the engineer who built it.

Two weeks later, I went down to Monterey to visit my in-laws. I had basically forgotten about CupidCurated at this point when I got a phone call late on Sunday evening from Chris McCann. This is when our fastidious editor compiles our event newsletters, so I picked up immediately, thinking something must be wrong with our CMS.

"How quickly do you think you can get CupidCurated up?", Chris went straight to the point.

"Um...."

"There's a demo day in San Francisco next Wednesday and we'd like to show CupidCurated at it."

My heart skipped a beat.

"I'll see what I can do..."

So began one of the craziest 9 days of coding of my life. The next morning, I immediately cloned our EC2 stack, forked our master Github repo and started to figure out how I could actually make this all work in 9 days. It's all very well and good to think of dating and recruiting as being parallel interactions, but how do you actually take one and turn it into the other. Could you take OKCupid and turn it into a LinkedIn killer?

The first step was to remove all unnecessary parts: activation, account editing, password resets. These are all key for a real product, but they're just wasting time in a demo. Then, I set Chris and Brendan on the task of re-writing all our copy to be 'dating-ish' rather than 'recruiting-ish'.

There was no way of getting around the core interaction of the application logic. A recruiting product helps companies and engineers meet. A dating site helps girls and guys meet. I made the crazy decision that women would be companies and men would be engineers (well, that one isn't so crazy, I guess). For the demo, the key was to validate the interaction, not the matching. Obviously, in a real product you want to optimize the matches that happen on your site, but for a true MVP, you just need to figure out if it answers the human side of the equation: the interaction, before you optimize the machine side. By Friday, I had a site that actually followed the workflow of a dating site.

The problem was, it still looked like a recruiting site.

The most important part of an MVP is that it needs to feel like a real product. It can be crap on the inside (and believe me, this product was a hodgepodge of hacks, improvisations, and plain old guesses on the inside), but, again, MVPs are about validating the human side of the equation. Will this product match what a human wants out of it? And to that end, it needs to feel real. So, I knuckled down over the weekend on design. I picked Imprima for the font as it has a nice, clean, sans serif feel, with a hand-written twist. I found a nice background on Subtle Patterns and played around with the color scheme to make it feel more Cupid-like.

And you know what? It actually looked like a dating site. It felt like a dating site, but could it actually handle demo day? I was fully prepared to spend the entirety of Life 3.0 huddled in a corner, casting spells of 'resurrect server' through the evening, but it actually handled the load quite nicely, which just goes to show you how useless premature optimization is.

I think MVPs are sometimes hardest on engineers. We're naturally lazy and therefore predisposed to the philosophy that if it isn't worth doing right, then it it isn't worth doing at all. However, this turns out to be wasteful as evidenced by the the countless engineers who spend their weekends working on over-designed, under-validated side projects that are never going to get off the ground.

Yes. The demo that I created for Life 3.0 was a monster an adventure, but, you know, life is too short to work at a boring company.

]]>
Chris Burnor
tag:chrisburnor.com,2013:Post/582018 2012-06-01T12:00:00Z 2013-10-08T17:25:59Z App Specific Settings for Django

While Django encourages a healthy degree of decoupling in how apps and modules are structured, the settings file can very easily become a monolithic mess. There are some good resources for how to divide up settings file between environments, but with a big application, even that can leave you with a mess of configuration settings.

What is particularly annoying in this situation is that many of these settings really just affect one app. For example, I store JavaScript and CSS files specific to each app in app_dir/static/ and then use django-pipeline to wrap and compress all the files for deployment. However, Django Pipeline requires you to define Groups in your settings.py file. However, since those groups are specific to each app, it seems like they should live with the app, not in the settings file. Adding a css file shouldn't require me to change the settings.

At first I attempted to fix this by putting a settings.py file in each app's directory, but Django doesn't automatically import those files and attempting to do so manually in Django's own settings files lead to all sorts of messy import loops. However, I found a much simpler solution. Simply put the extra settings in the __init__.py file in the app root. This get's imported automatically when the app is installed and those settings will automatically be added to the general settings environment.

]]>
Chris Burnor
tag:chrisburnor.com,2013:Post/582017 2012-04-30T12:00:00Z 2013-10-08T17:25:59Z Do one thing (at a time) and do it well

The Great Law of Unix and its progeny is to do one thing and do it well. Although Unix programs may have great complexity, they are focused and modular. This has certainly lead to the amazing success of Unix, BSD, Linux and other *nix operating systems in the tech world, but I think that this law is more generally applicable than simply 'how to write Unix programs.'

My previous post is, in essence merely a re-statement of this law. When pushing a release or change to your product, keep your focus. It is far better to make a few changes that will make a big difference, than lot's of meaningless fiddling (Though don't forget that big and little changes should be measured on their effect on the user's experience, not how much effort they require).

I learned this lesson again today when I was working on my Arch Linux install. I use LinuxMint for my day-to-day computing, but, in the interest of learning more about how Linux is built, I've been slowly working on getting a usable system on my second partition. Like with code releases, one thing I've learned is to not try to change too much at once. My initial plan was to build the entire system from scratch in an extreme minimalist style (OpenBox, SLiM, Chrome and a Terminal) but I quickly found that there is a great deal more complexity in doing that than I had anticipated and I've had much more success since switching to XFCE and more 'mainstream' technologies.

Some day I will probably reduce my system even further, but for now, I've learned that minimalism is a process of taking away more than it is a process of adding the minimum amount possible.

]]>
Chris Burnor
tag:chrisburnor.com,2013:Post/582016 2012-04-24T12:00:00Z 2013-10-08T17:25:59Z Deployment and Tools Guide

This isn't your ordinary guide to deployment and tools. As a matter of fact, this is somewhat of an anti-guide -- a guide on how to approach tools and deployment -- rather than a guide to any specific approach. I was inspired for this by a post yesterday to Hacker News by Hynek Schlawack on Python Deployment Anti-Patterns and other tools used in doing Python web development. The article and associated discussion on HN are both excellent and I highly recommend a read.

However, I often find that articles and resources like these can actually be quite counterproductive to my as a developer. I look at these lists and think to myself, "Oh no, I'm not using all of the best practices! I should switch over my development stack to ensure maximum scalability and stability for the long term." Then I spend several hours researching the tools, reading tutorials, reading docs, messing with the server, probably breaking something, fixing it and generally coming back right back to where I started with maybe a few tweaks to my process.

The problem with this philosophy is that it's a bit like putting an air spoiler on my Honda Accord. Certainly the right spoiler, air-filter, tires, etc will make improve the performance of my car, but right now, I need to focus on getting to work and shipping a product. Playing around with a deployment system for a massively distributed system is pointless when you're building out your initial product and trying to nail down the core feature set and build a customer base.

However, sticking with what you know and never moving onward is a surefire recipe for stagnation and boredom as a developer. I got into technology because I didn't want to be bored and I wanted to be pushing the limits of what I can do and I want to have a solid stack and is up to date and using current best practices. There is usually a reason why smart, successful people are developing and implementing such practices.

So here has become my approach to keeping up with best practices and scaling up my applications, while not wasting time with pointless Yak Shaving: one new deployment feature per deployment. Instead of trying to build out the perfect stack from the beginning, I take what I currently have, and know and try one new thing. Maybe I switch to RabbitMQ instead of Redis for message passing. Maybe I use Supervisord instead of upstart for process management. Whatever it is, I optimize for one big improvement to my workflow per big improvement on the user side. This way the stack and architecture grows and improves as the interface does. The additional advantage here is that as I get more comfortable with these technologies, I start to think in those terms and start to build them into my projects from day 1.

]]>
Chris Burnor
tag:chrisburnor.com,2013:Post/582015 2012-01-02T06:24:00Z 2013-10-08T17:25:58Z Ode to the Little Stuff

This past week I had finished a big project for my work and was trying to decide what to build next. We had discussed several major new projects that included a major overhaul of one of the core interfaces to our application. However, instead of starting that, I took some time to fix a bunch of nagging little bugs that had been bothering me (and our users) for some time.

Now, you might say, “But Chris, what about the lean startup approach? What about the Minimum Viable Product? Aren’t you guys supposed to be a scrappy startup? Well, yes…

But…

Don’t forget the little stuff. It represents your biggest opportunity to get maximum impact for a minimum of effort. Yes, I could have re-architected our front-end stack to implement new features, but fixing bad copy, broken CSS and a poor user interface served our customers far better than that would have. The key word in MVP is viable. It isn’t just a minimum product; it has to be one that validates and implements (successfully) your business model. Otherwise, it’s just junk.

There is a second reason to think about the little stuff: putting the user first. Sometimes, it is tempting to fall into the trap of wanting to take out a new canvas and make big, bold strokes to hit your targets. Certainly, not falling into ruts is a key startup success trait. However, by taking what you have and re-focusing on what about it is broken, you get much closer to a workable product than constantly starting over. A good engineer doesn’t start over their project from scratch every time they find a mistake. A good engineer fixes it and refactors it into a good, workable product. The same holds for designing your product. Making it better is more rewarding and more beneficial to your users than starting over.

]]>
Chris Burnor