abe hassan | blog

being pre-digital

Imagine what this is like in a fully digital environment instead. Of course, they'd know everything about your medical history and payment ability from a quick ID scan at the entrance. And you'd know the doctor's availability before you even walked in, and you would have been shuttled to the urgent care center down the street if there was an uneven load this early in the morning. No questions to guess at the answer (last tetanus shot? Allergies to medications?) because the answers would be known. The drive to the pharmacy might be eliminated, or perhaps the waiting time would be shortened. If this accident or illness is trending, effecting more of the population, we'd know that right away and be able to prevent more of it... Triage would be more efficient as well. The entire process might take ten minutes, with a far better outcome.

via sethgodin.typepad.com

This blog post has been rolling around in my head for weeks now, because it's so ridiculously true. It's embarassing, almost. There's seriously no reason for paper recordkeeping anymore.

Tablets are the new clipboard.

The Onion called this out in their own way: Quick-Lube Shop Masters Electronic Record Keeping Six Years Before Medical Industry. So sad, how much needs to get shuffled around.

I'm also noticing it while on jury duty (two weeks so far, and counting). The amount of paper that's being shuffled around is insane. Boxes upon boxes upon boxes. And we're hearing things like, "we'll get you all a copy of that 55-page exhibit tomorrow". Why can't you just zap it to an iPad? Instead of spending 5 minutes looking through depositions to find the right page and the right line number, why not just use something where you can cross-link questions to reference material?

I wonder, almost, how much this would destabilize what we know of our society. Imagine the efficiencies if a court, or a doctor's office, or even girl scout cookie sales, ... if any of those went digital. I wonder what we'd discover. I wonder what jobs would stop being so stressful if recordkeeping wasn't a problem. If appointment scheduling was self-serve. If...

And that's why I sorta hate a lot of the Silicon Valley wank. Yes it's great that we're enabling people to talk to each other, but there's so many other industries that are in need of just a thorough beatdown. Not to revolutionize what they do, just to change how they do it. If we took all our talent and put it towards making cab dispatch, taxes, insurance claims all easier, we could change the world.

the problem with amortization

What's happening is obvious: you're paying extra to subsidize something else. In order to have a clean lobby or repaired runway or a life-saving but little-used machine on hand, institutions charge some people extra and spread it out over some of their larger costs.

via sethgodin.typepad.com

One of several interesting posts from Seth Godin in the last couple weeks. We spend more on the things we pay for (products, services), in order to get the things we're not directly paying for (rent, staff, etc). And, by doing that, we're masking the cost of those indirect fees. I find this fascinating to think about in the sense of operations.

For instance, at SAY Media, my team hosts/runs/manages multiple services -- internal and external facing. And there's a lot of shared services: the base cost of the datacenter (before we put the first machine in there), the cost of the network equipment, the cost of monitoring services, the cost of the ops team's staff ... the list goes on. None of those costs are allocated to any particular product; they get the benefit of the shared infrastructure.

But imagine if we went nuts and allocated every little detail of everything -- down to the bandwidth and power costs to each particular product. If a product's GM knew how much he was spending on bandwidth, or power, or staff, and was held responsible for those costs, then they get the ability to make better global decisions -- should we have a developer spend time minifying their JS/CSS to save on bandwidth costs, or should they build a feature that customers have been asking for?

This sort of awareness ties into a perpetual struggle for sysadmins and development teams: the cost of up-front work versus ongoing maintenance. "Spend two days debugging and fixing a memory leak" versus "Restart it once a night until forever". I don't believe that one side is inherently better than the other, but I do believe that it's easy to discount the cost of ongoing maintenance. Unless you explicitly take on the up-front work, you're implicitly choosing the ongoing maintenance. It feels like it costs nothing. And even when it's considered: up-front costs are known, ongoing costs are more nebulous, and so it's easy to believe that up-front costs are more expensive. 

Knowing what gets amortized can scare a lot of people, especially if they weren't aware of it before. But it also puts them in a position of power and control, to make the right decisions in a more global context. And assuming that's understood, I find it hard to be upset with any outcome because I'll know that any cost or inconvenience to the ops team (or any other team) is actually understood and accepted -- as opposed to happening by default.

stop using "we" at standups

Stop using ‘we’ at standup meetings. Don’t say “We need to stop skipping tests”. Directly address the people that need to change; if this seems too confrontational for your meetings, do it in private

via swanson.github.com

rise of the popped-collar programmer

Once you’ve gone down the road of letting anonymous people on the internet convince you that having cool war stories with cutting edge technologies you can tell on Hacker News is more important than shipping software that works and is easy-to-maintain, you’ve lost the objectivity and pragmatism needed to be an effective software developer.

via www.aaronstannard.com

the romantic image of an uber-programmer

The romantic image of an über-programmer is someone who fires up Emacs, types like a machine gun, and delivers a flawless final product from scratch. A more accurate image would be someone who stares quietly into space for a few minutes and then says “Hmm. I think I’ve seen something like this before.”

via www.johndcook.com

Old post but I like this gem. :) Related to this tweet of an Einstein quote:

"A clever person solves a problem. A wise person avoids it." - Einstein

yelp's sec filing, on open source software

Some of our solutions contain open source software, which may pose particular risks to our proprietary software and solutions.

We use open source software in our solutions and will use open source software in the future. From time to time, we may face claims from third parties claiming ownership of, or demanding release of, the open source software and/or derivative works that we developed using such software (which could include our proprietary source code), or otherwise seeking to enforce the terms of the applicable open source license. These claims could result in litigation and could require us to purchase a costly license or cease offering the implicated solutions unless and until we can re-engineer them to avoid infringement. This re-engineering process could require significant additional research and development resources. In addition to risks related to license requirements, use of certain open source software can lead to greater risks than use of third party commercial software, as open source licensors generally do not provide warranties or controls on the origin of software. Any of these risks could be difficult to eliminate or manage, and, if not addressed, could have a negative effect on our business and operating results.

via www.sec.gov

Oh boy.

don't use mongodb

Database developers must be held to a higher standard than your average developer. Namely, your priority list should typically be something like:

1. Don't lose data, be very deterministic with data
2. Employ practices to stay available
3. Multi-node scalability
4. Minimize latency at 99% and 95%
5. Raw req/s per resource

via pastebin.com

git pretty

via justinhileman.info

This is the best "keep calm" git flowchart I've seen so far.

what marks the transition from novice to expert?

A large proportion of marketing communication concerns feedback to consumers. This article explores what feedback people seek and respond to. We predict and find a shift from positive to negative feedback as people gain expertise. We document this shift in a variety of domains including feedback on language acquisition, pursuit of environmental causes, and use of consumer products. Across these domains, novices sought and responded to positive feedback, and experts sought and responded to negative feedback. We examine a motivational account for the shift in feedback: positive feedback increased novices’ commitment and negative feedback increased experts’ sense that they were making insufficient progress.

via www.bakadesuyo.com

node.js is cancer

Although, let's be honest with ourselves here, if you're a Node developer, you are probably serving the application directly from Node, running in a screen session under your account.

via teddziuba.com

Been going around the last few days ... I don't have too much of an opinion about the rest of the post. But, yeah, this seems to be how every Node application needs to run.