A Battle With The Beast

If you know me well, you are probably aware that I periodically suffer bouts of depression.  Tonight, as I was driving home from hanging out with some work compatriots, I was suddenly assaulted with that familiar feeling of onset.  When it happens, it is almost always over some small or insignificant thought which plants itself like an invasive seedling in my mind and proceeds to blossom into a festering tree of gloom and self-abuse.  Despite knowing that this process is happening, I frequently find myself unable to cut it down before the thoughts take root.  Tonight I thought I would try something a little different.  Rather than sitting idly by and letting the fight unfold inside my head, I will spill it out here for the world to see.  Perhaps my obsessive attention to detail and eloquence in my writing will make a match for the equally tenacious thoughts attempting to drag me down.

To set the stage for those unfamiliar, let me describe what these episodes entail.  It all starts with a tiny event, something mostly meaningless and insignificant that I should gloss over within a few minutes.  In fact, most of the time, I would; other times, more sinister events ensue.  The thought stays with me, burrowing deeper and deeper into my mind.  By this point, I know what is happening, and I try to force myself to think of something, anything else.  If I am not successful in this effort, then I am sealed into my fate for the next few hours or more.  Pernicious little thoughts needle me constantly, digging up every negative concept of myself that has ever passed through my brain.  I try to beat them back, but this is akin to swatting individual locusts in a swarm.  Eventually I just give in, and let them wash over me, doing my best to become numb.  Typically I nap or sleep for the night, and wake up feeling completely normal, these negative thoughts banished from whence they came.

Even as I type out this narrative, I find that I cannot convey in words the depth of the feeling that subsumes my reality when the depression sets in.  I’ve read extensively on the subject and I find that this is a common problem.  Sufferers find it difficult, if not impossible, to help non-sufferers understand what it is really like to experience depression.  Healthy people often say things like “remember that you control your own destiny” or “just don’t think about the bad things in your life, dwell on the good things.”  This, though, misses the awful, dark evil that is the true spirit of depression – it doesn’t just make you feel sad, it robs away your power to take exactly the steps you must to feel better.  Sufferers, such as myself, frequently know exactly what they could do to feel better but are bound within their own minds, unable to make the correction.  This is why many people turn to medication, prescribed or otherwise.  Medicine alone cannot bring happiness, but it can at least equip the imbiber with tools to beat back the beast of depression.  I have employed this technique in the past, but found that the medicine drowned other parts of my personality that I did not wish to lose; I felt no valleys of despair, but neither did I feel peaks of elation.  So, I battle the beast on my own, using only the tools I can prepare myself.

The good news is that this does work.  Difficult as it can be to fight a monster which by its very nature handicaps you, it can be won like any other fight.  The trick is to roll with the punches and play to those strengths you are left with.  As soon as you feel the onset of the dark shadow, you do anything at all that you can muster the will to do (maybe write a blog post).  Most importantly though, the real secret to a rumble in the depression jungle is to keep friends close.  Talk to someone understanding and let them know what is going on.  Don’t dump all your problems on them, but have as cheerful a chat as you can to distract yourself.  Every blow struck against the beast drains the power out of it and back into you.  And, I find, once you show you can fight back, the monster will slink back into the night, maybe not gone but at least defeated.

Richard’s Memorial

I delivered the following speech at my Uncle Richard’s memorial this weekend.  He passed away on January 24, 2013 at the age of 58, while skiing in Colorado.

“To laugh often and much, to win the respect of intelligent people and the affection of children, to earn the appreciation of honest critics and endure the betrayal of false friends, to appreciate beauty, to find the best in others, to leave the world a bit better, whether by a healthy child, a garden patch…to know even one life has breathed easier because you have lived. This is to have succeeded!” This Ralph Waldo Emerson quote encapsulates my approach towards life. Though I did not know him as well as I should have liked, I can say confidently that by this metric my uncle lived a life of success beyond measure. He demonstrated intelligence in every aspect of his life, through his stellar education, his rise through the ranks in his career, and his dry, sardonic wit. Though it could be hard won, I can still hear the sound of his laughter in tribute to a worthy joke. His appreciation of beauty was beyond question; I’m sure many of you know he was a lover of nature, especially fond of birds, as evidenced by his beautiful photography and artwork. He raised two highly intelligent, passionate, and successful children with his wife, my aunt.  He grew beautiful garden patches, where ultimately a piece of him can remain forever. Though Richard has departed us, he leaves behind not one but many, many lives that have breathed easier. His passion for life and dedication to his chosen path was obvious even to those of us who, like me, made his acquaintance less than they might have liked. Even still, I can be unwavering in this certainty: Richard left this world more than a bit better than he found it, and his absence leaves it significantly more empty.

I have precious few personal remembrances of my uncle. When I was young, our families visited often, but sadly, I am not blessed with a brilliant memory of my childhood.  As I grew out of youth our two families found less and less time to spend together, until a visit became a rare occurrence.  Time passed and I grew to be a young adult, moving away from home, graduating college, and beginning my own career.  My cousins, Erica and Evan did the same, and Richard and Eileen achieved retirement.  This once again opened the window of opportunity for visits.  Over the last several years I got a chance to know my uncle as an adult, and I am very grateful for that time, short as it was.  I remember him as a man strong in both reason and intelligence, passion and humor.  On my last visit with him, in October of last year, when he and my aunt visited my town of Santa Barbara they took me out to dinner and we had a wonderful discussion about the state of American politics.  Though we certainly had our differences in that arena, we shared a passion for reasoned debate, and respect for a conclusion intelligently found, if perhaps not agreed upon.  This is something I greatly admired about my uncle; though he held his opinions strongly, he was willing to consider a well-presented opposing view.  Conversely, he brooked no nonsense and never missed an opportunity to apply his acerbic wit to those who rightly deserved it. This, too, is something to which I aspire.

Shortly after graduating college, my family and I had a chance to visit with the Stades and my grandmother at the lake house they owned for some time.  This is one of my very fond memories of recent years.  We enjoyed a few days of sun and relaxation, as well as sumptuous family feasts and mellow evenings of thoughtful conversation.  During the day, Richard and Eileen took us out on the lake in their boat, patiently teaching me to waterski and even letting me drive it around a bit.  I got a chance to experience my uncle’s ornithological passion first-hand, as we tried to sneak up on a nest of birds for a chance to photograph them in their habitat.  In the evenings, after dinner, Richard introduced me to his aperitif of choice, a honey-whiskey blend by the name of Irish Mist, which to this day remains my favorite drink for a quiet evening at home.  And when at last, it was time to go, Richard thanked me for visiting, and bade me return whenever I so desired.  This, to me, was Richard Stade.

I wish that I had more frequently taken him up on his offers of hospitality.  I sorely regret missing the opportunity to learn more about him, to spend more time in spirited discussion with him, to laugh with him, and learn from him.  I suppose this is common to all losses, but especially those which are so sudden and unexpected as his.  The night I learned of Richard’s passing, I wandered the streets of Santa Barbara in a fog, both mental and literal, trying to find a way to integrate this news into my mind.  I walked past some of the locales I had shown him and Eileen on their last visit, sometimes smiling at remembered conversation, but more often numbly remote.  Eventually I ate dinner and made my way home, and there I did the only think I could think of to do.  I poured a glass of Irish Mist, thought of my uncle, and raised it in remembrance of him.  I think that this is the best thing we can do to honor Richard: remember him.  And, perhaps, to breathe a little easier because we all knew him.

Beginnings and Endings

For every place we inhabit and every person we meet, there will always be a last visit.  It may be one last wistful glance over an apartment or house that has held, nourished and comforted for many years; somewhere that was both a temporary residence and the home of homes.  It may be a college campus or classroom, or workplace or cubicle, a local haunt like a coffee shop or bar.  It could be a fight with a girlfriend, a tear-fractured gaze into the wizened face of a passing parent, or even a careless goodbye to a friend killed in a cruel but all too common twist of fate.  One of the harsh facts of the human condition is that we must say goodbye.  The people and places we’ve loved and hated will soon depart our consciousness, whether by their leave or ours.  We need not embrace or desire this reality, but at least come to accept it.

This is the inevitability that I experience when newness comes upon me.  When I make a new acquaintance, and begin to pass that awkward phase of unknowing, into the territory of the friendly and familiar.  While others revel in the joy of novelty, I live in the dismal future, knowing that one day this inevitability must come to pass.  The crackle of a new bond shoots through the air, electrifying it and energizing the participants; I smile, but look past it, knowing that this beauty like others before it must wither with the grating presence of acquaintance and acclimation.  With good fortune this may be a great length of time, extended by disparity of experience and uniquely bonded personality.  But, humanity is fragile.  Someday either life or death will tear us apart.

Much the same is true of the locales we inhabit; the cities, states and countries we choose to live in, the residences and workplaces that constitute our homes.  Even those places we frequent, the coffee shops, bars, bookstores, restaurants, that form so much of who we are and what we experience.  With places, a person need not fear so much that the other will grow away and take a direction of their own.  Places remain much the same.  With places, we think more on the experiences we have within them, the lives we lead and the memories that become imprinted within their walls.   We humans have a peculiar spacial memory that can leave nasty scars or beauteous dreams upon an otherwise plain piece of scenery.  I kissed the first woman I loved on that couch, I committed my worst sin in that apartment, I found the true direction of my life while laying on that beach and looking up at the stars.  Human experience happens in both time and space, and while we may struggle with the temporality of our existence, we show an exquisite talent in tying a life lived to its fateful locations.

And yet, there comes a time when we must be separated from these islands of meaningful reality.  Who is to say when this day may come?  Some events may be forseen, such as closing and locking the door on a leased apartment that has been the first true home you ever felt as your own.  But tell me: what will be your last visit to the town you grew up in?  When will be your last visit to a restaurant, a library, a park where you enjoyed the bright gaze of the sun from the shadow of a giant oak?  Maybe you will know this place is being torn down or that you are on your way out; more likely, you will visit such a place, with every intention that you will someday return.  It may be a small lie you tell yourself, to make the terrible parting that much easier.  It may be that it simply never happens; you become to busy with your spouse, your child, your job, your life.  Someday, you will leave every place you have ever been, and never return to it.

These are the things I think about, as I encounter new experiences in my life.  In a way, it distances me from them, reminding me that while it is new now, it must end someday; in a way, it brings me closer.  I can never forget that everything I experience is a ticking clock.  I can never take a thing, a place, a person for granted because I know that one day by death or life, it will all fade away.  It may sound tragic or horrible.  I cannot argue with that assessment and still be honest to myself, but there is a better, stronger effect.  It reminds me that I am alive.

Print Something For Justin – The Results

Well, the results are in, and you can see them for yourself!  I’ve posted a public album on Facebook with scans of all of the print jobs that came in.  Some people were a little better about concealing their identities than others (you know who you are), and I have guesses as to some of the senders, but a few of them have me mystified.  I declare this experiment a success.

Print Something For Justin

I have recently acquired a new printer with a neat little capability, so I’ve decided to conduct a little social experiment.  The capability I’m referring to is ePrint, which allows printing by sending an email.  I send an email to a special address and voila, it pops out of my printer.  It works with regular emails, but it will also print attached documents and images.  It’s an awesome little perk that allows me to print something at home, even when I’m not there, so that it will be ready for me when I arrive.  It is also compatible with Google’s Beta service, Cloud Print.

So, here’s the experiment: send an email to [redacted] to print something to my printer anonymously.  Normally, the printer email address is locked down, so that it will only print for emails sent from my email address.  However, I have deactivated this setting, so that the printer will accept jobs from any email address.  Because the purpose of the technology is to print a document as though it were a normal printer attached to the computer, it doesn’t include any sender information in the printed document.  Because of this, I will never know who sent each print job.  I will leave this setting unlocked until Saturday, March 31st, after which I will lock it down again.  At the end of the week, I will write about the results of the experiment, and post some of my favorite prints.

tl;dr Send an email to [redacted] to anonymously print something out on my printer!

The Separation of Church and State

Recently, I have been having a civil disagreement with a coworker.  The conflict is as congenial as it can be, because he and I respect each other and neither wishes to inconvenience the other.  Sadly, the difference seems to be intractable between us.  Because, you see, the difference is an argument over coding standards.

Standards serve a very important purpose in a software shop of any size.  Any time two or more developers work together and will be reading one another’s code, it helps to have a common vernacular.  See, software languages share many features of human languages.  Languages can be spoken correctly with many accents.  Most languages develop idioms to efficiently express a complex idea to speakers, while being impenetrable to outsiders.  Complex sets of grammatical rules are created to govern the use of languages, and denote not only what is correct, but also what is proper.  Code standards are those rules for software languages, and they allow developers to communicate more efficiently.

However, standards must walk a delicate balance between guidance and dictatorship.  Standards are created with the principle goal of better code quality and to ease the burden of working on another developer’s code.  There must be some base agreement as to what these standards are and an agreement to enforce them, or the standards will be meaningless.  However, standards must be crafted carefully to not be so authoritative that they become aversive to the developers they are meant to serve.

Developing standards can be very difficult though, because many coders do something in a certain way simply because it feels right.  This may mean that they simply have never considered doing it any other way, but would be open to learn better methods.  Sometimes there is a strong argument in favor of one style over another or one method is widely regarded as “best.”  In those cases, a good group of intelligent developers will consider the facts and evaluate what is best versus what makes sense for the situation.  Sometimes, everyone just agrees on a point right off the bat, and you can move along to the next thing.  However, sometimes there are conflicts that come down to purely semantic differences, like using “you are” instead of “you’re.”  A grammar purist might tell you that “you’re” is a bastardization of language that encourages informal writing and thinking; a layperson might tell you they find “you’re” to be easier and more convenient to use, while conveying the same meaning.  Neither of these people are wrong, they simply have different styles and preferences.

The problem is that in software development, there is a tendency to regard one’s own coding style with an almost religious awe.  Sometimes the only real argument is that something feels wrong.  In the absence of any strong tangible benefit that one method provides over another, it is perfectly valid for a developer to cite their gut feeling as an objection.  It may seem silly initially, but if you have to spend hours and hours writing code that just feels wrong to you, you’ll understand why it’s valid.  It’s as though you are being asked to follow the tenets of a belief system that is contrary to your own.  If you are a wise and respectful person, you may recognize that the belief system is a valid one.  But it will never feel right to you.

This leads me to the point of this post.  Coding standards are a form of governance, most effective when of and by the people.  Individual coding styles may loosely, I think, be described as a belief system.  To be effective and fair, governance must make an effort to be separate from the individual belief systems of the governed.  It must create a set of common laws by which we can all abide, in order to maintain a coherent society.  But government must also know when to step back and allow its people to maintain their minor differences.  In developing coding standards, we must endeavor to do the same.

What Do You Do?

As someone who self-identifies as a software developer, when someone asks me what I do, there is a tempting and obvious answer.  I write code.  I gather requirements from business users, I consider a variety of factors going into the development such as data sources, type and style of User Interface, need for future maintenance, available resources, etc etc etc.  When all the information has been gathered and all the angles considered, I take all of that and teach a computer to do what people want it to do.  I write code.

None of that is wrong and that description is technically correct, but that is not what I do.  In fact, it is the technical correctness of the description that causes it to fall so short of describing what I actually do.

Tonight, I went to see a lecture given by Sir Ken Robinson, a renowned thinker on the topic of education and creativity.  I could fill a whole blog post with his amazing and inspirational thoughts on the subject, but I do have a specific point here.  During his talk, Sir Ken touched on what he saw as one of many wrong-headed approaches to education.  Bad teachers, he said, teach English, or Math, or Music, or Physics; Good teachers teach students.  It’s a simple concept, but it really struck home for me.  Sir Ken’s point was that our current educational system is focused on teaching to tests, or subjects, or an idea of “what kids need to know to be successful.”  Instead he (and I) think that the system should focus on the student; what are they interested in, what are their passions, what will make them want to learn?

This is an amazing idea, but I saw another lesson to be learned from the example.  In this little parable, the educator has lost sight of the true and laudable goal of educating a child and preparing them for the world.  They have become lost in a specific implementation of this goal that has pervaded western educational models for nearly a century.  The implementation (teaching specific subjects to all students) has now become the end in itself, rather than the means to the end of educating students.  As any software developer knows, this is a dangerous position to be in.  Your business needs become lost in the needs of the software, productivity and understanding drop, and you now have a tool that not only does not do its intended job, but may actually work against your purpose.

All of this comes back around to my original point.  When someone asks me what I do, I used to tell them that I write code; now I know better.  What I do is help people.  I help my business staff do their jobs smarter, more efficiently, and more happily.  I help our users to navigate the complex systems of the university with streamlined and intuitive web applications.  I help the university become a better place for scholars, and the staff who support them.  I do write code.  But that is not what I do; that is how I do it.

So I’ll ask again: what do you do?

Dissecting Architecture Astronauts

Recently a co-worker of mine prompted me to re-read Joel Spolsky’s 2001 article Don’t Let Architecture Astronauts Scare You.  Now, it’s not really fair to go arguing with an article from over 10 years ago, but in my defense, I’m bored.  Some of this will probably get a little nit-picky, but I think each section is a valid point.  Here goes.

Something about this article struck me as not quite right. Joel essentially posits that people who think about large-scale system architecture, and the technical details of them, are missing the point. He’s not flat-out wrong: people who are trying to produce a functional system that they will be giving to customers should be more concerned about what the system actually does than its architecture. But he also says things like this:

“These are the people I call Architecture Astronauts. It’s very hard to get them to write code or design programs, because they won’t stop thinking about Architecture.”

To me this is a little like saying “Damn those [actual] architects! Why do they spend all their time studying the concept of buildings and drawing up lots of fancy pictures of buildings? Why won’t they go lay some brick and mortar and be productive?” In other words, the issue is not so much “don’t be an astronaut architect” as “your coders and architects should not be the same people.”

Beyond that, not a single one of his concrete examples was convincing (to me). Let’s review:

Napster & BitTorrent

The Architecture Astronauts will say things like: “Can you imagine a program like Napster where you can download anything, not just songs? Then they’ll build applications like Groove that they think are more general than Napster, but which seem to have neglected that wee little feature that lets you type the name of a song and then listen to it — the feature we wanted in the first place.”

I’ll grant that Napster’s ability to instantly get a song just by typing its name was a very important part of what made it so popular – but it was not THE feature.  Joel himself has missed the point here: the key was the ability to instantly get a song for free.  If you doubt me, try to remember the last time you heard someone talk about downloading something on Napster.  It was probably somewhere around July of 2001 (~3 months after Joel wrote is article), when the free version of Napster was shut down.

On the other hand, think about a program like BitTorrent.  It’s infinitely less user friendly than Napster was in its heyday.  You certainly can’t just type in the name of a song and then listen to it.  You can’t even download anything without first using a completely separate program (usually a web browser) to find a torrent file!  However, 1) it’s free and 2) you can download anything, not just songs.  This is due to the fact that BitTorrent consumes a generic, abstracted protocol (the torrent) concerned with transporting the most generic of all data, bits.  It doesn’t care if these bits comprise a song, or a movie, or a book; they are just bits, in a specific order.  That sounds suspiciously like what Joel was mocking his Architecture Astronauts for thinking of.

Hype

Joel goes on to list a variety of architectures, and then says this:

I’m not saying there’s anything wrong with these architectures… by no means. They are quite good architectures. What bugs me is the stupendous amount of millennial hype that surrounds them.

Fine.  That’s a fair point.  Except that doesn’t actually have anything to do with software design.  Please forward these complaints to the marketing department.

Services

Remember that the architecture people are solving problems that they think they can solve, not problems which are useful to solve. Soap + WSDL may be the Hot New Thing, but it doesn’t really let you do anything you couldn’t do before using other technologies — if you had a reason to. All that Distributed Services Nirvana the architecture astronauts are blathering about was promised to us in the past, if we used DCOM, or JavaBeans, or OSF DCE, or CORBA.

A couple of problems with this.  First, Joel seems to be arguing that if you can solve a problem, in any way, with an existing technology then there is nothing interesting about a new solution to that problem.  Technically, yes, you can create a distributed services platform with CORBA.  Would you want to?  You can perform complex calculations on a slide rule, why on earth would you want a graphing calculator?!  Second, once again we find Joel mocking architecture astronauts for proposing something that is now a very important concept of software design: “Distributed Services Nirvana.”  The Cloud would like a word with you, Joel.

Fast-forward to 2008

As I mentioned in my intro, I feel a little guilty for picking on a decade old article.  Fortunately, in doing a bit of research for this post, I dug up another more recent article of Joel’s.  In Architecture Astronauts Take Over (2008), Joel continues his tirade against the evils of high-level architecture.  Excellent!  That means I can continue my tirade against Joel’s tirade.  Now, to be fair this particular article isn’t so much about architecture astronauts as it is a long-winded complaint about Microsoft and two of its products, Hailstorm and Live Mesh.  Those are fair complaints – I’ve been working at a .NET shop for almost 5 years now, and I had to look these up to find out what they were.  But once again, Joel is using specific cases to tentpole his overarching theory about astronauts.  And once again, his theory looks good, as long as you only look at the bad examples.

The Cloud

Underneath his complaints about specific Microsoft products, you can catch a glimpse of Joel’s real point.  In summary “The Cloud is not something people want.”  In asking the question “what is Live Mesh,” Joel says the following:

“Imagine all your devices—PCs, and soon Macs and mobile phones—working together to give you anywhere access to the information you care about.”

Wait a minute. Something smells fishy here. Isn’t that exactly what Hailstorm was supposed to be? I smell an architecture astronaut.

Just as he loves to do, Joel has taken a useful, desirable concept and dismissed it out of hand by pointing to one or two terrible implementations of the idea.  Again, I don’t disagree on the specific case.  I am a huge fan of many Microsoft products, but they definitely do have a tendency to be over-engineered, bulky, and frequently not very usable in their first few iterations. That does NOT mean that no one should attempt to solve the problem that Microsoft is trying to address.  Does anyone think that Apple is going in the wrong direction with iCloud?  Should Google stop developing services like Google Docs, Google Calendar, or GMail?

Perhaps even more damning, Joel goes on to say this:

When did the first sync web sites start coming out? 1999? There were a million versions. xdrive, mydrive, idrive, youdrive, wealldrive for ice cream. Nobody cared then and nobody cares now, because synchronizing files is just not a killer application. I’m sorry. It seems like it should be. But it’s not.

Anyone who has ever used an application like Dropbox knows exactly how preposterous this claim is.  Now, at the time Joel wrote this article his argument might have held a little more water.  The proliferation of mobile devices hadn’t really begun to occur yet.  Modern smartphones were just starting to get off the ground (I keep having to remind myself that the iPhone only came out in ’07) and netbooks were really only an early concept; tablets existed, but each implementation was more laughable than the next.  You were basically limited to a desktop or a laptop, so having all your devices synchronized wasn’t as big of an issue.  Normally I would say something like “no one can predict the future” – but that’s part of a technology professional’s job.  Syncronization is now not only a killer app, it’s THE killer app.

Wrapping Up

I want to be very clear about this: I have tremendous respect for Joel Spolsky.  He’s a very intelligent man, and his work shows it.  He co-founded StackOverflow (and eventually the StackExchange network), which I consider to be THE place to go when I want to figure out how to solve a software problem.  He also co-founded Fog Creek, where any self-respecting developer would kill to work.  More importantly, I don’t totally disagree with his point about Architecture Astronauts.  When you are building a complex high-level architecture, you must be extremely careful to solve a real problem that is useful to someone.  The higher your level of abstraction, the more you should check, double-check, and triple-check yourself to make sure that what you ultimately produce will be a product.  If you are not careful, what you’ll get instead is essentially a very expensive solution to brainteaser.

Here’s the important distinction: that does not mean you shouldn’t try to solve the problem anyways.  Just make sure you are solving it for someone and doing it better than anyone has done it before.