Fear and Coding

There exists in the technology world today the myth of the glorious failure.  The praiseworthy failure.  The gently notorious and spectacular failure.  Everyone should fail all of the time, right?  Companies should fail fast — fail well.  Fail in  a humorous way maybe, suitable for later rehashing over craft beer.  Not failing?  Push harder — you will.  To fail is to be epic and to learn.  Worstward Ho and all that.

“Fail better” is now experimental literature’s equivalent of that famous Che Guevara photo, flayed completely of meaning and turned into a successful brand with no particular owner. — Ned Beauman in New Inquiry

But when it comes time to  actually fail for real in the world of technology and business — particularly in the world of very large platforms with millions of users and millions of dollars at stake — I suspect that I am not the only software person who doesn’t find much relevance in the startup-era jingoistic kind of failure.  The fact is that we have basically managed to completely divorce ourselves from the psychology of what it means to thoroughly fuck up.  Moreover — failure sucks.   It’s excessively and inappropriately worshiped by people who work on the interwebs and build companies, but who (I suspect) do little of the un-sexy work that actually props up most of the web.

At my job, I’ve been tasked with a rather broad technical project which might be said to fall into the category of low reward, high risk.  It involves the underlying data structures and some of the hidden internal plumbing behind a product used by tens of millions of people every day.  A mistake on my part could at best introduce hard-to-find bugs,  or worse temporarily render parts of the product unusable for a short time,  or worse still corrupt some underlying data that would take a long time to restore, resulting in a wide outage.  Success, on the other hand, means that nothing (apparently) changes.  Status quo.  I’ve feared failure in this project.  I’ve really feared it.  I’ve feared that one day I’d start some script off running and realizing it was doing something horrible and then be unable to un-do it.

I think this kind of fear of failure has been useful.

It’s been fear that caused me to approach this sort of work with the caution it deserved.   I’ve been checking and testing all the code I write many times.  I’ve been allowing time for problems to emerge and others to weigh in before I move on to the next phase or task.  I’ve built redundant safeguards into the code so that data-destructive things that shouldn’t be happening have a vanishingly small chance of ever occurring.  I’ve slowed down and not pretended that every. single. thing. on the web or with people needs to happen at light speed.

I’m finishing up this project now, and it looks like it will have — not failed.  I’m glad I took it slow.  I’m glad I was afraid.

Fear and Coding

Coding in prison: Clallam Bay and UnLoop

On Monday I was privileged to join group of technology volunteers to spend the day at Clallam Bay Corrections Center in rural Washington State.  The trip was part of a program sponsored by UnLoop, an organization here in Seattle on a mission to build a pipeline of talent from prison to tech. It makes sense in the abstract right?  There’s a huge unmet labor demand in the technology industry.  At the  same time, we live in a country with almost unbelievable levels of incarceration.

Clallam Bay
Prison is the opposite of an abstraction.  To enter Clallam Bay, our group passed through no less than nine electronically controlled doors. We left the internet, mobile devices, the cloud, social networks and our own complicated virtual lives behind.

Screen Shot 2016-03-08 at 5.13.33 PM
Calibrating the robot
The workshop led by UnLoop was designed as an introduction to programming for students who had never coded before. By that measure, it was clearly a success — coding happened … lots of it.  We divided up into small groups, each a mixture of volunteers and participants from the inside, and hacked away at moving around little robots.  The time sped by.

But for me there was more to it.  While I’d heard about the prison’s programming class before the trip, but what I wasn’t prepared for was meeting its senior students.  These were folks who had spent a year or two of their lives learning to code. Several men had written complex video games from scratch.  Some had mastered non-easy languages like C and C++, and were moving on to C#.  Several had learned entire web stacks without the benefit of Google, Stack Overflow or anything else.

I met several developers inside who — incarceration aside — could walk in to most technology interviews in Seattle and end up getting a fair, stable job offer.  Right now this is clearly still a dream — the barriers to employment are serious and many.  But at least from the industry side, they are artificial.

I went to prison carrying nothing but emerged with a new burden, a new vision.  To build a prison-to-tech pipeline, we need only start judging developers by their ability and desire, and not just their history of incarceration.  We need rational strategies and perhaps new enterprises to build willingness, ensure security and  encourage stability.  We need to do all of this because it’s right and just — this is a problem, and we can solve it.

Most problems are opportunities.  And there a few greater opportunities than an artificially under-utilized resource.  The results of allowing incarcerated or formerly-incarcertaed developers to do what they were clearly put on this planet to do will be not only good, but profitable —  in every sense of that word.   More justice, more stability, less recidivism.  More innovation, more utility, more dedication and yes more profit.

Want to go to prison and see for yourself?  Contact UnLoop.

Coding in prison: Clallam Bay and UnLoop