Theory & Logic

How to Lose Friends and Alienate People

Fri, 23 Mar 2012 16:36:00 -0400

Communication is complex. It requires more than just words to be truly effective. Intonation and inflection are completely lost in the translation to digital form and misunderstanding happens in their absence.

I get more frustrated every day with the terse, cold nature of electronic discussion. I need a cleansing period. As of today, I am removing myself from all personal online interactions by going dark for the next month. I can’t go 100% offline because I work remotely, so communicating with my coworkers will be the one exception.

If you are weird enough to desire my presence, give me a call. Or just show up at my house.

Armchair Activism and the Misconception of "Good Enough"

Fri, 23 Mar 2012 16:34:00 -0400

Twitter has an immense ecosystem with incredible diversity. There are accounts for everything and for all types. Many people stick with a single theme and run with it. Comedians never break character; activists fight the good fight; others simply lament over or sing praises about their daily lives. It has helped launch fledgling businesses. It’s been wielded as a powerful weapon against social and ethical injustices.

To me, Twitter is a great outlet for satire. I’m not a spokesperson for a company or in a position of authority or leadership so I don’t censor myself. Rarely do I tweet about anything serious because those messages are almost universally ignored. Sometimes I’m just making up for my unusually timid real-life personality. But most of the time I use it to be provocative and to learn about how my audience responds. My own social experiment.

I have been very interested in the effects of social media on the efficacy of activism, and I’m concerned that our improved ability to talk about problems is replacing our reason to do something about it.

One cannot deny that the Arab Spring was aided in part by social networks like Twitter, but it was not tweets of solidarity alone that overthrew corrupt governments. People fought back in the streets and paid dearly, sometimes with their lives, to achieve the change they so deserved.

The outcry against SOPA and PIPA helped dismantle legislation that would have stripped the Internet of the freedom that gave it life. Without a strong media backlash, the support of affected major corporations, and tens of thousands of letters to public officials, these bills may not have been overturned.

The KONY 2012 campaign is just the latest. What will come of it?

On the issue of women’s rights, when companies use alienating stereotypes in their messages, a cacophony of angry voices is rightfully heard. It’s even more maddening when it happens twice in the same week by two different companies, Sqoot and Geeklist, and in the same industry, no less. It should be outright frightening because these incidents are just the tip of the iceberg.

There has been an alarming increase in violations against women, from marketing done in poor taste to blatant rights violations. The response to these moral issues has increased as well, this week being a perfect example of such. Yet the problem still exists, and if anything, it’s getting worse. Why?

Women are under attack. They are being treated as second-class citizens by the very politicians they elected to represent them. Men and women are different, yes, but only in physiological terms; we are all human and we deserve the same rights that every human can enjoy. For all the advancement of women’s rights over the last 50 years, we are quickly slipping backwards.

If men in male-dominated industries like technology want to encourage women to be involved, we need so much more than 140 characters. We must do something about it.

Gender inequality doesn’t start in the workplace. It begins at birth, where societal pressure influences us into our respective gender roles. To combat this, we must create opportunities for women from the very start. Where are the programming classes focused on young girls? Where is the Summer of Code for Women? Armchair Activism is simply not enough.

SOLID Principles for Operations

Wed, 21 Mar 2012 11:46:00 -0400

SOLID is a mnemonic acronym for five basic principles of object-oriented design, originally coined by “Uncle Bob” Martin. From Wikipedia: “The principles when applied together intend to make it more likely that a programmer will create a system that is easy to maintain and extend over time.” While SOLID is designed to help guide developers, these principles can be very much applied to operations as well.

Single Responsibility (SRP)

A server should have only a single responsibility.

When first starting out, it’s common practice to run web server, the app server, and the database server on a single host. While that may be an accepted practice for development (though, I would argue against it even then), your applications will become more complex in time and the tangled mess of servers will become a nightmare to administer.

Each server should have a single purpose. By separating responsibilities, your servers are easier to care for, your metrics are easier to parse, your infrastructure audits go much more quickly, and service disruptions can be greatly minimized.

Capacity planning is an absolute must for reducing infrastructure costs. Proper planning requires clear and well-defined metrics. Virtualize parts of your infrastructure where performance will not be degraded to minimize expenses.

Open/closed (OCP)

Servers should be open for extension, but closed for modification.

Once a server is provisioned, it should remain in the intended state until it is decommissioned. A server can be modified to correct errors, but adding new services or changing the functionality of a service means that a new server should be provisioned.

Adding new services to a server breaks the closed nature of the system, consequently increasing complexity and the time it takes to recover from failure.

Liskov Substitution (LSP)

Servers in an infrastructure should be replaceable with instances of similar types without altering the correctness of that infrastructure.

Servers are a disposable commodity. Never rely on providers to always have 100% uptime and never assume a server that exists today will be there tomorrow. Your application should not rely on a specific provider. It should not rely on a service that is only offered by one provider. Data that can’t be recreated must be backed up in a vendor-independent manner.

Knowledge should never be held by a single individual. The person responsible for a particular piece of infrastructure should document any and all information they have about it. Everyone on your team should be able to sub in for anyone else. They may not immediately know to resolve issues, but they should know where and how to find the necessary information.

Interface Segregation (ISP)

Many client specific tools are better than one general purpose interface.

Give your infrastructure the UNIX Philosophy treatment. The tools you use should do one thing and do it well. Your configuration management tool should only manage configurations. Your server provisioning tool should only provision servers. Your metric collection tool should only collect metrics.

Monolithic services force you to modify your processes to fit the service. Instead, use tools with single purposes and modify them to fit your processes.

Dependency Inversion (DIP)

Depend upon abstractions. Do not depend upon concretions.

Having your developers worrying about the underlying infrastructure is a needless and potentially dangerous distraction. Developers should not concern themselves with how much storage or memory a given system has. That doesn’t mean your developers should not understand or ignore the performance implications of their design decisions, but provisioning or configuring the systems they use should not be on their mind.

Provide your developers with a platform upon which they may deploy their applications; be it Heroku, Cloud Foundry, or even something home-rolled. Implement a simple interface with which they can deploy their applications and make the deployment process across multiple languages and data stores as uniform as possible.

In Practice

In smaller organizations where cost is a much greater concern, following these principals does pose a greater challenge, but it is not impossible. Never assume your organization will always remain small. Growing will be so much easier in the long run. Likewise, if you simply don’t have enough time or people to implement one or more of these principles, make it a goal to work toward while focusing on the principals you can implement.

Like all ideals, meeting them completely is hard. Our common goal shouldn’t be “good enough”; we should shoot for the stars and sacrifice whenever we must.

CHANGELOG

2012/03/21 - Added "In Practice" section

The Time I Got Arrested

Wed, 23 Nov 2011 16:52:00 -0500

It’s the summer of 2001. The sun is burning hot in the midday sky, the grass a most beautiful emerald green, and I just found my first love. It is a brown 1983 Buick Regal sedan with bench seats, a vinyl top, AM and FM radio, enough fake wood to re-panel a basement rec room, and shocks so ~~worn~~ amazing you’d have thought you were sailing a ship across a sea of clouds. In other words, this is one serious Chick Magnet.

$200 cash and it’s mine. What a deal! The person running the estate sale let slip that the dearly departed went to meet her maker in the front seat. Like I said: Chick. Magnet.

Where was I? Right, getting arrested.

I just turned 17. I had neither the mental faculty nor the legal authority to enter into sales contracts or other binding agreements with anyone. But this lady who now owned her grandmother’s car didn’t care. She just wants the garage cleared out and I am the one to help her do it. So without any official proof the car was legally obtained, she hands me the keys and sends me on my way. The lady promises me that this exchange is completely legitimate. Who am I to argue? I now possess a car.

I drive away in a car that is not legally mine, with no license plate, no registration, and no insurance (and I forgot my driver’s license, for good measure). To top it off, this car is also not technically road legal (we’ll get to that part in a bit). But it doesn’t matter. I just got my first taste of true freedom and I am hooked.

I make the only decision a 17 year old with a car could make. I drive to my friend’s house to show it off. 40 miles away. It’s during this trip that I learn driving a car with no rear-view mirror is a ticket-worthy offense. It is during this trip that I also learn driving a car registered to a recently deceased person with none of the aforementioned paperwork bears a striking resemblance to what some people might refer to as “Grand Theft Auto” [It is also where I learn never to accept legal advice from strangers -Ed.]

This car isn’t fast. Hell, this car can’t even reach the highway speed limit. And I, still oblivious to the fact that I am committing several crimes, cruise along at a grandmother’s pace down I-69. That is, until a state trooper with superhuman vision flags me down to notify me of the mirror issue. We pull onto the shoulder and the officer makes his way toward my car.

Surely, he wants to admire the beaded covers adorning these luxurious tweed-wrapped seats up close.

He requests the usual “license and registration”, to which I reply “Oh, yea, no… I just, uh, got the car today so I, um, don’t have any of that yet.” Dearest reader, please take note: while correct, this is the Wrong Answer™ to that question.

The officer excuses himself and walks back to his squad car. A minute barely had time to pass before he is back at my window, requesting that I “step out of the car please”.

I knew it. He wants to experience these seats for himself. He’s in for a treat.

Alas, this is where my story takes a turn. This officer of the law is not here to take in the fine American craftsmanship. He is here to place me in handcuffs and put me in the backseat of his cruiser. I am bewildered. He carefully explains every unlawful act I have just committed. Panic sets in. I feel cold steel pressing against my wrist bones. I sink down as far as I can, trying my best to ignore the pain and my inevitable outcome. He walks back to my car to search it further. I start imagining the former owner was a crime boss. Was the estate sale just a front? Why did they want the car gone so fast? Did they use this car to transport narcotics and weapons? It’s only a matter of time before he finds everything. I sit up for a moment to see what fate has in store for me.

I realize something. My girlfriend has been sitting in the passenger seat this whole time and the look on her face is hilarous. Having gone through every other possible emotional reaction, the only one I have left is laughter. So I laugh. Hard. I’ve gotten myself into some seriously ridiculous situations, but this so far takes the cake. I see her laugh. Then the cop laughs.

She corroborates my story. Finding nothing other than sheer stupidity, the officer releases me. We wait for the tow truck to haul away my brown beauty and the officer drives us to a gas station where I call my friend so his dad can pick us up. As the cop departs, he leaves me with wisdom I will never forget:

“Stupid people do stupid things. Smart people do stupid things only once.”

The concept is simple and uttered quite often. Learn from your mistakes. I sure made a lot of mistakes that day. I trusted a total stranger; I got myself handcuffed; I pissed off my mom in ways my older siblings could only dream of. Not repeating these things is a definite no-brainer.

Confessions of an Awkward Penguin

Fri, 15 Jul 2011 01:48:00 -0400

I have intense social anxiety.

I feel extreme discomfort when I am in a situation where I may have to interact with other people: grocery shopping; driving in traffic; going to the movies; even talking on the phone. My heart races, my hands get sweaty, and my head starts pounding. I can do pretty well with people or places I have known for a long time, but I am awful with new people and new situations.

If you know me personally, you are probably reading this right now, smirking and saying to yourself, “yea, right.” Remember when we worked together and I didn’t say a word to you for the first few months? You probably though I was a jerk or that I hated you because I’d never speak or make eye contact. I’m sorry about that. I did like you, I just couldn’t figure out how to say it. How about the time we worked retail together and you thought I was just avoiding work? Sorry about that, too. I was having panic attacks in the bathroom from all the customers.

Have you ever tried calling me? I never pick up because I won’t know what to say. Sent me a text? Even easier to pretend I didn’t get it. If you invite me somewhere and I decline, it’s not that I don’t want to go (I really do), I just wouldn’t know what to do once I got there.

The fact that I work from home only serves to exacerbate the problem. I do leave the house (once a week) and I talk to friends (indirectly over Facebook or Twitter). At least I shower daily.

I have no reason to act the way I do. I know I’m awesome. I know other people think I’m awesome. I am constantly reminded of all the people whose respect and admiration I have earned.

So why, then, am I so afraid?

I know that the only way I can fix this is by throwing my brain into a chokehold of anxiety until it cries “uncle”. There are so many things I know I can accomplish, and I am holding myself back. I hope, by putting this out here for everyone to see, that it will be harder to find reasons to close myself off.

The next time I give an excuse to not be social, call me out.

The Ideal Monitoring Service

Fri, 27 May 2011 01:21:00 -0400

The state of monitoring solutions has been on my mind for a while. Today, the #monitoringsucks hash tag became a trend on my local Twitter feed. I’ve been working on my own monitoring app as of late, so I was inspired to put to words what my definition of the ideal solution should look like.

It must be easy.

One of the bigger pain points of monitoring applications is configuration and deployment. Management systems like Puppet or Chef have made this easier, but it’s still far from a perfect solution.

Deployment should be a drop-in process. Plugins should be simple to write. The API should adhere to current best practices. The system itself should not use proprietary or esoteric pieces.

It must be extensible.

No two infrastructures are alike, and so the service that monitors yours should provide the freedom and the flexibility to instrument it as you see fit. The resources we want to instrument are different. Sometimes it’s a server; other times it’s an application. The system should make no assumptions.

It must be performant.

Monitoring is an incredibly critical component of a well-designed infrastructure. If a monitoring service cannot identify and alert us to problems rapidly, then it is of little use. The system must be able to keep up with any and all demand and be impeccably stable.

It must be useful.

The system should provide three distinct capabilities: the ability to observe, the ability to trend, and the ability to report. Metrics are a crucial part of being able to intelligently respond to an event. Trends help us discover weak spots that need fixing, or help us better plan capacity.

Reports are the most critical part, as well as the part most in need of an overhaul. What happens when a service fails? Who or what gets notified? How do our other systems react? The system should not only provide the typical meatcloud notifications, but also provide ways to interact with other systems.

Talkback

What makes a monitoring app good in your eyes? What are current offerings lacking?

"Programming is a science dressed up as art, because most of us don’t understand the physics of..."

Sun, 10 Apr 2011 23:55:00 -0400

“Programming is a science dressed up as art, because most of us don’t understand the physics of software, and it’s rarely if ever taught. The physics of software is not algorithms, data structures, languages and abstractions. These are just tools we make, use, throw away. The real physics of software is the physics of people.”

- ZeroMQ documentation

Bash SSH Tunnel Wrapper

Thu, 24 Feb 2011 18:25:00 -0500

I recently became the caretaker of a Chef server that sits behind a firewall, inaccessible to all but the nodes that require access. Even though it’s locked down, I still need to be able to administer it. My tool of choice is knife, the command-line utility used to interact with Chef.

I have SSH access to the box, so to use knife I only have to create an SSH tunnel:

ssh -T -f -N -L 4000:localhost:4000 dryan@chef.example.com

This works, but I don’t really want to manually manage SSH tunnels. What I really want is a wrapper that 1) creates the tunnel 2) runs my command, and 3) closes the tunnel. So I wrote a bit of Bash to allow me to do just that:


function create_chef_tunnel() {
  cmd='ps -eo pid,args | egrep "[s]sh -T -f -N -L 4000:localhost" | cut -c1-6'
  if [ $? -eq 0 ]
  then
    echo "SSH tunnel exists"
    return
  else
    ssh -T -f -N -L 4000:localhost:4000 dryan@chef.example.com
  fi

}

function close_chef_tunnel() {
  cmd='ps -eo pid,args | egrep "[s]sh -T -f -N -L 4000:localhost" | cut -c1-6'
  pid=$(eval $cmd)
  kill -9 $pid
}

function chef_tunnel_wrapper() {
  create_chef_tunnel
  "$@"
  close_chef_tunnel
}

alias knife="chef_tunnel_wrapper knife"

Surely, the above snippet could be made more re-usable. One could modify it to support specifying ports, hosts, usernames, etc, but I didn’t need it for anything else just yet. I’ll leave that as an exercise to the reader :)

Agile Book Development

Fri, 29 Oct 2010 08:29:00 -0400

My wife is a writer. She considers herself the aspiring variety, but I disagree. Anyone who can actually sit down and puts words to paper (digital or otherwise) is certainly a bonafide writer in my eyes. Writing is hard - really hard, and I respect the hell out of anyone who tries their hand at it.

I consider myself a developer, which is a different kind of writing altogether. Both types of writing exercise the same creative and analytical parts of one’s brain, but each has its own distinctly different approach to fleshing out an idea.

Authors write in solitary, often in long winding stretches just to get words on the page; they focus on the bigger picture first and then come back to reorganize their thoughts; they keep their work to themselves until they deem the project complete.

Practitioners of a style of programming called agile development team up together to solve difficult problems and learn from each other; they break up larger tasks into smaller, more manageable ones; they work on pieces of the bigger picture one week at a time; they release early and release often, and in the process they gain feedback and meaningful insight that enables them to better their work earlier on.

Not all developers follow an Agile philosophy, but the ones that do are more focused, have less stress, and get better work done faster.

Writers could learn a lot from this.

"Never, ever, write in a vacuum. Show your work to people: friends, colleagues, reviewers. Check with..."

Wed, 27 Oct 2010 10:53:32 -0400

“Never, ever, write in a vacuum. Show your work to people: friends, colleagues, reviewers. Check with your publisher to see how they want to handle this, but get feedback early, and get it often.”

- Dave Thomas

Tiered support? More like "tear'd" support.

Tue, 10 Aug 2010 21:18:00 -0400

Tiered support is a methodology commonly practiced by any institution that proffers customer service. When a customer calls in, they’re connected to a tech who can offer basic advice. If that tech cannot resolve the issue, the customer’s call is transferred to the next tier of techs that know more than the last. Rinse, repeat, until the customer is passed on to the tech that eventually solves the problem.

This is a horrible practice, and I know you already agree with me.

Remember how quickly your issue was resolved the last time you called a company for support? I didn’t think so. The first person you talk to is an unskilled, untrained, and woefully unqualified person who’s reading verbatim from a manual written by someone who knows what they’re doing; the someone you wish you could be talking to.

Step 3 is Profit

So why do companies use this system? It’s cheap. Hell, it’s really cheap. After all, they don’t make money from troubleshooting your issues. They make money from you paying for a product. Customer service is simply a business expense, and knowledgeable employees are expensive.

To put it plainly: spending money on helping you does not make more money, and therefore is not worth it.

“Did you try turning it off and on again?”

Companies would rather spend their dollars on advertising or other things that can make sales. Advertising will bring customers in, but it won’t keep them. Spend your dollars on things that will build meaningful, lasting relationships instead.

Don’t force them to navigate a byzantine menu. Give them a person after a few rings instead of hold music. Make sure that real person can do what your customer is asking for in the first place. They deserve it.

Throw tiered support in the trash where it belongs and start treating your customers like people and not a line item. Don’t just say their “call is important to us” — prove it.

The secret to a successful business, happy employees and a prosperous future

Thu, 01 Jul 2010 22:39:00 -0400

It’s money.

I know what you’re thinking: “Of course it’s money. Everyone likes money.” But it’s more complex than that. Just a wee bit more, not rocket-surgery complex.

Say you start a business. You make it far enough that you need people to do some of the work for you. Great! Now, there are two paths you can take, each with a wildly divergent outcome.

More is Less

The first path is the easiest one, as well as the one most businesses take: pay a lot of people a little money. You’re in business to make money, not spend it, after all. In your search for employees, you’ll find a lot of low-hanging fruit, though every once in a while you’ll get a real gem who just enjoys doing the work. At this point, there’s still time to make things right. Reward these people with more money and they’ll continue to be happy. Given the path you chose, however, I will assume you won’t.

Soon you have a company full of mediocrity, with a sprinkle of awesomeness to keep things from falling apart. Eventually the awesome employees will realize that they work harder and do a better job than the mediocre ones, but they make roughly the same wage. They start feeling disgruntled, then begin vocalizing their frustrations, and eventually whatever positive culture you had (if you had any) disintegrates when they jump ship.

You’ll still be able to get a rockstar here and there, sure, but now with the culture gone and even more mediocre people than before (that you had to hire because the previous rockstars left), they won’t last long at all. Rinse, repeat, until your staff is nothing but average or worse.

Does that sound like a company you want to work for? Does that sound like a company you want to do business with? If you said “yes” to either of the previous questions, think about the last company you dealt with that really pissed you off - your cable or phone company, for example. What made you upset about the interaction? Keep your answer in the back of your brain and read through the first path again. Odds are the company you had in mind decided to go down this road.

The less money you spend on each person, the more people you can employ; more people means more man-hours; more man-hours means more work being performed; more work performed means more money…right?

I understand the formula for choosing this route. I’m simply saying that it is inherently and irrevocably flawed.

Less is More

The second path is the one less traveled, but only because it requires more capital than the first: pay a few people a lot of money. You’re still in business to make money, yes? The most-skilled or talented person for the job will consistently surpass someone who is adequate, both in terms of quality and quantity. An exceptionally skilled person is easily capable of performing the work volume of two to three average people.

And here’s the kicker: you won’t need to pay this person two to three times as much as a single mediocre employee.

So the initial higher cost of a exceptional employee pays off almost immediately. Really makes the first path seem like a dead end, doesn’t it?

Let’s recap this concept. If you offer better wages, you will attract employees of a much higher caliber; if your employees are above average, their work will be of superior quality; better quality means more customers; more customers means more money for you; more money for you means you can continue the cycle, hiring more of those rockstars and making even more money.

Bring it Home

If you have any doubts at this point, remind yourself of why people have jobs in the first place. We need money for food, money for shelter, money for things we need and things we want. When you don’t have enough money to get the things you want, you will be less happy. When you don’t have enough money to get the things you need, it will prove very difficult for you to be happy at all.

The first path leads to either destruction or obscurity. The second path leads to fast growth, prosperity, healthy and happy employees who give you their best.

Which path will you take?

"Team spirit is for losers, financially speaking. It’s the glue that binds the losers together...."

Thu, 13 May 2010 19:54:37 -0400

“Team spirit is for losers, financially speaking. It’s the glue that binds the losers together. It’s the methodology employers use to shackle useful employees to their desks without having to pay them too much. While lives may depend on it in a few professions, like soldiering or firefighting, in commerce it acts as a subtle handicap and a brake to ambitious individuals. Which, in a way, is what it’s designed to do.”

- Felix Dennis, How to Get Rich

Employees that are a challenge to keep are often the best kind of employee to have.

Thu, 13 May 2010 04:10:13 -0400

Employees that are a challenge to keep are often the best kind of employee to have.