programming and human factors
by Jeff Atwood
Markdown is a simple little humane markup language based on time-tested plain text conventions from the last 40 years of computing.
| Meaning, if you enter this… | …you get this! |
Lightweight Markup Languages
============================
According to **Wikipedia**:
> A [lightweight markup language](http://is.gd/gns)
is a markup language with a simple syntax, designed
to be easy for a human to enter with a simple text
editor, and easy to read in its raw form.
Some examples are:
* Markdown
* Textile
* BBCode
* Wikipedia
Markup should also extend to _code_:
10 PRINT "I ROCK AT BASIC!"
20 GOTO 10
|
Lightweight Markup LanguagesAccording to Wikipedia: A lightweight markup language is a markup language with a simple syntax, designed to be easy for a human to enter with a simple text editor, and easy to read in its raw form. Some examples are:
Markup should also extend to code: 10 PRINT "I ROCK AT BASIC!" 20 GOTO 10 |
You can think of Markdown as a radically simplified and far more human readable form of HTML. I have grown to love Markdown over the last few years. If you're a programmer of any shape, size, or color, you can't really avoid using Markdown, as it's central to both GitHub and Stack Overflow. For that matter, my new project uses Markdown, too.
Markdown is a wonderful tool, but it does suffer a bit from lack of project leadership. The so-called "spec" is anything but, and there are dozens of different flavors of Markdown out there, all with differences in the way they behave. While they are broadly compatible, Stack Overflow and GitHub have both tweaked Markdown in ways that can trip you up if you're familiar with one but not the other; compare GitHub Flavor with Stack Overflow Flavor.
That's why I was so excited to get this email from David Greenspan a few days ago:
I'm the creator of EtherPad (a collaborative WYSIWYG editor), now working at Meteor. At Meteor, we're trying to "pave the web" for developers by writing better components. For example, we just released universal login buttons that talk over WebSockets and are wired into the users table of the app's database. Since Markdown is increasingly ubiquitous for writing content, it's going to be part of the Meteor toolchain. I wouldn't be surprised if we end up releasing a component like Stack Overflow's editor, with the full "Meteor" standard of code quality, so that no one has to roll their own again. Today, we use Markdown in our API docs generation, and we're going to be writing more and more content in it -- which is a scary thought.
I think you and I share some concern (horror?) about Markdown's lack of spec and tests. The code is ugly to boot. Extending or customizing Markdown is tricky (we already have some hacks and they are terrible), and I worry about "bit rot" of content if the format doesn't have a spec. I'm evaluating the possibility of starting over with a new implementation coupled with a real spec and test suite, and I've been thinking a lot about how to parse a language like Markdown in a principled way. I'm pretty fearless about parsers, by the way; I wrote a full ECMAScript parser in a week as a side project.
I want this new language – working name "Rockdown" – to be seen as Markdown with a spec, and therefore only deviate from Markdown's behavior in unobtrusive ways. It should basically be a replacement that paves over the problems and ambiguities in Markdown. I'm trying to draw a line between what behavior is important to preserve and what behavior isn't.
I was excited because, like David, I freaking love Markdown. I love it so much that I want to see it succeed and flourish over the next 20 years. I believe the best way to achive that goal is for the most popular sites using Markdown to band together and take ownership of Markdown as a standard. I propose that Stack Exchange, GitHub, Meteor, Reddit, and any other company with lots of traffic and a strategic investment in Markdown, all work together to come up with an official Markdown specification, and standard test suites to validate Markdown implementations. We've all been working at cross purposes for too long, accidentally fragmenting Markdown while popularizing it.
Like any dutiful and well-meaning suitor, we first need to ask permission for this courtship from the parents. So I'm asking you, John Gruber: as the original creator of Markdown, will you bless this endeavor? Also, as a totally unreleated aside, have I mentioned what a huge Yankees fan I am? Derek Jeter is one of the all-time greats.
I realize that the devil is in the details, but for the most part what I want to see in a Markdown Standard is this:
And that's it, really. I don't want to extend Markdown by adding tons of crazy new functionality, or radically change the way it currently works, or anything like that. I'd be opposed to such changes. I just want to solidify and standardize the simple, useful version of Markdown that is working so well for everyone right now. I want there to be an unambiguous, basic standard that everyone using Markdown can expect to work in the same way across all web sites in the world when they begin typing.
I'd really prefer not to fork the language; I'd much rather collectively help carry the banner of Markdown forward into the future, with the blessing of John Gruber and in collaboration with other popular sites that use Markdown.
So … who's with me?
| [advertisement] Stack Overflow Careers matches the best developers (you!) with the best employers. You can search our job listings or create a profile and even let employers find you. |
I was invited to judge the Rails Rumble last year, but was too busy to participate. When they extended the offer again this year, I happily accepted.
The Rails Rumble is a distributed programming competition where teams of one to four people, from all over the world, have 48 hours to build an innovative web application, with Ruby on Rails or another Rack-based Ruby web framework. After the 48 hours are up, a panel of expert judges will pick the top ten winners.
I received an email notifying me that judging begins today, so I cracked my knuckles, sat down in front of my three monitors (all the better to judge with!) and … saw that there were around 340 entries.
That's when I started to get a little freaked out about the math. Perhaps we can throw 5% of the entrants out as obviously incomplete or unfinished. That leaves 323 entries to judge. Personally, I'm not comfortable saying I judged a competition unless I actually look at each one of the entries, so at an absolute minimum I have to click through to each webapp. Once I do, I couldn't imagine properly evaluating the webapp without spending at least 30 seconds looking at the homepage.
Let's be generous and say I need 10 seconds to orient myself and account for page load times, and 30 seconds to look at each entry. That totals three and a half hours of my, y'know, infinitely valuable time. In which I could be finding a cure for cancer, or clicking on LOLcats. I still felt guilty about only allocating half a minute per entry; is it fair to the contestants if I make my decision based on 30 seconds of scanning their landing page and maybe a few desultory clicks?
But then I had an epiphany: yes, deciding in 30 seconds is totally completely unfair, but that's also exactly how it works in the real world. Users are going to click through to your web site, look at it for maybe 30 seconds, and either decide that it's worthy, or reach for the almighty back button on their browser and bug out. Thirty seconds might even be a bit generous. In one Canadian study, users made up their mind about websites in under a second.
Researchers led by Dr. Gitte Lindgaard at Carleton University in Ontario wanted to find out how fast people formed first impressions. They tested users by flashing web pages for 500 millseconds and 50 milliseconds onto the screen, and had participants rate the pages on various scales. The results at both time intervals were consistent between participants, although the longer display produced more consistent results. Yet, in as little as 50 milliseconds, participants formed judgments about images they glimpsed. The "halo effect" of that emotional first impression carries over to cognitive judgments of a web site's other characteristics including usability and credibility.
The opportunity cost to switch websites is one tiny little click of the mouse or tap of the finger. What I learned from judging the Rails Rumble most of all is that your website's front page needs to be kind of awesome. It is never the complete story, of course, but do not squander your first opportunity to make an impression on a visitor. It may be the only one you get.
I'm not sure I was learning much about these apps while I judged, and for that I am truly sorry. But along the way I accidentally learned a heck of a lot about what makes a great front page for a web application. So I'd like to share that with you, and all future Rails Rumble entrants:
I've talked about performance as a feature before; the sooner the front page of your site loads, the sooner I can decide whether or not I am interested. If you are slow, I will resent you for being slow, and the slower you are the more I will resent you for keeping me from not just finding out about you but also keeping me from moving on to the next thing. I need to be an efficient informavore. That means moving quickly. Above all else, load fast.
The first challenge you have is not coding your app. It is explaining what problem your app solves, and why anyone in the world would possibly care about that. You need an elevator pitch on your front page: can you explain to a complete stranger, in 30 seconds, why your application exists? Yes, writing succinctly and clearly is an art, but keep pounding on that copy, keep explaining it over and over and over until you have your explanation polished to the fine sheen of a diamond. When you're confident you could walk up to any random person on the street, strike up a conversation about what you're working on, and not have their eyes gloss over in boredom and/or fear – that's when you're ready. That's the text you want on your home page.
OK, so you're building the ultimate tool for cataloging and sharing Beanie Babies on Facebook. Awesome, let me be an angel investor in your project so I can get me a piece of those sweet, sweet future billions. The idea is sound. But everyone knows that ideas are worthless, whereas execution is everything. I have no clue what the execution of your idea is unless you show it to me. At the very least throw up some screenshots of what it would look like if I used your webapp, with some juicy real world examples. And please, please, please, for the love of God please, do not make me sign up, click through a video, watch a slideshow, or any of that nonsense. Only emperors and princes have that kind of time, man. Show, don't tell.
In the rare cases where the app passes the above three tests with flying colors, I'm invested: I am now willing to spend even more of my time checking it out. What do I do next? Where do I go? Your job is to make this easy for me. I call this "the put a big-ass giant obvious fluorescent lime green button on your home page" rule. You can have more than one, but I'd draw the line at two. And make the text on the button descriptive, like Start sharing your favorite Beanie Babies → or Build your dream furry costume →. If you require login at this point, I strongly urge you to skip that barrier and have a live sample I can view without logging in at all, just to get a taste of how things might work. If you're really, really slick you will make it seamless to go from an unregistered to a registered state without losing anything I've done.
Even if you nail all the above, you might not fit into my interest zone through absolutely no fault of your own. If you built the world's most innovative and utterly disruptive Web 5.0 Pokédex, there's a lot of people who won't care one iota about it, because they're not really into Pokemon. This is not your fault and it is certainly not their fault. You need to embrace the idea that half of all success is knowing your core audience and not trying to water it down so much that it appeals to "everyone". Don't patronize me by trying to sell me on the idea that everyone should care about babies, or invoicing, or sports, or being a student, or whatever. Only the people who need to care will care, and that's who you are talking to. So have the confidence to act like it.
I realize that Rails Rumble apps only have a mere 48 hours to build an entire app from scratch. I am not expecting a super professional amazing home page on every one of the entries, nor did I judge it that way. But I do know that a basic sketch of a homepage design is the first thing you should work on in any webapp, because it serves as the essential starting design document and vision statement. Unless you start with a basic homepage that meets the above 5 rules, your app won't survive most judges, much less the herds of informavores running wild on the Internet.
| [advertisement] Hiring developers? Post your open positions with Stack Overflow Careers and reach over 20MM awesome devs already on Stack Overflow. Create your satisfaction-guaranteed job listing today! |
In 1998 I briefly worked for FiringSquad, a gaming website founded by Doom and Quake champion Thresh aka Dennis Fong and his brother Kyle. I can trace my long-standing interest in chairs and keyboards to some of the early, groundbreaking articles they wrote. Dennis and Kyle were great guys to work with, and we'd occasionally chat on the phone about geeky hardware hotrodding stuff, like the one time they got so embroiled in PC build one-upmanship that they were actually building rack-mount PCs … for their home.
So I suppose it is inevitable that I'd eventually get around to writing an article about building rack-mount PCs. But not the kind that go in your home. No, that'd be as nuts as the now-discontinued Windows Home Server product.
Servers belong in their native habitat, the datacenter. Which can be kind of amazing places in their own right.
The above photo is from Facebook's Open Compute Project, which is about building extremely energy efficient datacenters. And that starts with minimalistic, no-frills 1U server designs, where 1U is the smallest amount of space divisible in a server rack.
I doubt many companies are big enough to even consider building their own datacenter, but if Facebook is building their own custom servers out of commodity x86 parts, couldn't we do it too? In a world of inexpensive, rentable virtual machines, like Amazon EC2, Google Compute Engine, and Azure Cloud, does it really make sense to build your own server and colocate it in a datacenter?
It's kind of tough to tell exactly how much an Amazon EC2 instance will cost you since it varies a lot by usage. But if I use the Amazon Web Services simple monthly calculator and select the Web Application "common customer sample", that provides a figure of $1,414 per month, or $17k/year. If you want to run a typical web app on EC2, that's what you should expect to pay. So let's use that as a baseline.
The instance types included in the Web Application customer sample are 24 small (for the front end), and 12 large (for the database). Here are the current specs on the large instance:
You might be wondering what the heck a EC2 Compute Unit is; it's Amazon's way of normalizing CPU performance. By their definition, what we get in the large instance is akin to an old 2008 era dual core 2.4 GHz Xeon CPU. Yes, you can pay more and get faster instances, but switching instances from the small to the high-CPU and from the large to the high-MEM more than doubles the bill to $3,302 per month or $40k/year.
Assuming you subscribe to the theory of scaling out versus scaling up, building a bunch of decent bang-for-the-buck commodity servers is what you're supposed to be doing. I avoided directly building servers when we were scaling up Stack Overflow, electing to buy pre-assembled hardware from Lenovo instead. But this time, I decided the state of hardware has advanced sufficiently since 2009 that I'm comfortable cutting out the middleman in 2012 and building the servers myself, from scratch. That's why I just built four servers exactly like this:
(If you are using this as a shopping list, you will also need 4-pin power extensions for the case, and the SuperMicro 1u passive heatsink. The killer feature of SuperMicro motherboards that makes them all server-y in the first place is the built in hardware KVM-over-IP. That's right, unless the server is literally unplugged, you can remote in and install an operating system, tweak the BIOS, power it on and off, and so on. It works. I use it daily.)
Based on the above specs, this server has comparable memory to the High-Memory Double Extra Large Instance, comparable CPU power to the High-CPU Extra Large Instance, and comparable disk performance to the High I/O Quadruple Extra Large Instance. This is a very, very high end server by EC2 standards. It would be prohibitively expensive to run this hardware in the Amazon cloud. But how much will it cost us to build? Just $2,452. Adding 10% for taxes, shipping, etc let's call it $2,750 per server. One brand new top-of-the-line server costs about as much as two months of EC2 web application hosting.
Of course, that figure doesn't include the cost in time to build and rack the server, the cost of colocating the server, and the ongoing cost of managing and maintaining the server. But I humbly submit that the one-time cost of paying for three of these servers, plus the cost of colocation, plus a bunch of extra money on top to cover provisioning and maintenance and support, will still be significantly less than $17,000 for a single year of EC2 web application hosting. Every year after the first year will be gravy, until the servers are obsolete – which even conservatively has to be at least three years. Perhaps most importantly, these servers will offer vastly better performance than you could get from EC2 to run your web application, at least not without paying astronomical amounts of money for the privilege.
(If you are concerned about power consumption, don't be. I just measured the power use of the server using my trusty Kill-a-Watt device: 31 watts (0.28 amps) at idle, 87 watts (0.75 amps) under never-gonna-happen artificial 100% CPU load. The three front fans in the SuperMicro case are plugged into the motherboard and only spin up at boot and under extreme load. It's shockingly quiet in typical use for a 1U server.)
I realize that to some extent we're comparing apples and oranges. Either you have a perverse desire to mess around with hardware, or you're more than willing to pay exorbitant amounts of money to have someone else worry about all that stuff (and, to be fair, give you levels of flexibility, bandwidth, and availability that would be impossible to achieve even if you colocate servers at multiple facilities). $51,000 over three years is enough to pay for a lot of colocation and very high end hardware. But maybe the truly precious resource at your organization is people's time, not money, and that $51k is barely a rounding error in your budget.
Anyway, I want to make it clear that building and colocating your own servers isn't (always) crazy, it isn't scary, heck, it isn't even particularly hard. In some situations it can make sense to build and rack your own servers, provided …
Why do I choose to build and colocate servers? Primarily to achieve maximum performance. That's the one thing you consistently just do not get from cloud hosting solutions unless you are willing to pay a massive premium, per month, forever: raw, unbridled performance. I'm happy to spend money on nice dedicated hardware because I know that hardware is cheap, and programmers are expensive.
But to be totally honest with you, mostly I build servers because it's fun.
| [advertisement] Stack Overflow Careers matches the best developers (you!) with the best employers. You can search our job listings or create a profile and even let employers find you. |
What do you need to do today? Other than read this blog entry, I mean.
Have you ever noticed that a huge percentage of Lifehacker-like productivity porn site content is a breathless description of the details of Yet Another To-Do Application? There are dozens upon dozens of the things to choose from, on any platform you can name. At this point it's getting a little ridiculous; per Lifehacker's Law, you'd need a to-do app just to keep track of all the freaking to-do apps.
I've tried to maintain to-do lists at various points in my life. And I've always failed. Utterly and completely. Even turning it into a game, like the cleverly constructed Epic Win app, didn't work for me.
Eventually I realized that the problem wasn't me. All my to-do lists started out as innocuous tools to assist me in my life, but slowly transformed, each and every time, into thankless, soul-draining exercises in reductionism. My to-do list was killing me. Adam Wozniak nails it:
For the things in my life that actually mattered, I've never needed any to-do list to tell me to do them. If I did, then that'd be awfully strong evidence that I have some serious life problems to face before considering the rather trivial matter of which to-do lifehack fits my personality best. As for the things that didn't matter in my life, well, those just tended to pile up endlessly in the old to-do list. And the collective psychic weight of all these minor undone tasks were caught up in my ever-growing to-do katamari ball, where they continually weighed on me, day after day.
Yes, there's that everpresent giant to-do list, hanging right there over your head like a guillotine, growing sharper and heavier every day.
Like a crazy hoarder I mistake the root cause of my growing mountain of incomplete work. The hoarder thinks he has a storage problem when he really has a 'throwing things away problem'. I say I am 'time poor' as if the problem is that poor me is given only 24 hours in a day. It's more accurate to say… what exactly? It seems crazy for a crazy person to use his own crazy reasoning to diagnose his own crazy condition. Maybe I too easily add new projects to my list, or I am too reluctant to exit from unsuccessful projects. Perhaps I am too reluctant to let a task go, to ship what I've done. They're never perfect, never good enough.
And I know I'm not alone in making the easy claim that I am 'time poor'. So many people claim to be time poor, when really we are poor at prioritizing, or poor at decisiveness, or don't know how to say 'no' (…to other people, to our own ideas).
If only I had a hidden store of time, or if only I had magical organisation tools, or if only I could improve my productive throughput, then, only then would I be able to get things done, to consolidate the growing backlogs and todo lists into one clear line of work, and plough through it like an arctic ice breaker carving its way through a sheet of ice.
But are you using the right guillotine? Maybe it'd work better if you tried this newer, shinier guillotine? I'd like to offer you some advice:
Here's my challenge. If you can't wake up every day and, using your 100% original equipment God-given organic brain, come up with the three most important things you need to do that day – then you should seriously work on fixing that. I don't mean install another app, or read more productivity blogs and books. You have to figure out what's important to you and what motivates you; ask yourself why that stuff isn't gnawing at you enough to make you get it done. Fix that.
Tools will come and go, but your brain and your gut will be here with you for the rest of your life. Learn to trust them. And if you can't, do whatever it takes to train them until you can trust them. If it matters, if it really matters, you'll remember to do it. And if you don't, well, maybe you'll get to it one of these days. Or not. And that's cool too.
| [advertisement] How are you showing off your awesome? Create a Stack Overflow Careers profile and show off all of your hard work from Stack Overflow, Github, and virtually every other coding site. Who knows, you might even get recruited for a great new position! |
MG Siegler writes:
The PC is over. It will linger, but increasingly as a relic.
I now dread using my computer. I want to use a tablet most of the time. And increasingly, I can. I want to use a smartphone all the rest of the time. And I do.
The value in the desktop web is increasingly an illusion. Given the rate at which these mobile devices are improving, a plunge is rapidly approaching.
Don’t build an app based on your website. Build the app that acts as if websites never existed in the first place. Build the app for the person who has never used a desktop computer. Because they’re coming. Soon.
Realize that MG Siegler is a journalist, and a TechCrunch air-quotes journalist at that, so he's well versed in hyperbole. You might say he's a billion times better at hyperbole than the average blogger. In his own way, he is a creator, I suppose: he creates hype.
But he's not entirely wrong here.
I've noticed the same pattern in my own computing habits. As I wrote in The Last PC Laptop, it's becoming more and more difficult to justify any situation where a traditional laptop is your best choice – even a modern, svelte, fancypants laptop.
Desktops, on the other hand, are perfectly justifiable. That is, if you want three monitors, eight blazingly fast CPU cores, 64 GB of memory, and fire-breathing multi-GPU configurations. If you need absurd, obscene amounts of power, a desktop computer is the way to go. And it's probably cheaper than you think, because desktops are all built from the same interchangeable pool of parts. It's also a lot more fun than laptops, because willingness to tinker combined with lust for ostentatious power is the essence of hot rodding.
And it is freakin' awesome.
But even as an inveterate PC hot-rodder, I've noticed that in the last few years I've started to lose interest in the upgrade treadmill of ever faster CPUs with more cores, more sophisticated GPUs, more bandwidth, more gigabytes of RAM. Other than solid state drives, which gave us a badly needed order of magnitude improvement in disk speeds, when was the last time you felt you needed to upgrade a powerful desktop or laptop computer? If I dropped a SSD in it, do you honestly think you could tell the difference in real world non-gaming desktop usage between a high end 2009 personal computer and one from today?
Because I'm not sure I could.
Imagine the despair of a hot-rodder who regularly sees the streets awash in boring Chrysler K-Cars and Plymouth minivans with more ponies under the hood than a sweet custom rig he built just two years ago.
I think we're way past the point of satisfying the computing performance needs of the typical user. I'd say we hit that around the time dual CPU cores became mainstream, perhaps 2008 or so. What do you do when you have all the computing performance anyone could ever possibly need, except for the freakish one-percenters, the video editors and programmers? Once you have "enough" computing power, for whatever value of "enough" we can agree to disagree on, the future of computing is, and always has been, to make the computers smaller and cheaper. This is not some new trend that MG Siegler revealed unto the world from his journalistic fortress of solitude.
I mentioned how boring the performance scene has gotten for laptops and desktops. It's so boring that I can't be bothered to dig up representative benchmarks. Let's just assume that, outside of SSDs, there have been at best cost-of-living inflation type improvements in desktop and laptop benchmarks since 2008. Now contrast that with the hyperbolic performance improvement in the iPhone since 2008:
In case the graph didn't make it clear, in the last four years of iPhone, we've seen a factor of 20 improvement in Browsermark and a factor of four improvement in GeekBench. In the smartphone world, performance is – in the worst case – almost doubling every year.
Ironically enough, these results were printed in PC magazine. I'd like to draw your attention to two little letters in the title of said magazine. The first one is Pee, and the second one is Cee. That's right, PC Magazine is now in the business of printing the kind of smartphone performance benchmarks that are enough to make any hotrodder drool. What does that have to do with PCs? Well, it has everything to do with PCs, actually.
I have an iPhone 5, and I can personally attest that it is crazy faster than the old iPhone 4 I upgraded from. Once you add in 4G, LTE, and 5 GHz WiFi support, it's so fast that – except for the obvious size limitations of a smaller screen – I find myself not caring that much if I get the "mobile" version of websites any more. Even before the speed, I noticed the dramatically improved display. AnandTech says that if the iPhone 5 display was a desktop monitor, it would be the best one they had ever tested. Our phones are now so damn fast and capable as personal computers that I'm starting to wonder why I don't just use the thing I always have in my pocket as my "laptop", plugging it into a keyboard and display as necessary.
So maybe MG Siegler is right. The PC is over … at least in the form that we knew it. We no longer need giant honking laptop and desktop form factors for computers any more than we need entire rooms and floors of a building to house mainframes and minicomputers.
| [advertisement] What's your next career move? Stack Overflow Careers has the best job listings from great companies, whether you're looking for opportunities at a startup or Fortune 500. You can search our job listings or create a profile and let employers find you. |
This is not a post about programming, or being a geek. In all likelihood, this is not a post you will enjoy reading. Consider yourselves warned.
I don't remember how I found this Moth video of comedian Anthony Griffith.
It is not a fun thing to watch, especially as a parent. Even though I knew that before I went in, I willingly chose to watch this video. Then I watched it again. And again. And again. I watched it five times, ten times. I am all for leaning into the pain, but I started to wonder if maybe I was addicted to the pain. I think my dumb programmer brain was stuck in an endless loop trying to make sense out of what happened here.
But you don't make sense of a tragedy like this. You can't. There are no answers.
My humor is becoming dark, and it's biting, and it's becoming hateful. And the talent coordinator is seeing that there's a problem, because NBC is all about nice, and everything is going to be OK. And we're starting to buck horns because he wants everything light, and I want to be honest and tell life, and I'm hurting, and I want everybody else to hurt. Because somebody is to blame for this!
The unbearable grief demands that someone must be to blame for this unimaginably terrible thing that is happening to you, this deeply, profoundly unfair tragedy. But there's nobody. Just you and this overwhelming burden you've been given. So you keep going, because that's what you're supposed to do. Maybe you get on stage and talk about it. That's about all you can do.
So that's what I'm going to do.
Five weeks ago, I was selected for jury duty in a medical malpractice trial.
This trial was the story of a perfectly healthy man who, in the summer of 2008, was suddenly killed by a massive blood clot that made its way to his heart, after a surgery to repair a broken leg. Like me, he would have been 41 years old today. Like me, he married his wife in the summer of 1999. Like me, he had three children; two girls and a boy. Like me, he had a promising, lucrative career in IT.
I should have known I was in trouble during jury selection. When they called your name, you'd come up from the juror pool – about 50 people by my estimation – and sit in the jury booth while both lawyers asked you some questions to determine if you'd be a fair and impartial juror for this trial. What I hadn't noticed at the time, because she was obscured by a podium, is that the wife was sitting directly in front of the jury. I heard plenty of people get selected and make up some bogus story about how they couldn't possibly be fair and impartial to get out of this five week obligation. And they did, if they stuck to their story. But sitting there myself, in front of the wife of this dead man, I just couldn't do it. I couldn't bring myself to lie when I saw on her face that her desire not to be there was a million times more urgent than mine.
Now, I'm all for civic duty, but five weeks in a jury seemed like a bit more than my fair share. Even worse, I was an alternate juror, which meant all of the responsibility of showing up every day and listening, but none of the actual responsibility of contributing to the eventual verdict. I was expecting crushing boredom, and there was certainly plenty of that.
On day one, during opening remarks, we were treated to multiple, giant projected photographs of the three happy children with their dead father – directly in front of the very much still alive wife. She had to leave the courtroom at one point.
The first person we heard testimony from was this man's father, who was and is a practicing doctor. He was there when his son was rushed to the emergency room. He was allowed to observe as the emergency room personnel worked, so he described to the jury the medical process of treatment, his son thrashing around on the emergency room table being intubated, his heart stopping and being revived. As a doctor, he knows what this means.
On day two, we heard from the brother-in-law, also a doctor, and close friend of the family. He described coming home from the hospital to explain to the children that their father was dead, that he wasn't coming home. The kids were not old enough to understand what death means, so for a year afterward, every time they drove by the hospital, they would ask to visit their dad.
I did not expect to learn what death truly was in a courtroom in Martinez, California, at age 41. But I did. Death is a room full of strangers listening to your loved ones describe, in clinical detail and with tears in their eyes, your last moments. Boredom, I can deal with. This is something else entirely.
As a juror, you're ordered not to discuss the trial with anyone, so that you can form a fair and impartial opinion based on the shared evidence that everyone saw in the courtroom together. So I'm taking all this in and I'm holding it down, like I'm supposed to. But it's hard. I feel like becoming a parent has opened emotional doors in me that I didn't know existed, so it's getting to me.
Sometime later, the wife finally testifies. She explains that on the night of the incident, her husband finally felt well enough after the surgery on his right leg to read a bedtime story to their 4 year old son. So she happily leaves father and son to have their bedtime ritual together. Later, the son comes rushing in and tells her there's something wrong with dad, and the look on his face is enough to let her know that it's dire. She found him collapsed on the floor of her son's room and calls 911.
A week later, I was putting our 4 year old son Henry to bed. I didn't realize it at the time, but this was the first time I had put him to bed since the trial started. Henry isn't quite old enough to have a stable sleep routine, so sometimes bedtime goes well, and sometimes it doesn't. It went well that particular night, so I'm happy lying there with him in the bed waiting for his breathing to become regular so I know he's fully asleep. And then the next thing I know I'm breaking down. Badly. I'm desperately trying to hold it together because I don't want to scare him, and he doesn't need to know about any of this. But I can't stop thinking about what it would feel like for my wife to see pictures of me with our children if I died. I can't stop thinking about what it would feel like to watch Henry die on an emergency room table at age 38. I can't stop thinking about what it would feel like to explain to someone else's children that their father is never coming home again. Most of all, I can't stop thinking about the other 4 year old boy who will never stop blaming himself because he saw his Dad collapse on the floor of his room, and then never saw him again for the rest of his life.
Somebody is to blame for this. Somebody must be to blame for this.
Now I urgently want this trial to be over. I'm struggling to understand the purpose of it all. Nothing we see or do in this courtroom is bringing a husband and father back from the dead. The plaintiff could be home with her children. The parade of doctors and hospital staff making their way through this courtroom could be helping patients. The jurors could be working at their jobs. My God how I would love to be doing my job rather than this, anything in the world other than this. A verdict for either party has immense cost. Nobody is in this courtroom because they want to be here. So why?
I don't know these people. I don't care about these people. I mean, it's in my job description as a juror: I am fair and impartial because I don't care what happens to them. But finally I realized that this trial is part of our ride.
We get on the ride because we know there will be thrills and chills. Nobody gets on a rollercoaster that goes in a straight line. That's what you sign up for when you get on the ride with the rest of us: there will be highs, and there will be lows. And those lows – whether they are, God forbid, your own, or someone else's – are what make the highs so sweet. The ride is what it is because the pain of those valleys teaches us.
Sharing this tragic, horrible, private thing that happened to these poor people is how we cope. Watching this play out in public, among your peers, among other fellow human beings, is what it takes to for all of us to survive and move on. We're here in this courtroom together because we need to be here. It's part of the ride.I've heard and seen things in that courtroom I think I will remember for the rest of my life. It's been difficult to deal with, though I am sure it is the tiniest reflected fraction of what you and your family went through. I am so, so sorry this happened to you. But I want to thank you for sharing it with me, because I now know that I am to blame. We're all to blame.
That's what makes us human.
| [advertisement] Hiring developers? Post your open positions with Stack Overflow Careers and reach over 20MM awesome devs already on Stack Overflow. Create your satisfaction-guaranteed job listing today! |
I've been chasing the perfect PC laptop for over a decade now.
Though I've tolerated lugging around five to seven pound machines because I had to, laptops were always about portability first and most of all to me. I quickly gravitated to so-called ultraportable laptops as soon as they became available. The first one was the 2003 Dell Inspiron 300M. It was the first laptop I found that delivered a decent 3-ish pound package without too many compromises. How I loved this little thing.
But there was a downside to that 2003-era ultraportability – the default battery in the system provided about 2 hours of runtime. Switching to the larger battery extended that to a much more respectable 5.5 hours, but it also added a pound to the system and protruded from the rear a bit.
I've pursued the same dream of reasonable power with extreme portability ever since, with varying degrees of success. The PC industry isn't exactly known for its design leadership, and it can be downright schizophrenic at times. So if you were a fan of laptops that were actually thin and light and portable, it's been rough going for a long time. 2007's Dell XPS M1330 was a brief bright spot, but honestly, it's only in the last few months I've found an ultraportable that lived up to my expectations, one that I feel confident in recommending. That laptop is the Asus Zenbook Prime UX31A.
Having lived with this laptop for about two months now, I can safely say it is without question the best PC laptop I've ever owned. Consider the Tech Report review and the Engadget review, both rave. Here's what you need to know:
All of this for about $1,050 at the time of writing. If you're suffering through a sub-par TN display on your current laptop, the awesome IPS display is almost worth an upgrade on its own. After switching to bargain Korean IPS displays on the desktop, I'm desperately hoping my poor eyeballs never have to endure another awful TN LCD display for the rest of my life.
This is a machine that pleasantly surprised me at every turn. The keyboard is solid feeling with a dimmable backlight, and the achilles heel of all PC laptops, the trackpad, is about as good as it ever gets on PCs. Which is to say still not great. Even the power adapter is classy, although highly derivative of Apple. While this is substantially closer to the ideal ultraportable hardware I've had in my brain since 2003, it still exhibits some of the same problems I experienced with that Inspiron 300M almost 10 years ago:
The first thing I did when I got the laptop was wipe it and install the Windows 8 preview, and soon after updated it to the final Windows 8 release. Despite all the grousing about the tablet-centric nature of Windows 8 – some of which is warranted, but can easily be ignored entirely – I am an unabashed fan of the operating system. It is a big improvement over Windows 7 in my day to day use. The more I use Windows 8 the more I believe it's the biggest step forward in Windows since Windows 95. So what I've put together here is probably the best, most platonic ideal form of Wintel laptop hardware you can buy in mid-2012.
(In the interests of full disclosure, I actually own two of these. One for my wife and one for me. Because I am an inveterate hotrodder, I had to have more memory and a larger, faster SSD. So I bought the UX32VD model which has a discrete Nvidia 620M GPU and, most importantly, can be upgraded internally. So I dropped in a Samsung 830 512 GB SSD and 8 GB DIMM. This led to a slightly oddball final configuration of 10 GB RAM and an internal embedded 32 GB SSD plus the 512 GB SSD. It hurts battery life by at least an hour, too. You should also know that the teeny-tiny Torx screws on the back of this laptop are not to be trifled with. Bring your jeweler's loupe. In case it wasn't already abundantly clear, let me spell it out for you: going this route is not recommended unless you are as crazy as I am. The base model is really nice! Trust me!)
If pressed, I might admit the combination of ASUS Zenbook Prime hardware and modern Windows 8 amenities lives up to the whole Intel "Ultrabook" marketing schtick. But I'm not sure that's enough any more.
Every time I leave the house – heck, every time I leave the room – I have to decide what kind of computer I'm going to take with me, if any. Besides the ultraportable laptops, I now own an iPhone 5, several retina iPads, and a Nexus 7. I'm sure there are many more of these devices on the way. In the calculus of deciding what kind of computing device I want with me, even the most awesome ultraportable laptop I can find is no longer enough. Consider:
My laptop is increasingly a device I only take when I know I'll need to do a lot of typing, and/or I'll need a lot of screen space to work. But even a phone could do that if it had decent support for bluetooth keyboards and external displays, couldn't it? And even a few programmers, the audience who would most need all the power and flexibility of laptops, are switching to tablets.
I've waited 12 years for the PC industry to get its collective act together and, if nothing else, successfully copy Apple's laptop hardware designs. Now that they (mostly) have, I wonder: is it too late? Has the PC industry irrevocably shifted underneath them while they were so busy pumping out endless refinements to generic x86 boxes? I love this new laptop, and in many ways it is the perfect ultraportable hardware I dreamed of having in 2003. But every time I power it up and use it, I feel a little sad. I can't shake the feeling that this might end up being the last PC laptop I ever own.
| [advertisement] Stack Overflow Careers matches the best developers (you!) with the best employers. You can search our job listings or create a profile and even let employers find you. |
I've already documented my brief, youthful dalliance with the illegal side of computing as it existed in the late 1980s. But was it crime? Was I truly a criminal? I don't think so. To be perfectly blunt, I wasn't talented enough to be any kind of threat. I'm still not.
There are two classic books describing hackers active in the 1980s who did have incredible talent. Talents that made them dangerous enough to be considered criminal threats.
|
The Cuckoo's Egg: Tracking a Spy Through the Maze of Computer Espionage |
Ghost in the Wires: My Adventures as the World's Most Wanted Hacker |
Cuckoo is arguably the first case of hacking that was a clearly malicious crime circa 1986, and certainly the first known case of computer hacking as international espionage. I read this when it was originally published in 1989, and it's still a gripping investigative story. Cliff Stoll is a visionary writer who saw how trust in computers and the emerging Internet could be vulnerable to real, actual, honest-to-God criminals.
I'm not sure Kevin Mitnick did anything all that illegal, but there's no denying that he was the world's first high profile computer criminal.
By 1994 he made the FBI's 10 Most Wanted list, and there were front page New York Times articles about his pursuit. If there was ever a moment that computer crime and "hacking" entered the public consciousness as an ongoing concern, this was it.
The whole story is told in minute detail by Kevin himself in Ghost in the Wires. There was a sanitized version of Kevin's story presented in Wizzywig comix but this is the original directly from the source, and it's well worth reading. I could barely put it down. Kevin has been fully reformed for many years now; he wrote several books documenting his techniques and now consults with companies to help improve their computer security.
These two books cover the genesis of all computer crime as we know it. Of course it's a much bigger problem now than it was in 1985, if for no other reason than there are far more computers far more interconnected with each other today than anyone could have possibly imagined in those early days. But what's really surprising is how little has changed in the techniques of computer crime since 1985.
The best primer of modern – and by that I mean year 2000 and later – computer crime is Kingpin: How One Hacker Took Over the Billion-Dollar Cybercrime Underground. Modern computer crime is more like the classic sort of crime you've seen in black and white movies: it's mostly about stealing large sums of money. But instead of busting it out of bank vaults Bonnie and Clyde style, it's now done electronically, mostly through ATM and credit card exploits.
Written by Kevin Poulson, another famous reformed hacker, Kingpin is also a compelling read. I've read it twice now. The passage I found most revealing is this one, written after the protagonist's release from prison in 2002:
One of Max’s former clients in Silicon Valley tried to help by giving Max a $5,000 contract to perform a penetration test on the company’s network. The company liked Max and didn’t really care if he produced a report, but the hacker took the gig seriously. He bashed at the company’s firewalls for months, expecting one of the easy victories to which he’d grown accustomed as a white hat. But he was in for a surprise. The state of corporate security had improved while he was in the joint. He couldn’t make a dent in the network of his only client. His 100 percent success record was cracking.
Max pushed harder, only becoming more frustrated over his powerlessness. Finally, he tried something new. Instead of looking for vulnerabilities in the company’s hardened servers, he targeted some of the employees individually.
These “client side” attacks are what most people experience of hackers—a spam e-mail arrives in your in-box, with a link to what purports to be an electronic greeting card or a funny picture. The download is actually an executable program, and if you ignore the warning message
All true; no hacker today would bother with frontal assaults. The chance of success is miniscule. Instead, they target the soft, creamy underbelly of all companies: the users inside. Max, the hacker described in Kingpin, bragged "I've been confident of my 100 percent [success] rate ever since." This is the new face of hacking. Or is it?
One of the most striking things about Ghost In The Wires is not how skilled a computer hacker Kevin Mitnick is (although he is undeniably great), but how devastatingly effective he is at tricking people into revealing critical information in casual conversations. Over and over again, in hundreds of subtle and clever ways. Whether it's 1985 or 2005, the amount of military-grade security you have on your computer systems matters not at all when someone using those computers clicks on the dancing bunny. Social engineering is the most reliable and evergreen hacking technique ever devised. It will outlive us all.
For a 2012 era example, consider the story of Mat Honan. It is not unique.
At 4:50 PM, someone got into my iCloud account, reset the password and sent the confirmation message about the reset to the trash. My password was a 7 digit alphanumeric that I didn’t use elsewhere. When I set it up, years and years ago, that seemed pretty secure at the time. But it’s not. Especially given that I’ve been using it for, well, years and years. My guess is they used brute force to get the password and then reset it to do the damage to my devices.
I heard about this on Twitter when the story was originally developing, and my initial reaction was skepticism that anyone had bothered to brute force anything at all, since brute forcing is for dummies. Guess what it turned out to be. Go ahead, guess!
Did you by any chance guess social engineering … of the account recovery process? Bingo.
After coming across my [Twitter] account, the hackers did some background research. My Twitter account linked to my personal website, where they found my Gmail address. Guessing that this was also the e-mail address I used for Twitter, Phobia went to Google’s account recovery page. He didn’t even have to actually attempt a recovery. This was just a recon mission.
Because I didn’t have Google’s two-factor authentication turned on, when Phobia entered my Gmail address, he could view the alternate e-mail I had set up for account recovery. Google partially obscures that information, starring out many characters, but there were enough characters available, m••••n@me.com. Jackpot.
Since he already had the e-mail, all he needed was my billing address and the last four digits of my credit card number to have Apple’s tech support issue him the keys to my account.
So how did he get this vital information? He began with the easy one. He got the billing address by doing a whois search on my personal web domain. If someone doesn’t have a domain, you can also look up his or her information on Spokeo, WhitePages, and PeopleSmart.
Getting a credit card number is tricker, but it also relies on taking advantage of a company’s back-end systems. … First you call Amazon and tell them you are the account holder, and want to add a credit card number to the account. All you need is the name on the account, an associated e-mail address, and the billing address. Amazon then allows you to input a new credit card. (Wired used a bogus credit card number from a website that generates fake card numbers that conform with the industry’s published self-check algorithm.) Then you hang up.
Next you call back, and tell Amazon that you’ve lost access to your account. Upon providing a name, billing address, and the new credit card number you gave the company on the prior call, Amazon will allow you to add a new e-mail address to the account. From here, you go to the Amazon website, and send a password reset to the new e-mail account. This allows you to see all the credit cards on file for the account — not the complete numbers, just the last four digits. But, as we know, Apple only needs those last four digits.
Phobia, the hacker Mat Honan documents, was a minor who did this for laughs. One of his friends is a 15 year old hacker who goes by the name of Cosmo; he's the one who discovered the Amazon credit card technique described above. And what are teenage hackers up to these days?
Xbox gamers know each other by their gamertags. And among young gamers it’s a lot cooler to have a simple gamertag like “Fred” than, say, “Fred1988Ohio.” Before Microsoft beefed up its security, getting a password-reset form on Windows Live (and thus hijacking a gamer tag) required only the name on the account and the last four digits and expiration date of the credit card on file. Derek discovered that the person who owned the “Cosmo” gamer tag also had a Netflix account. And that’s how he became Cosmo.
“I called Netflix and it was so easy,” he chuckles. “They said, ‘What’s your name?’ and I said, ‘Todd [Redacted],’ gave them his e-mail, and they said, ‘Alright your password is 12345,’ and I was signed in. I saw the last four digits of his credit card. That’s when I filled out the Windows Live password-reset form, which just required the first name and last name of the credit card holder, the last four digits, and the expiration date.”
This method still works. When Wired called Netflix, all we had to provide was the name and e-mail address on the account, and we were given the same password reset.
The techniques are eerily similar. The only difference between Cosmo and Kevin Mitnick is that they were born in different decades. Computer crime is a whole new world now, but the techniques used today are almost identical to those used in the 1980s. If you want to engage in computer crime, don't waste your time developing ninja level hacking skills, because computers are not the weak point.
People are.
| [advertisement] How are you showing off your awesome? Create a Stack Overflow Careers profile and show off all of your hard work from Stack Overflow, Github, and virtually every other coding site. Who knows, you might even get recruited for a great new position! |
Twenty-four years ago today, I had a very bad day.
On August 8, 1988, I was a senior in high school. I was working my after school and weekend job at Safeway as a cashier, when the store manager suddenly walked over and said I better stop ringing up customers and talk to my mother on the store phone right now. Mom told me to come home immediately because, well, there were police at the front door asking for me with some legal papers in hand.
Like I said, definitely not a good day. The only sliver of good news was that I was still 17 at the time, so I enjoyed the many protections that the law provides to a minor. Which I shall now throw away by informing the world that I am a dirty, filthy, reprehensible adult criminal. Thanks, law!
One of the problems you had in the pre-Internet 1980s as a hardcore computer geek was that all the best bulletin boards and online services were kind of expensive. Either because you had to pay an hourly fee to access them, like CompuServe, or because they were a long distance modem call. Or both. Even after the 1984 AT&T breakup, long distance at around 20-30 cents a minute was a far, far cry from today's rates. (Does anyone actually even worry about how much voice calls cost any more, to anywhere in the world? This, my friends, is progress.)
Remember, too, that this is back when 9600 baud modems were blazing, state of the art devices. For perspective, the ultra-low-power wireless bluetooth on your phone is about 80 times faster. If you wanted to upload or download any warez software, that meant potentially hours on your modem at rates of around $20/hour. Adjusted for inflation, that's closer to $40 in 2012 dollars. My family wasn't well off enough to afford a second telephone line, so most of my calling was done late at night both because the rates were lower, and also so that I wouldn't be monopolizing the telephone. Nothing was worse than the dreaded "mom picked up the phone" disconnect to an elite difficult-to-access BBS with limited slots.
One way or another, I eventually got involved with the seedier side of the community, even joining a lesser Apple // pirate group. Probably my main claim to fame is that while trolling BBSes, I personally discovered and recruited a guy who turned out to be an amazing cracker. He was so good he eventually got recruited away.
I was, at best, a footnote to a footnote to a footnote in Apple // history. This was mainly a process of self-discovery for me. I learned I was the type of geek who doesn't even bother attending his high school prom, partially because I was still afraid of girls even as a high school senior, yes, but mainly because I was so addicted to computers and playing my tiny role in these nascent online communities. I was, and am, OK with that. This is the circuitous path of 30 years that led me to create Stack Overflow. And there's more, so much more, but I can't talk about it yet.
But addicted, I think, is too weak a word for what I felt about being a part of these oddball, early online home computer communities. It was more like an all-consuming maniacal blood lust. So obtaining access to free, unlimited long distance calling rapidly became an urgent priority in my teenage life. I needed it. I needed it so bad. I had to have it to talk on the phone to the other members of my motley little crew, who were spread all over the USA, as well as for calling BBSes.
I can't remember exactly how I found it, probably on one of the BBSes, but I eventually discovered a local 804 area code number for "calling cards" that accepted a 5 digit PIN, entered via touch-tone phone. Try over and over, and you might find some valid PIN codes that let you attain the holy grail of free long distance calling. Only one small problem: it's a crime. But, at least to my addled teenage brain, this was a victimless crime, one that I had to commit. The spice must flow!
All I had to do is write software to tell the modem to dial over and over and try different combinations. Because I was a self-taught programmer, this was no problem. But because I was an overachieving self-taught programmer, I didn't just write a program. No, I went off and built a full-blown toolkit in AppleBasic, with complete documentation and the best possible text user interface I could muster, and then uploaded it to my favorite BBSes so every other addict could get their online modem fix, too. I called it The Hacking Construction Set, and I spent months building it. I didn't just gold plate, I platinum plated this freaking thing, man. (Yes, I know the name isn't really correct. I read as many 2600 textfiles as the next guy. This is mere phreaking, not hacking, but I guess I was shooting for poetic license. Maybe you could use the long distance dialing codes to actually hack remote machines, or something.)
I never knew if anyone else ever used my little program to dial for calling codes. It certainly worked for me, and I tried my level best to make it work for all the possible dialing situations I could think of. It even had an intro screen with music and graphics of my own creation. But searching now, for the first time in 24 years, I found my old Hacking Construction Set disk image on an Apple ROM site. It even has real saved numbers in the dialing list! Someone was using my illicit software!
If you're curious, fire up your favorite Apple // emulator and give the disk image a spin. Don't forget to connect your modem. There's full blown documentation accessible from the main menu. Which, re-reading now, was actually not half bad, if I do say so myself:
I used to regularly call BBSes in Florida, California, and Missouri? That's news to me; I haven't seen any of this stuff in over 24 years! All I did was upload a disk image to a few BBSes in 1986. After all that time, to discover that someone used and loved my little bit of software still gives me a little thrill. What higher praise is there for a software developer?
About that trouble. Using my own software got me in trouble with the law. And deservedly so; what I wrote the software to do was illegal. I hired a local lawyer (who, as I recall, was missing a hand; he had a prosthetic hand that was almost impossible not to look at) who represented me. It was quite clear at preliminary hearings that the Chesterfield County court system did not see any computer crime cases, and they had absolutely no idea what to make of me, or what this was all about. All they saw was a smart kid with a bit of bad judgment who loved computers and was headed to the University of Virginia, most likely not a life as a career criminal. So the case was dismissed for the cost of lawyer's fees. Which, for the record, I had to pay myself, using my income as a Safeway cashier.
This was definitely a wake up call for me; in the summer of 1988, I was about to graduate from high school, and I thought I'd try being just a regular guy at college, with less of an obsessive focus on computers that causes me to get in trouble with the law, and perhaps spread my wings to other interests. Who knows, maybe even girls!
That didn't last long. Because after all these years, I must confess I've grown to love my own bad judgment. It's led me to the most fascinating places.
| [advertisement] Stack Overflow Careers matches the best developers (you!) with the best employers. You can search our job listings or create a profile and even let employers find you. |
When you're hired at Google, you only have to do the job you were hired for 80% of the time. The other 20% of the time, you can work on whatever you like – provided it advances Google in some way. At least, that's the theory.
Google's 20 percent time policy is well known in software engineering circles by now. What's not as well known is that this concept dates all the way back to 1948 at 3M.
In 1974, 3M scientist Art Fry came up with a clever invention. He thought if he could apply an adhesive (dreamed up by colleague Spencer Silver several years earlier) to the back of a piece of paper, he could create the perfect bookmark, one that kept place in his church hymnal. He called it the Post-It Note. Fry came up with the now iconic product (he talks to the Smithsonian about it here) during his "15 percent time," a program at 3M that allows employees to use a portion of their paid time to chase rainbows and hatch their own ideas. It might seem like a squishy employee benefit. But the time has actually produced many of the company's best-selling products and has set a precedent for some of the top technology companies of the day, like Google and Hewlett-Packard.
There's not much documentation on HP's version of this; when I do find mentions of it, it's always referred to as a "convention", not an explicit policy. Robert X. Cringely provides more detail:
Google didn’t invent that: HP did. And the way the process was instituted at HP was quite formal in that the 10 percent time was after lunch on Fridays. Imagine what it must have been like on Friday afternoons in Palo Alto with every engineer working on some wild-ass idea. And the other part of the system was that those engineers had access to what they called “lab stores” — anything needed to do the job, whether it was a microscope or a magnetron or a barrel of acetone could be taken without question on Friday afternoons from the HP warehouses. This enabled a flurry of innovation that produced some of HP’s greatest products including those printers.
Maybe HP did invent this, since they've been around since 1939. Dave Raggett, for example, apparently played a major role in inventing HTML on his 10% time at HP.
Although the concept predates Google, they've done more to validate it as an actual strategy and popularize it in tech circles than anyone else. Oddly enough, I can't find any mention of the 20% time benefit listed on the current Google jobs page, but it's an integral part of Google's culture. And for good reason: notable 20 percent projects include GMail, Google News, Google Talk, and AdSense. According to ex-employee Marissa Meyer, as many as half of Google's products originated from that 20% time.
At Hewlett-Packard, 3M, and Google, "many" of their best and most popular products come from the thin sliver of time they granted employees to work on whatever they wanted to. What does this mean? Should we all be goofing off more at work and experimenting with our own ideas? That's what the book The 20% Doctrine explores.
Closely related to 20% time is the Hack Day. Hack Days carve out a specific 24 hour timeframe from the schedule, encouraging large groups to come together to work collaboratively (or in friendly competition) during that period. Chad Dickerson instituted one of the first at Yahoo in 2005.
The Friday before, I had organized the first internal Hack Day at Yahoo! with the help of a loosely-organized band of people around the company. The “hack” designation for the day was a tip of the hat to hacker culture, but also a nod to the fact that we were trying to fix a system that didn’t work particularly well. The idea was really simple: all the engineers in our division were given the day off to build anything they wanted to build. The only rules were to build something in 24 hours and then show it at the end of the period. The basic structure of the event itself was inspired by what we had seen at small startups, but no one had attempted such an event at a large scale at an established company.
The first Yahoo! Hack Day was clearly a success. In a company that was struggling to innovate, about seventy prototypes appeared out of nowhere in a single 24-hour period and they were presented in a joyfully enthusiastic environment where people whooped and yelled and cheered. Sleep-deprived, t-shirt-clad developers stayed late at work on a Friday night to show prototypes they had built for no other reason than they wanted to build something. In his seminal book about open source software, The Cathedral and the Bazaar, Eric Raymond wrote: “Every good work of software starts by scratching a developer’s personal itch.” There clearly had been a lot of developer itching around Yahoo! but it took Hack Day to let them issue a collective cathartic scratch.
Atlassian's version, a quarterly ShipIt Day, also dates back to 2005. Interestingly, they also attempted to emulate Google's 20% time policy with mixed results.
Far and away, the biggest problem was scheduling time for 20% work. As one person put it, “Getting 20% time is incredibly difficult amongst all the pressure to deliver new features and bug fixes.” Atlassian has frequent product releases, so it is very hard for teams to schedule ‘down time’. Small teams in particular found it hard to afford time away from core product development. This wasn’t due to Team Leaders being harsh. It was often due to developers not wanting to increase the workload on their peers while they did 20% work. They like the products they are developing and are proud of their efforts. However, they don’t want to be seen as enjoying a privilege while others carry the workload.
I think there's enough of a track record of documented success that it's worth lobbying for something like Hack Days or 20% time wherever you work. But before you do, consider if you and your company are ready:
You can't realistically achieve 20% time, or even a single measly hack day, if there's absolutely zero slack in the schedule. If everyone around you is working full-tilt boogie as hard as they can, all the time, that's … probably not healthy. Sure, everyone has crunch times now and then, but if your work environment feels like constant crunch time, you'll need to deal with that first. For ammunition, try Tom Demarco's book Slack.
If anyone gets flak for not "looking busy", your company's work culture may not be able to support an initiative like this. There has to be buy-in at the pointy-haired-boss level that time spent thinking and daydreaming is a valid part of work. Daydreaming is not the antithesis of work; on the contrary, creative problem solving requires it.
When given the freedom to "work on whatever you want", the powers that be have to really mean it for the work to matter. Mostly that means providing employees the unfettered freedom to fail miserably at their skunkworks projects, sans repercussion or judgment. Without failure, and lots of the stuff, there can be no innovation, or true experimentation. The value of (quickly!) learning from failures and moving on is enormous.
If there isn't a healthy respect for individual experimentation versus the neverending pursuit of the Next Thing on the collective project task list, these initiatives are destined to fail. You have to truly believe, as a company, and as peers, that crucial innovations and improvements can come from everyone at the company at any time, in bottom-up fashion – they aren't delivered from on high at scheduled release intervals in the almighty Master Plan.
Having some official acknowledgement that time spent working on whatever you think will make things better around these here parts is not just tolerated – but encouraged – might go a long way towards making work feel a lot less like work.
| [advertisement] What's your next career move? Stack Overflow Careers has the best job listings from great companies, whether you're looking for opportunities at a startup or Fortune 500. You can search our job listings or create a profile and let employers find you. |
When I wrote about TN LCD panels 5 years ago, I considered them acceptable, despite their overall mediocrity, mostly due to the massive price difference.
Unfortunately, the vast majority of LCDs on the market now are TN. You can opt to pay a little bit more for one of the few models with *VA – if there are any available in the size you want. *-IPS is widely considered the best all around LCD display technology, but it is rapidly being pushed into the vertical "pro" graphics designer market due to the big jump in price. It's usually not an option, unless you're willing to pay more than twice as much for a monitor.
But when the $499 iPad 3 delivers an amazingly high resolution IPS panel that's almost reference quality, I found myself a whole lot less satisfied with the 27" TN LCDs on my desktop. And on my laptop. And everywhere else in my life.
I'll spare you all the exposition and jump to the punchline. I am now the proud owner of three awesome high resolution (2560x1440) 27" IPS LCDs, and I paid less than a thousand dollars for all three of them.
(If you're curious about the setup, I use Ergotron monitor arms to fit everything in there.)
I won't deny that it is a little weird, because everything is in Korean. I replaced the Korean 3 prong power cord in the power brick with a regular US power cord I had laying around. But a monitor is a monitor, and the IPS panel is stunning. The difference between TN and IPS is vast in every measurable dimension. No bad pixels on these three panels, either. Although, as my friend Scott Wasson of Tech Report fame says, "every pixel on a TN panel is a bad pixel".
How is this possible? You can thank Korea. All three of these monitors were ordered from Korean eBay vendors, where a great 27" IPS LCD goes for the equivalent of around $250 in local currency. They tack on $100 for profit and shipping to the USA, then they're in business. It's definitely a grey market, but something is clearly out of whack, because no domestic monitor of similar quality and size can be had for anything under $700.
I wanted to get this out there, because I'm not sure how long this grey market will last, and these monitors are truly incredible deals. Heck, it's worth it just to get out of the awful TN display ghetto most of us are stuck in. Scott Wasson got the exact same model of Korean LCD I did, and his thorough review concludes:
Even with those last couple of quirks uncovered, I still feel like I won this thing in a drawing or something. $337 for a display of this quality is absolutely worth it, in my view. You just need to keep your eyes open to the risks going into the transaction, risks I hope I've illustrated in the preceding paragraphs. In many ways, grabbing a monitor like this one on the cheap from eBay is the ultimate tinkerer's gambit. It's risky, but the payoff is huge: a combination of rainbow-driven eye-socket ecstasy and the satisfying knowledge that you paid less than half what you might pay elsewhere for the same experience.
There are literally dozens of variants of these Korean 27" LCDs, but the model I got is the FSM-270YG. Before you go rushing off to type ebay.com in your browser address bar, remember that these are bare-bones monitors being shipped from Korea. They work great, don't get me wrong, but they are the definition of no-frills:
Although the noise-to-signal ratio is off the charts, it might be worth visiting the original overclock.net thread on these inexpensive Korean monitors. There's some great info buried in there, if you can manage to extract it from the chaos. And if you're looking for a teardown of this particular FSM-270YG model (minus the OSD, though), check out the TFT Central review.
In the past, I favored my wallet over my eyes, and chose TN. I now deeply regret that decision. But the tide is turning, and high quality IPS displays are no longer extortionately expensive, particularly if you buy them directly from Korea. Is it a little risky? Sure, but all signs point to the risk being fairly low.
In the end, I decided my eyes deserve better than TN. Maybe yours do too.
| [advertisement] Hiring developers? Post your open positions with Stack Overflow Careers and reach over 20MM awesome devs already on Stack Overflow. Create your satisfaction-guaranteed job listing today! |
One of my favorite movie scenes in recent memory is from The Last King of Scotland, a dramatized "biography" of the megalomaniac dictator Idi Amin, as seen through the eyes of a fictional Scottish personal physician.
Idi Amin I want you to tell me what to do! Garrigan You want ME to tell YOU what to do? Amin Yes, you are my advisor. You are the only one I can trust in here. You should have told me not to throw the Asians out, in the first place! Garrigan I DID! Amin But you did not persuade me, Nicholas. You did not persuade me!
If you haven't watched this movie yet, you should. It is amazing. (For trivia buffs, this is the video clip that prompted me to write YouTube vs. Fair Use. The kind folks at vive.ly originally offered to host this fair use video clip, and I took them up on that offer, because I still can't find anywhere to host it.)
What I love about this tour de force of a scene – beyond the incredible acting – is that it illustrates just how powerful of a force persuasion really is. In the hands of a madman or demagogue, dangerously powerful. Hopefully you don't deal with too many insane dictators on a daily basis, but the reason this scene works so well is the unavoidable truth it exposes: to have any hope of influencing others, you must be able to persuade them.
Steve Yegge is as accomplished a software engineer as I can think of. I was amazed to hear him tell us repeatedly and at length on a podcast that the one thing every software engineer should know is not how to write amazing code, but how to market themselves and their project. What is marketing except persuasion?
Marc Hedlund, who founded Wesabe and is now the VP of Engineering at Etsy, thinks of himself not as a CEO or boss, but as the Lobbyist-in-Chief. I believe that could be re-written as Persuader-in-Chief with no loss of meaning or nuance.
I was recently asked how I run our development team. I said, “Well, basically I blog about something I think we should do, and if the blog post convinces the developers, they do it. If not, I lobby for it, and if that fails too, the idea falls on the floor. They need my approval to launch something, but that’s it. That’s as much ‘running things’ as I do, and most of the ideas come from other people at this point, not from me and my blog posts. I’ve argued against some of our most successful ideas, so it’s a good thing I don’t try to exert more control.”
I’m exaggerating somewhat; of course I haven’t blogged about all of our ideas yet. But I do think of myself as Lobbyist-in-Chief, and I have lots of good examples of cases where I failed to talk people into an idea and it didn’t happen as a result. One person I said this to asked, “So who holds the product vision, then?” and I replied, “Well, I guess I do,” but really that’s not right. We all do. The product is the result of the ideas that together we’ve agreed to pursue. I recruit people based on their interest in and enthusiasm about the ideas behind Wesabe, and then set them loose, and we all talk and listen constantly. That’s how it works — and believe it or not, it does work.
So how do we persuade? Primarily, I think, when we lead by example. Even if that means getting down on your knees and cleaning a toilet to show someone else how it's done. But maybe you're not a leader. Maybe you're just a lowly peon. Even as a peon, it's still possible to persuade your team and those around you. A commenter summarized this grassroots method of persuasion nicely:
Science and data are among the best ways to be objectively persuasive, but remember that data alone isn't the reductionist end of every single topic. Beware the 41 shades of blue pitfall.
Yes, it’s true that a team at Google couldn’t decide between two blues, so they’re testing 41 shades between each blue to see which one performs better. I had a recent debate over whether a border should be 3, 4 or 5 pixels wide, and was asked to prove my case. I can’t operate in an environment like that. I’ve grown tired of debating such minuscule design decisions. There are more exciting design problems in this world to tackle.
If I measure by click data alone, all Internet advertising should have breasts in it. Incorporate data, by all means. But you need to tell a bigger, grander, more inspiring story than that to be truly persuasive.
I re-read Letter from a Birmingham Jail every year because I believe it is the single best persuasive essay I've ever read. It is remarkably persuasive without ever resorting to anger, incivility, or invective. Read it now. But do more than just read; study it. How does it work? Why does it work? Does it cite any data? What techniques make this essay so incredibly compelling?
Nobody ever changed anything by remaining quiet, idly standing by, or blending into the faceless, voiceless masses. If you ever want to effect change, in your work, in your life, you must learn to persuade others.
| [advertisement] How are you showing off your awesome? Create a Stack Overflow Careers profile and show off all of your hard work from Stack Overflow, Github, and virtually every other coding site. Who knows, you might even get recruited for a great new position! |
Stack Overflow – like most online communities I've studied – naturally trends toward increased strictness over time. It's primarily a defense mechanism, an immune system of the sort a child develops after first entering school or daycare and being exposed to the wide, wide world of everyday sneezes and coughs with the occasional meningitis outbreak. It isn't always a pleasant process, but it is, unfortunately, a necessary one if you want to survive.
Consider this question from two years ago:
New programming jargon you coined?
What programming terms have you coined that have taken off in your own circles (i.e. have heard others repeat it)? It might be within your own team, workplace or garnered greater popularity on the Internet.
Write your programming term, word or phrase in bold text followed by an explanation, citation and/or usage example so we can use it in appropriate context.
Don't repeat common jargon already ingrained in the programming culture like: kludge, automagically, cruft, etc. (unless you coined it).
This question serves in the spirit of communication among programmers through sharing of terminology with each other, to benefit us by its propagation within our own teams and environments.
Is this even a question, really? How many answers does it have?
Three hundred and eighty six!
A question that invites 386 different "answers" isn't a question at all. It's an opinion survey, a poll, a List of X. I suppose you could argue that reading through all those responses would teach you something about programming, but it was pretty clear that the bulk of the responses were far more about laughs and GTKY (Getting to Know You) than learning. That's why it was eventually deleted by experienced Stack Overflow community members. Although it is somewhat borderline in terms of learning, and I didn't personally vote to delete it, I tend to agree that it was correctly deleted. Though opinions vary.
I won't bore you with the entire history, our so-called "war on fun", and the trouble with popularity. Ultimately, Stack Overflow is a college, not a frat house. All the content on the site must exist to serve the mission of learning over entertainment – even if that means making difficult calls about removing some questions and answers that fail to meet those goals, plus or minus 10 percent.
In terms of programmer culture, though, there is precedent in the form of The Jargon File. Unfortunately, we don't have a good designated place for deleted "too fun" questions to live, but all Stack Exchange content is licensed under Creative Commons in perpetuity. Which means, with proper attribution, we can give it a permanent home on our own blogs. So I did. I've collected the top 30 Stack Overflow New Programming Jargon entries below, as judged by the Stack Overflow community. Enjoy.*
Using if(constant == variable) instead of if(variable == constant), like if(4 == foo). Because it's like saying "if blue is the sky" or "if tall is the man".
For when you just Gotta Catch 'Em All.
try {
}
catch (Exception ex) {
// Gotcha!
}
You know the style of brackets where the opening brace goes on the end of the current line, e.g. this?
if (a == b) {
printf("hello");
}
We used to refer to this style of brackets as "Egyptian brackets". Why? Compare the position of the brackets with the hands in the picture. (This style of brackets is used in Kernighan and Ritchie's book The C Programming Language, so it's known by many as K&R style.)
A bug submitted by a user who thinks he knows a lot more about the system's design than he really does. Filled with irrelevant technical details and one or more suggestions (always wrong) about what he thinks is causing the problem and how we should fix it.
Also related to Drug Report (a report so utterly incomprehensible that whoever submitted it must have been smoking crack.), Chug Report (where the submitter is thought to have had one too many), and Shrug Report (a bug report with no error message or repro steps and only a vague description of the problem. Usually contains the phrase "doesn't work.")
A feature added for no other reason than to draw management attention and be removed, thus avoiding unnecessary changes in other aspects of the product.
I don't know if I actually invented this term or not, but I am certainly not the originator of the story that spawned it.
This started as a piece of Interplay corporate lore. It was well known that producers (a game industry position, roughly equivalent to PMs) had to make a change to everything that was done. The assumption was that subconsciously they felt that if they didn't, they weren't adding value.
The artist working on the queen animations for Battle Chess was aware of this tendency, and came up with an innovative solution. He did the animations for the queen the way that he felt would be best, with one addition: he gave the queen a pet duck. He animated this duck through all of the queen's animations, had it flapping around the corners. He also took great care to make sure that it never overlapped the "actual" animation.
Eventually, it came time for the producer to review the animation set for the queen. The producer sat down and watched all of the animations. When they were done, he turned to the artist and said, "that looks great. Just one thing - get rid of the duck."
The process of taking a well-designed piece of code and, through a series of small, reversible changes, making it completely unmaintainable by anyone except yourself.
A riff on strongly typed. Used to describe an implementation that needlessly relies on strings when programmer & refactor friendly options are available.
For example:
Excessively stringly typed code is usually a pain to understand and detonates at runtime with errors that the compiler would normally find.
A computer bug that disappears or alters its characteristics when an attempt is made to study it. (Wikipedia)
When web designers add a doctype declaration but don't bother to write valid markup.
<!DOCTYPE html> <BLINK>Now on sale!</BLINK>
A generalized name for the clueless/new developer.
Found as we were developing a framework component that required minimal knowledge of how it worked for the other developers. We would always phrase our questions as: "What if Jimmy forgets to update the attribute?"
This led to the term: "Jimmy-proof" when referring to well designed framework code.
A hypothetical bug predicted to exist based on a small number of possibly related event log entries and vague anecdotal reports from users, but it is difficult (if not impossible) to reproduce on a dev machine because you don't really know if it's there, and if it is there what is causing it. (see Higgs-Boson)
I'm writing a scifi novel from the POV of an AI, and their internal language has a lot of programming jargon in it. One of the more generalizable terms is "nopping", which comes from assembler NOP for no-operation. It's similar to 'nap', but doesn't imply sleep, just zoning out. "Stanislav sat watching the screensaver and nopped for a while."
An adjective to describe a feature that's so early in the planning stages that it might as well be imaginary. We cribbed this one from Yehuda Katz, who used it in his closing keynote at last year's Windy City Rails to describe some of Rails' upcoming features.
Code with too many layers.
Baklava is a delicious pastry made with many paper-thin layers of phyllo dough. While thin layers are fine for a pastry, thin software layers don’t add much value, especially when you have many such layers piled on each other. Each layer has to be pushed onto your mental stack as you dive into the code. Furthermore, the layers of phyllo dough are permeable, allowing the honey to soak through. But software abstractions are best when they don’t leak. When you pile layer on top of layer in software, the layers are bound to leak.
A catastrophic data destroying bug. "Oh the humanity!"
Also related to Counterbug (a bug you present when presented with a bug caused by the person presenting the bug) and Bloombug (a bug that accidentally generates money).
When project management adds more pressure (fires someone, moves deadlines forward, subtracts resources from the project, etc).
Code that cannot be fixed. Like the Hydra of legend, every new fix introduces two new bugs. It should be rewritten.
A bug in the application that has existed so long that it is now part of the expected functionality, and user support is required to actually fix it.
I've started Loch Ness Monster bug for anything not reproducible / only sighted by one person. I'm hearing a lot of people in the office say it now. (Possible alternates: Bugfoot, Nessiebug.)
Also known as invisible comments, secret comments, or no comments.
When almost every class has the same prefix. IE, when a user clicks on the button, a SmurfAccountView passes a SmurfAccountDTO to the SmurfAccountController. The SmurfID is used to fetch a SmurfOrderHistory which is passed to the SmurfHistoryMatch before forwarding to either SmurfHistoryReviewView or SmurfHistoryReportingView. If a SmurfErrorEvent occurs it is logged by SmurfErrorLogger to ${app}/smurf/log/smurf/smurflog.log
A prototype that ends up in production. Heard this from a tech at the Fermi lab. He said he didn't coin the term but had heard it used a number of times at Fermi.
Sometimes, you just have to talk a problem out. I used to go to my boss and talk about something and he'd listen and then I'd just answer my own question and walk out without him saying a thing. I read about someone that put a rubber duck on their monitor so they could talk to it, so rubberducking is talking your way through a problem.
Placeholder text indicating that documentation is in progress or yet to be completed. Mostly used because FxCop complains when a public function lacks documentation.
/// <summary> /// banana banana banana /// </summary> public CustomerValidationResponse Validate()
Other food-related jargon: Programmer Fuel (Mountain Dew, coffee, Mate, anything which gets you well-caffeinated), Hot Potato (Http and Https respectively. Same number of syllables, but more fun to say), Cake (Marty's noob cake broke the build), Chunky Salsa (based on the chunky salsa rule, a single critical error or bug that renders an entire system unusable, especially in a production environment).
Adding 2 to a variable.
The program (or more likely feature of a program) does exactly what was asked for but when it's deployed it turns out that the problem was misunderstood and it's basically useless.
When you see something strange happening, but the software is telling you everything is fine.
Stands for MEGA MOnolithic meTHod. Often contained inside a God Object, and usually stretches over two screens in height. Megamoths of greater size than 2k LOC have been sighted. Beware of the MEGAMOTH!
Code that is problematic and causes application instability (application "goes down" often). "Did the site go down again? Yeah, Jim must still have some hooker code in there."
When the whole thing collapses after you alter a block of code.
This is just the top 30, what I consider to be the most likely candidates for actual new programming jargon based on community upvotes, not just "funny thing that another programmer typed on a webpage and I felt compelled to upvote for hilarity". Because that would be Reddit. If you're itching to see even more, there are plenty more answers to read – three hundred and fifty six more to be precise. Longtime Stack Overflow user Greg Hewgill maintains an archive of old deleted Stack Overflow questions, but this one hasn't quite made it in there yet. In the meantime, try Stack Printer, or if you have the requisite 10k rep on Stack Overflow, you can view the full soft-deleted question on the site.
* But don't enjoy it too much. We will be watching you.
| [advertisement] What's your next career move? Stack Overflow Careers has the best job listings from great companies, whether you're looking for opportunities at a startup or Fortune 500. You can search our job listings or create a profile and let employers find you. |
If I had to make a list of the top 10 things I've done in my life that I regret, "writing a book" would definitely be on it. I took on the book project mostly because it was an opportunity to work with a few friends whose company I enjoy. I had no illusions going in about the rapidly diminishing value of technical books in an era of pervasive high speed Internet access, and the book writing process only reinforced those feelings.
In short, do not write a book. You'll put in mountains of effort for precious little reward, tangible or intangible. In the end, all you will have to show for it is an out-of-print dead tree tombstone. The only people who will be impressed by that are the clueless and the irrelevant.
As I see it, for the kind of technical content we're talking about, the online world of bits completely trumps the offline world of atoms:
- It's forever searchable.
- You, not your publisher, will own it.
- It's instantly available to anyone, anywhere in the world.
- It can be cut and pasted; it can be downloaded; it can even be interactive.
- It can potentially generate ad revenue for you in perpetuity.
And here's the best part: you can always opt to create a print version of your online content, and instantly get the best of both worlds. But it only makes sense in that order. Writing a book may seem like a worthy goal, but your time will be better spent channeling the massive effort of a book into creating content online. Every weakness I listed above completely melts away if you redirect your effort away from dead trees and spend it on growing a living, breathing website presence online.
A few weeks ago, Hyperink approached me with a concept of packaging the more popular entries on Coding Horror, its "greatest hits" if you will, into an eBook. They seemed to have a good track record doing this with other established bloggers, and I figured it was time to finally practice what I've been preaching all these years. So you can now download Effective Programming: More Than Writing Code for an introductory price of $2.99. It's available in Kindle, iPad, Nook, and PDF formats.
(As of March 2013, the first book was apparently popular enough to warrant a second volume, How to Stop Sucking and Be Awesome Instead)
I've written about the ongoing tension between bits and atoms recently, and I want to be clear: I am a fan of books. I'm just not necessarily a fan of writing them. I remain deeply cynical about current book publishing models, which feel fundamentally broken to me. No matter the price of the book, outside of J.K. Rowling, you're basically buying the author a drink.
As the author, you can expect to make about a dollar on every copy that sells. The publisher makes several times that, so they make a nice profit with as few as, say, five thousand copies sold. Books that sell ten or fifteen thousand are rare, and considered strong sellers. So let's say you strike gold. After working on your book for a year or more, are you going to be happy with a payday of ten to fifteen grand?
Incidentally, don't expect your royalty check right away. The publisher gets paid first, by the bookstores, and the publisher may then hold on to your money for several months before they part with any of it. Yes, this is legal: it's in the publisher's contract. Not getting paid may be a bummer for you, but it's a great deal for the publisher, since they make interest on the float (all the money they owe to their authors) - which is another profit stream. They'll claim one reason for the delay is the sheer administrative challenge of cutting a check within three months (so many authors to keep track of! so many payments!)... a less ridiculous reason is that they have to wait to see whether bookstores are going to return unsold copies of your book for a full refund.
Here's one real world example. John Resig sold 4,128 copies of Pro Javascript, for which he earned a grand total of $1.87 per book once you factor in his advance. This is a book which still sells for $29.54 on Amazon new.
Tellingly, John's second book seems permanently unfinished. It's been listed as "in progress" since 2008. Can't say I blame him. (Update: John explains.)
When I buy books, I want most of that money to go to the author, not the publishing middlemen. I'd like to see a world where books are distributed electronically for very little cost, and almost all the profits go directly to the author. I'm not optimistic this will happen any time soon.
I admire people willing to write books, but I honestly think you have to be a little bit crazy to sit down and pound out an entire book these days. I believe smaller units of work are more realistic for most folks. I had an epic email discussion with Scott Meyers about the merits of technical book publishing versus blogging in 2008, and I don't think either of us budged from our initial positions. But he did launch a blog to document some of his thoughts on the matter, which ended with this post:
My longer-term goal was to engage in a dialogue with people interested in the production of fast software systems such that I could do a better job with the content of [my upcoming book]. Doing that, however, requires that I write up reasonable initial blog posts to spur discussion, and I've found that this is not something I enjoy. To be honest, I view it as overhead. Given a choice between doing background research to learn more about a topic (typically reading something, but possibly also viewing a technical presentation, listening to a technical podcast, or exchanging email with a technical expert) or writing up a blog entry to open discussion, I find myself almost invariably doing the research. One reason for this is that I feel obliged to have done some research before I post, anyway, and I typically find that once I'm done with the research, writing something up as a standalone blog entry is an enterprise that consumes more time than I'm willing to give it. It's typically easier to write the result up in the form of a technical presentation, then give the presentation and get feedback that way.
Overhead? I find this attitude perplexing; the research step is indeed critical, but no less important than writing up your results as a coherent blog entry. If you can't explain the results of your research to others, in writing, in a way they can understand, you don't understand it. And if you aren't willing to publish your research in the form of a simple web page that anyone in the world can visit and potentially learn from, why did you bother doing that research in the first place? Are you really maximizing the value of your keystrokes?
More selfishly, you should always finish by writing up your results purely for your own self-improvement, if nothing else. As Steve Yegge once said: "I have many of my best ideas and insights while blogging." Then you can take all that published writing, fold in feedback and comments from the community, add some editorial embellishment on top, and voilà – you have a great book.
Of course, there's no getting around the fact that writing is just plain hard. Seth Godin's advice for authors still stands:
Lower your expectations. The happiest authors are the ones that don't expect much.
Which, I think, is also good life advice in general. Maybe the easiest way to lower your expectations as an author is by attempting to write one or two blog entries a week, keep going as long as you can, and see where that takes you.
| [advertisement] What's your next career move? Stack Overflow Careers has the best job listings from great companies, whether you're looking for opportunities at a startup or Fortune 500. You can search our job listings or create a profile and let employers find you. |
I'd argue that the last truly revolutionary version of Windows was Windows 95. In the subsequent 17 years, we've seen a stream of mostly minor and often inconsequential design changes in Windows – at its core, you've got the same old stuff: a start menu, a desktop with icons, taskbar at the bottom, overlapping windows, toolbars, and pull-down menus.
Windows 7 may be bigger, prettier, and more refined – finally, a proper sequel to Windows XP – but it's also safe. Rote. Familiar. Maybe a little too safe.
Windows 95 was a big deal because it innovated, because it was a break from the status quo. It sold 40 million copies in a year. It marked the coming of age of the Wintel beige box PC hegemony, and in the process dealt a near death blow to Apple and its rapidly aging System 7 OS.
But we all know how that story ends – with the iPhone in 2007, and most of all the iPad in 2010, Apple popularized the idea of simple touch computing surfaces that are now defining the Post-PC Era. The best way to predict the future is to invent it. And to their credit, Apple did; that is why their star is ascendant. Kind of absurdly scarily ascendant, actually.
It's not like Microsoft isn't investing in R&D. The Surface table looked amazing. Unfortunately, it was also trapped in a ridiculous, giant coffee table form factor that no regular person could afford or even want. That's too bad, because the Surface table was actually … kind of amazing. I've only ever seen one, in the lobby of a Seattle hotel in 2008. I went in skeptical, but when I actually got to try the Surface table, I came away impressed. It was a fascinating and intuitive multi-touch experience … that virtually nobody will ever get to experience or use. The iPad also offers a fascinating and intuitive multi-touch experience; let's compare:
a multi-touch Surface Table priced at $10,000 that, statistically speaking, nobody will ever be able to see or afford
… versus …
a multi-touch iPad in the hands of every consumer with $500 in their pocket
Now guess which of these companies is currently worth umpteen bazillion dollars. Go on, guess! No, it's not Webvan, you jokers.
After using the retina iPad for a while, I was shocked just how much of my everyday computing I can pull off on a tablet. Once you strip away all the needless complexities, isn't a tablet the simplest form of a computer there can be? How could it get any simpler than a tablet? Is this the ultimate and final form of computing? I wonder. It's a display in your hands, with easy full-screen applications that have simple oversize click targets to poke your finger at, and no confusing file systems to puzzle over or power-draining x86 backwards compatibility to worry about. Heck, maybe a tablet is better than traditional PCs, because it sidesteps all the accumulated cruft and hacks the PC ecosystem has accreted over the last 30 years.
If you're Microsoft, this is the point at which you should be crapping your pants in abject fear.
It is nothing less than the first stages of the heat death of the PC ecosystem, the formation of a tidal wave that will flow inexorably forward from this point. But you can't say they didn't see it coming. Bill Gates, of all people, saw this coming all the way back in 1995, the same year Windows 95 was released.
One scary possibility being discussed by Internet fans is whether they should get together and create something far less expensive than a PC which is powerful enough for Web browsing. This new platform would optimize for the datatypes on the Web. Gordon Bell and others approached Intel on this and decided Intel didn't care about a low cost device so they started suggesting that General Magic or another operating system with a non-Intel chip is the best solution.
To be honest, I had almost written Microsoft off at this point, to the "whatever the abomination that IBM is now" enterprisey deadpool. It's not like they would disappear, necessarily, but they no longer had a viable horse in the race for the future of consumer computing devices. In these darkest of hours, I was actually considering … switching to OS X.
That is, until I tried Windows 8, and until I watched Microsoft unveil Surface. No, not the huge table one, the new one that's roughly the size (and one hopes, the price) of the iPad. I was expecting Yet Another Incremental Improvement to Windows, but I got something else altogether.
It took a little longer than originally anticipated, but what's 17 years between friends?
Windows 8 is, in my humble opinion, the most innovative version of Windows Microsoft has released since Windows 95. Maybe ever. And it's good. Really good! I can't remember the last time I was this excited about a Windows release, except when I was kind of obsessively running betas of Windows 95 and waiting for Windows 95 to be released. Don't judge me man!
What's good about Windows 8? A ton of stuff.
That's just a list off the top of my head. But don't take my word for it. Download the free Release Preview and try Windows 8 yourself.
Now, I will warn you that Windows 8 definitely has a wee bit of Jekyll and Hyde going on, because it smushes together two radically different paradigms: the old school mouse and keyboard centric desktop UI, and the new school tablet and touch centric Metro UI. It can be disconcerting to get kicked abruptly from one to the other. It's different, so there's a learning curve. (Protip: using your mouse scroll wheel in a Metro panel scrolls sideways. Don't forget the hover corners, or the right click, either.) But I have to say, this choice seems, at least so far, to be a bit saner approach than the super hard totally incompatible iOS/OSX divide in Apple land.
I expect that most people will decide early on whether they prefer treating their computer like a traditional laptop, or a tablet, and stick to their guns. Fortunately, the tablet stuff in Windows 8 doesn't get in the way. Even if only used as a glorified Start Menu, the Metro interface works surprisingly well – just start typing and match what you want to launch.
What's even more amazing is that Microsoft is actually pricing the upgrade sanely. Can you believe it's only $40 to upgrade from Windows 8 from XP, Vista, or Windows 7? It's like someone at Microsoft woke up and finally listened to what I've desperately been trying to tell them for years.
In the post PC era, Microsoft is betting the company on Windows 8, desperately trying to serve two masters with one operating system. The traditional mouse and keyboard desktop is no longer the default; it is still there, but slightly hidden from view, as the realm of computer nuts, power users, and geeks. For everyone else, the Metro UI puts an all new, highly visual touch and tablet friendly face on the old beige Wintel box. Will Microsoft succeed? I'm not sure yet. But based on what I've seen so far of Windows 8, its pricing, and the new Surface hardware – I'm cautiously optimistic.
| [advertisement] Hiring developers? Post your open positions with Stack Overflow Careers and reach over 20MM awesome devs already on Stack Overflow. Create your satisfaction-guaranteed job listing today! |
Look at this incredible thing Ian Baker created. Look at it!
What you're seeing is not Photoshopped. This is an actual photo of a real world, honest to God double-clawed hammer. Such a thing exists. Isn't that amazing? And also, perhaps, a little disturbing?
That wondrous hammer is a delightful real-world acknowledgement of the epic blog entry PHP: A Fractal of Bad Design.
I can’t even say what’s wrong with PHP, because – okay. Imagine you have uh, a toolbox. A set of tools. Looks okay, standard stuff in there.
You pull out a screwdriver, and you see it’s one of those weird tri-headed things. Okay, well, that’s not very useful to you, but you guess it comes in handy sometimes.
You pull out the hammer, but to your dismay, it has the claw part on both sides. Still serviceable though, I mean, you can hit nails with the middle of the head holding it sideways.
You pull out the pliers, but they don’t have those serrated surfaces; it’s flat and smooth. That’s less useful, but it still turns bolts well enough, so whatever.
And on you go. Everything in the box is kind of weird and quirky, but maybe not enough to make it completely worthless. And there’s no clear problem with the set as a whole; it still has all the tools.
Now imagine you meet millions of carpenters using this toolbox who tell you “well hey what’s the problem with these tools? They’re all I’ve ever used and they work fine!” And the carpenters show you the houses they’ve built, where every room is a pentagon and the roof is upside-down. And you knock on the front door and it just collapses inwards and they all yell at you for breaking their door.
That’s what’s wrong with PHP.
Remember the immediate visceral reaction you had to the double-clawed hammer? That's exactly the reaction most sane programmers have to their first encounter with the web programming language PHP.
This has been going on for years. I published my contribution to the genre in 2008 with PHP Sucks, But It Doesn't Matter.
I'm no language elitist, but language design is hard. There's a reason that some of the most famous computer scientists in the world are also language designers. And it's a crying shame none of them ever had the opportunity to work on PHP. From what I've seen of it, PHP isn't so much a language as a random collection of arbitrary stuff, a virtual explosion at the keyword and function factory. Bear in mind this is coming from a guy who was weaned on BASIC, a language that gets about as much respect as Rodney Dangerfield. So I am not unfamiliar with the genre.
Except now it's 2012, and fellow programmers are still writing long screeds bemoaning the awfulness of PHP!
What's depressing is not that PHP is horribly designed. Does anyone even dispute that PHP is the worst designed mainstream "language" to blight our craft in decades? What's truly depressing is that so little has changed. Just one year ago, legendary hacker Jamie Zawinski had this to say about PHP:
I used to think that PHP was the biggest, stinkiest dump that the computer industry had taken on my life in a decade. Then I started needing to do things that could only be accomplished in AppleScript.
Is PHP so broken as to be unworkable? No. Clearly not. The great crime of PHP is its utter banality. Its continued propularity is living proof that quality is irrelevant; cheap and popular and everywhere always wins. PHP is the Nickelback of programming languages. And, yes, out of frustration with the status quo I may have recently referred to Rasmus Lerdorf, the father of PHP, as history's greatest monster. I've told myself a million times to stop exaggerating.
The hammer metaphor is apt, because at its core, this is about proper tooling. As presciently noted by Alex Papadimoulis:
What we ought to be talking about is not how terrible PHP is – although its continued terribleness is a particularly damning indictment – but how we programmers can culturally displace a deeply flawed tool with a better one. How do we encourage new programmers to avoid picking up the double clawed hammer in favor of, well, a regular hammer?A client has asked me to build and install a custom shelving system. I'm at the point where I need to nail it, but I'm not sure what to use to pound the nails in. Should I use an old shoe or a glass bottle?
How would you answer the question?
- It depends. If you are looking to pound a small (20lb) nail in something like drywall, you'll find it much easier to use the bottle, especially if the shoe is dirty. However, if you are trying to drive a heavy nail into some wood, go with the shoe: the bottle will shatter in your hand.
- There is something fundamentally wrong with the way you are building; you need to use real tools. Yes, it may involve a trip to the toolbox (or even to the hardware store), but doing it the right way is going to save a lot of time, money, and aggravation through the lifecycle of your product. You need to stop building things for money until you understand the basics of construction.
This is not an abstract, academic concern to me. I'm starting a new open source web project with the goal of making the code as freely and easily runnable to the world as possible. Despite the serious problems with PHP, I was forced to consider it. If you want to produce free-as-in-whatever code that runs on virtually every server in the world with zero friction or configuration hassles, PHP is damn near your only option. If that doesn't scare you, then check your pulse, because you might be dead.
Therefore, I'd like to submit a humble suggestion to my fellow programmers. The next time you feel the urge to write Yet Another Epic Critique of PHP, consider that:
We've got a long way to go. One of the explicit goals of my next project is to do whatever we can to buff up a … particular … open source language ecosystem such that it can truly compete with PHP in ease of installation and deployment.
From my perspective, the point of all these "PHP is broken" rants is not just to complain, but to help educate and potentially warn off new coders starting new codebases. Some fine, even historic work has been done in PHP despite the madness, unquestionably. But now we need to work together to fix what is broken. The best way to fix the PHP problem at this point is to make the alternatives so outstanding that the choice of the better hammer becomes obvious.
That's the PHP Singularity I'm hoping for. I'm trying like hell to do my part to make it happen. How about you?
| [advertisement] How are you showing off your awesome? Create a Stack Overflow Careers profile and show off all of your hard work from Stack Overflow, Github, and virtually every other coding site. Who knows, you might even get recruited for a great new position! |
And now for the dramatic conclusion to The Great MP3 Bitrate Experiment you've all been waiting for! The actual bitrates of each audio sample are revealed below, along with how many times each was clicked per the goo.gl URL shortener stats between Thursday, June 21st and Tuesday, June 26th.
| Limburger | ~160kbps VBR | 10,265 |
| Cheddar | 320kbps CBR | 7,183 |
| Gouda | raw CD | 6,159 |
| Brie | ~192kbps VBR | 5,508 |
| Feta | 128kbps CBR | 5,567 |
During that six day period, my overall Amazon CloudFront and S3 bill for these downloaded audio samples was $103.72 for 800 GB of data, across 200k requests.
Based on the raw click stats, it looks like a bunch of folks clicked on the first and second files, then lost interest. Probably because of, y'know, Starship. Still, it's encouraging to note that the last two files were both clicked about 5.5k times for those that toughed their way out to the very end. Of those listeners, 3,512 went on to contribute results. Not bad at all! I mean, considering I made everyone listen to what some people consider to be one of the bestworst "rock" songs of all time. You guys are troopers, taking one in the ear for the team in the name of science. That's what I admire about you.
I belatedly realized after creating this experiment that there was an easy way to cheat. Simply compress all the samples with FLAC, then sort by filesize.
10,836,505 We+Built+This+City+-+Excerpt+(Feta).flac 11,054,288 We+Built+This+City+-+Excerpt+(Limburger).flac 11,294,757 We+Built+This+City+-+Excerpt+(Brie).flac 11,731,999 We+Built+This+City+-+Excerpt+(Cheddar).flac 11,816,415 We+Built+This+City+-+Excerpt+(Gouda).flac
The higher the bitrate, apparently, the less compressible the audio files are with lossless FLAC compression. It's a small difference in absolute file size, but it's enough to sort exactly with quality. At least you can independently verify that I wasn't tricking anyone in this experiment; each sample was indeed different, and the bitrates are what I said they were.
But you guys and gals wouldn't do that, because you aren't dirty, filthy cheaters, right? Of course not. Let's go over the actual results. Remember each sample was ranked in a simple web form from 1 to 5, where 1 is worst quality, and 5 is highest quality.
The summary statistics for the 3,512 data points:
| Avg | Std dev | ||
| 160kbps VBR | (Limburger) | 3.49 | 1.38 |
| 320kbps CBR | (Cheddar) | 3.30 | 1.34 |
| raw CD audio | (Gouda) | 3.34 | 1.26 |
| 192kbps VBR | (Brie) | 3.27 | 1.29 |
| 128kbps CBR | (Feta) | 2.95 | 1.40 |
(If you'd like to perform more detailed statistical analysis, download the Excel 2010 spreadsheet with all the data and have at it.)
Even without busting out hard-core statistics, I think it's clear from the basic summary statistics graph that only one audio sample here was discernably different than the rest – the 128kbps CBR. And by different I mean "audibly worse". I've maintained for a long, long time that typical 128kbps MP3s are not acceptable quality. Even for the worst song ever. So I guess we can consider this yet another blind listening test proving that point. Give us VBR at an average bitrate higher than 128kbps, or give us death!
But what about the claim that people with dog ears can hear the difference between the higher bitrate MP3 samples? Well, first off, it's incredibly strange that the first sample – encoded at a mere 160kbps – does better on average than everything else. I think it's got to be bias from appearing first in the list of audio samples. It's kind of an outlier here for no good reason, so we have to almost throw it out. More fuel for the argument that people can't hear a difference at bitrates above 128kbps, and even if they do, they're probably imagining it. If we didn't throw out this result, we'd have to conclude that the 160kbps sample was somehow superior to the raw CD audio, which is … clearly insane.
Running T-Test and Analysis of Variance (it's in the spreadsheet) on the non-insane results, I can confirm that the 128kbps CBR sample is lower quality with an extremely high degree of statistical confidence. Beyond that, as you'd expect, nobody can hear the difference between a 320kbps CBR audio file and the CD. And the 192kbps VBR results have a barely statistically significant difference versus the raw CD audio at the 95% confidence level. I'm talking absolutely wafer thin here.
Anyway, between the anomalous 160kbps result and the blink-and-you'll-miss-it statistical difference between the 192kbps result and the raw CD audio, I'm comfortable calling this one as I originally saw it. The data from this experiment confirms what I thought all along: for pure listening, the LAME defaults of 192kbps variable bit rate encoding do indeed provide a safe, optimal aural bang for the byte – even dogs won't be able to hear the difference between 192kbps VBR MP3 tracks and the original CD.
| [advertisement] Stack Overflow Careers matches the best developers (you!) with the best employers. You can search our job listings or create a profile and even let employers find you. |
Lately I've been trying to rid my life of as many physical artifacts as possible. I'm with Merlin Mann on CDs:
Although I'd extend that line of thinking to DVDs as well. The death of physical media has some definite downsides, but after owning certain movies once on VHS, then on DVD, and finally on Blu-Ray, I think I'm now at peace with the idea of not owning any physical media ever again, if I can help it.
My current strategy of wishing my physical media collection into a cornfield involves shipping all our DVDs to Second Spin via media mail, and paying our nephew $1 per CD to rip our CD collection using Exact Audio Copy and LAME as a summer project. The point of this exercise is absolutely not piracy; I have no interest in keeping both digital and physical copies of the media I paid for the privilege of owningtemporarily licensing. Note that I didn't bother ripping any of the DVDs because I hardly ever watched them; mostly they just collected dust. But I continue to love music and listen to my music collection on a daily basis. I'll donate all the ripped CDs to some charity or library, and if I can't pull that off, I'll just destroy them outright. Stupid atoms!
CDs, unlike DVDs or even Blu-Rays, are considered reference quality. That is, the uncompressed digital audio data contained on a CD is a nearly perfect representation of the original studio master, for most reasonable people's interpretation of "perfect", at least back in 1980. So if you paid for a CD, you might be worried that ripping it to a compressed digital audio format would result in an inferior listening experience.
I'm not exactly an audiophile, but I like to think I have pretty good ears. I've recommended buying $200+ headphones and headphone amps for quite a while now. By the way: still a good investment! Go do it! Anyhow, previous research and my own experiments led me to write Getting the Best Bang for Your Byte seven years ago. I concluded that nobody could really hear the difference between a raw CD track and an MP3 using a decent encoder at a variable bit rate averaging around 160kbps. Any bit rate higher than that was just wasting space on your device and your bandwidth for no rational reason. So-called "high resolution audio" was recently thoroughly debunked for very similar reasons.
Articles last month revealed that musician Neil Young and Apple's Steve Jobs discussed offering digital music downloads of 'uncompromised studio quality'. Much of the press and user commentary was particularly enthusiastic about the prospect of uncompressed 24 bit 192kHz downloads. 24/192 featured prominently in my own conversations with Mr. Young's group several months ago.
Unfortunately, there is no point to distributing music in 24-bit/192kHz format. Its playback fidelity is slightly inferior to 16/44.1 or 16/48, and it takes up 6 times the space.
There are a few real problems with the audio quality and 'experience' of digitally distributed music today. 24/192 solves none of them. While everyone fixates on 24/192 as a magic bullet, we're not going to see any actual improvement.
The authors of LAME must have agreed with me, because the typical, standard, recommended, default way of encoding any old audio input to MP3 …
lame --preset standard "cd-track-raw.wav" "cd-track-encoded.mp3"
… now produces variable bit rate MP3 tracks at a bitrate of around 192kbps on average.
(Going down one level to the "medium" preset produces nearly exactly 160kbps average, my 2005 recommendation on the nose.)
Encoders have only gotten better since the good old days of 2005. Given the many orders of magnitude improvement in performance and storage since then, I'm totally comfortable with throwing an additional 32kbps in there, going from 160kbps average to 192kbps average just to be totally safe. That's still a miniscule file size compared to the enormous amount of data required for mythical, aurally perfect raw audio. For a particular 4 minute and 56 second music track, that'd be:
| Uncompressed raw CD format | 51 mb |
| Lossless FLAC compression | 36 mb |
| LAME insane encoded MP3 (320kbps) | 11.6 mb |
| LAME standard encoded MP3 (192kbps avg) | 7.1 mb |
Ripping to uncompressed audio is a non-starter. I don't care how much of an ultra audio quality nerd you are, spending 7× or 5× the bandwidth and storage for completely inaudible "quality" improvements is a dagger directly in the heart of this efficiency-loving nerd, at least. Maybe if you're planning to do a lot of remixing and manipulation it might make sense to retain the raw source audio, but for typical listening, never.
The difference between the 320kbps track and the 192kbps track is more rational to argue about. But it's still 1.6 times the size. Yes, we have tons more bandwidth and storage and power today, but storage space on your mobile device will never be free, nor will bandwidth or storage in the cloud, where I think most of this stuff should ultimately reside. And all other things being equal, wouldn't you rather be able to fit 200 songs on your device instead of 100? Wouldn't you rather be able to download 10 tracks in the same time instead of 5? Efficiency, that's where it's at. Particularly when people with dog's ears wouldn't even be able to hear the difference.
Of course you do. On the Internet, nobody knows you're a dog. Personally, I think you're a human being full of crap, but let's drop some science on this and see if you can prove it.
When someone tells me "Dudes, come on, let's steer clear of the worst song ever written!", I say challenge accepted. Behold The Great MP3 Bitrate Experiment!
As proposed on our very own Audio and Video Production Stack Exchange, we're going to do a blind test of the same 2 minute excerpt of a particular rock audio track at a few different bitrates, ranging from 128kbps CBR MP3 all the way up to raw uncompressed CD audio. Each sample was encoded (if necessary), then exported to WAV so they all have the same file size. Can you tell the difference between any of these audio samples using just your ears?
(update: experiment concluded; links removed.)
| Limburger |
| Cheddar |
| Gouda |
| Brie |
| Feta |
Once you've given each audio sample a listen – with only your ears please, not analysis software – fill out this brief form and rate each audio sample from 1 to 5 on encoding quality, where one represents worst and five represents flawless.
Yes, it would be better to use a variety of different audio samples, like SoundExpert does, but I don't have time to do that. Anyway, if the difference in encoding bitrate quality is as profound as certain vocal elements of the community would have you believe it is, that difference should be audible in any music track. To those who might argue that I am trolling audiophiles into listening to one of the worst-slash-best rock songs of all time … over and over and over … to prove a point … I say, how dare you impugn my honor in this manner, sir. How dare you!
I wasn't comfortable making my generous TypePad hosts suffer through the bandwidth demands of multiple 16 megabyte audio samples, so this was a fun opportunity to exercise my long dormant Amazon S3 account, and test out Amazon's on-demand CloudFront CDN. I hope I'm not rubbing any copyright holders the wrong way with this test; I just used a song excerpt for science, man! I'll pull the files entirely after a few weeks just to be sure.
You'll get no argument from me that the old standby of 128kbps constant bit rate encoding is not adequate for most music, even today, and you should be able to hear that in this test. But I also maintain that virtually nobody can reliably tell the difference between a 160kbps variable bit rate MP3 and the raw CD audio, much less 192kbps. If you'd like to prove me wrong, this is your big chance. Like the announcer in Smash TV, I say good luck – you're gonna need it.
So which is it – are you a dog or a man? Give the samples a listen, then rate them. I'll post the results of this experiment in a few days.
| [advertisement] Hiring developers? Post your open positions with Stack Overflow Careers and reach over 20MM awesome devs already on Stack Overflow. Create your satisfaction-guaranteed job listing today! |
About a year and a half ago, I researched the state of routers: about as unsexy as it gets but essential to the stability, reliability, and security of your Internet connection. My conclusion?
This is boring old plain vanilla commodity router hardware, but when combined with an open source firmware, it is a massive improvement over my three year old, proprietary high(ish) end router. The magic router formula these days is a combination of commodity hardware and open-source firmware. I'm so enamored of this one-two punch combo, in fact, I might even say it represents the future. Not just of the everyday workhorse routers we all need to access the Internet – but the future of all commodity hardware.
I felt a little bad about that post, because I quickly migrated from the DD-WRT open source firmware to OpenWRT and then finally settled on Tomato. I guess that's open source, too many choices with nobody to really tell you what's going to work reliably on your particular hardware. But the good news is that I've been running Tomato quite happily with total stability for about a year now – primarily because it is gloriously simple, but also because it has the most functional quality of service (QoS) implementation.
Why does functional Quality of Service matter so very much in a router? Unless you have an Internet connection that's only used by your grandmother to visit her church's website on Sundays, QoS is the difference between a responsive Internet and one that's brutally dog slow.
Ever sat in an internet shop, a hotel room or lobby, a local hotspot, and wondered why you can't access your email? Unknown to you, the guy in the next room or at the next table is hogging the internet bandwidth to download the Lord Of The Rings Special Extended Edition in 1080p HDTV format. You're screwed - because the hotspot router does not have an effective QoS system. In fact, I haven't come across a shop or an apartment block locally that has any QoS system in use at all. Most residents are not particularly happy with the service they [usually] pay for.
When I switched from DD-WRT and OpenWRT to Tomato, I had to buy a different router, because Tomato only supports certain router hardware, primarily Broadcom. The almost universal recommendation was the Asus RT-N16, so that's what I went with.
And it is still an excellent choice. If you just want a modern, workhorse single band wireless N router that won't break the bank, but has plenty of power and memory to run Tomato, definitely try the Asus RT-N16. It's currently available for under $80 (after $10 rebate). Once you get Tomato on there, you've got a fine combination of hardware and software. Take it from this SmallNetBuilder user review:
I'm a semigeek. Some of the stuff on this site confuses me. But I figured out enough to get this router and install Tomato USB. Great combination. Have not had any problems with the router. Love all the features that Tomato gives me. Like blocking my son's iPod after 7 PM. Blocking certain websites. Yeah, I know you can do that with other routers but Tomato made it easy. Also love the QoS features. Netflix devices get highest bandwidth while my wife's bittorrent gets low.
Review was too heavily slanted against the Asus software, which I agree is crap. I bought the router for its hardware specs. Large memory. Fast processor. Gigabyte lan. 2 USB ports.
What's not to love? Well, the dual band thing, mainly. If you want a truly top of the line router with incredible range, and simultaneous dual band 2.4 GHz and 5 GHz performance bragging rights, fortunately there's the Asus RT-N66U.
This is, currently at least, the state of the art in routers. It has a faster CPU and twice the memory (256 MB) of the RT-N16. But at $190 it is also over twice the price. Judge for yourself in the SmallNetBuilder review:
As good as the RT-66U is, our wireless performance results once again show that no router is good in every mode that we test. But that said, the Dark Knight clearly outperformed both the NETGEAR WNDR4500 and Cisco Linksys E4200V2 in most of our two and three-stream tests. And it's the only router in recent memory able to reach to our worst-case/lowest-signal test location on the 5 GHz band, albeit with barely-usable throughput. Still, this is an accomplishment in itself.
If you're going to spend close to $200 for a wireless router, you should get a lot for your money. The Dark Knight seems to deliver wireless performance to justify its high price and has routing speed fast enough to handle any service a consumer is likely to have, even our friends in Europe and Asia.
Its only weakness? Take a guess. Oh wait, no need to guess, it's the same "weakness" the RT-N16 shared, the sketchy Asus firmware it ships with out of the box. That's why we get our Tomato on, people! There is complete and mature support for the RT-N66U in Tomato; for a walkthrough on how to get it installed (don't be shy, it's not hard) Check out Shadow Andy's TomatoUSB firmware flashing guide.
Does having nice router hardware with a current open source firmware matter? Well, if your livelihood depends on the Internet like mine does, then I certainly think so.
At the very least, if you or someone you love is also an Internet fan and hasn't given any particular thought to what router they use, maybe it's time to start checking into that. Now if you'll excuse me, I'm going to go donate to the Tomato project.
| [advertisement] What's your next career move? Stack Overflow Careers has the best job listings from great companies, whether you're looking for opportunities at a startup or Fortune 500. You can search our job listings or create a profile and let employers find you. |
I hesitate to say everyone should have a child, because becoming a parent is an intensely personal choice. I try my best to avoid evangelizing the experience, but the deeper in I get, the more I believe that nothing captures the continued absurdity of the human condition better than having a child does.
After becoming a parent, the first thing you'll say to yourself is, my God, it is a miracle any of us even exist, because I want to freakin' kill this kid at least three times a day. But then your child will spontaneously hug you, or tell you some stupid joke that they can't stop laughing at, or grab for your hand while crossing the street and then … well, here we all are, aren't we? I'm left wondering if I'll ever be able to love other people – or for that matter myself – as much as I love my children. Unconditional, irrational, nonsensical love. That's humanity in a nutshell.
Parenting is by far the toughest job I've ever had. It makes my so-called career seem awfully quaint in comparison.
My favorite part of the parenting process, though, is finally being able to talk to my kids. When the dam breaks and all that crazy stuff they had locked away in those tiny brains for the first two years comes uncontrollably pouring out. Finding out what they're thinking about and what kind of people they are at last. Watching them discover and explore the surface of language is utterly fascinating. After spending two years trying to guess – with extremely limited success – what they want and need, truly, what greater privilege is there than to simply ask them? Language: Best. Invention. Ever. I like it so much I'm using it right now!
Language also allows kids to demonstrate just what crazy little roiling balls of id they (and by extension, we) all are on the inside. Kids don't know what it means to be mad, to be happy, to be sad. They have to be taught what emotions are, how to handle them, and how to deal in a constructive way with everything the world is throwing at them. You'll get a ringside seat to this process not as a passive observer, but as their coach and spirit guide. They have no coping mechanisms except the ones we teach them. The difference between a child who freaks out at the slightest breeze, and a child who can confidently navigate an unfamiliar world? The parents.
See, I told you this was going to be tough.
There are of course innumerable books on parenting and child-rearing, most of which I have no time to read because by the time I'm done being a parent for the day, I'm too exhausted to read more about it. And, really, who wants to read about parenting when you're living the stuff 24/7? Except on Parenting Stack Exchange, of course. However, there is one particular book I happened to discover that was shockingly helpful, even after barely ten pages in. If you ever need to deal with children aged 2 to 99, stop reading right now and go buy How to Talk So Kids Will Listen & Listen So Kids Will Talk.
We already own three copies. And you're welcome.
What's so great about this book? I originally found it through A.J. Jacobs, who I mentioned in Trust Me, I'm Lying. Here's how he describes it:
The best marriage advice book I’ve read is a paperback called How to Talk So Kids Will Listen & Listen So Kids Will Talk. As you might deduce from the title, it wasn’t meant as a marriage advice book. But the techniques in this book are so brilliant, I use them in every human interaction I can, no matter the age of the conversant. It’s a strategy that was working well until today.
The book was written by a pair of former New York City teachers, and their thesis is that we talk to kids all wrong. You can’t argue with kids, and you shouldn’t dismiss their complaints. The magic formula includes: listen, repeat what they say, label their emotions. The kids will figure out the solution themselves.
I started using it on Jasper, who would throw a tantrum about his brothers monopolizing the pieces to Mouse Trap. I listened, repeated what he said, and watched the screaming and tears magically subside. It worked so well, I decided, why limit it to kids? My first time trying it on a grown-up was one morning at the deli. I was standing behind a guy who was trying unsuccessfully to make a call on his cell.
“Oh come on! I can’t get a signal here? Dammit. This is New York.”
He looked at me.
“No signal?” I say. “Here in New York?” (Repeat what they say.)
“It’s not like we’re in goddamn Wisconsin.”
“Mmmm.” (Listen. Make soothing noises.)
“We’re not on a farm. It’s New York, for God’s sake,” he said.
“That’s frustrating,” I say. (Label their emotions.)
He calmed down.
This book taught me that, as with so many other things in life, I've been doing it all wrong. I thought it was my job as a parent to solve problems for my children, to throw myself on life's figurative grenades to protect them. Consider the following illustrated examples from the book.
Notice how she cleverly lets the child reach an alternative solution himself, rather than providing the "solution" to him on a silver platter as the all-seeing, all-knowing omniscient adult. This honestly would never have occurred to me, because, well, if we're out of Toastie Crunchies, then we are out of freaking Toastie Crunchies!
I've learned to fall back whenever possible to simply describing things or situations instead of judging or pontificating. I explain the consequences of potential actions rather than jumping impatiently to "don't do that".
How to Talk So Kids Will Listen & Listen So Kids Will Talk is full of beautiful little insights on human interaction like this, and I was surprised to find how often what I thought was a good parenting behavior was working against us. Turns out, children aren't the only ones who have trouble dealing with their emotions and learning to communicate. I haven't just improved my relationship with my kids using the practical advice in this book, I've improved my interactions with all human beings from age 2 to 99.
Kids will teach you, if you let them. They'll teach you that getting born is the easy part. Anyone can do that in a day. But becoming a well-adjusted human being? That'll take the rest of your life.
| [advertisement] How are you showing off your awesome? Create a Stack Overflow Careers profile and show off all of your hard work from Stack Overflow, Github, and virtually every other coding site. Who knows, you might even get recruited for a great new position! |
I've been fortunate to have some measure of success in my life, primarily through this very blog over the last eight years, and in creating Stack Overflow and Stack Exchange over the last four years. With the birth of our twin girls, I've had a few months to pause and reflect on those experiences. What did I do right? What did I do wrong? How would I do things differently next time? What advice should I give other people based on my own life experiences?
The short answer is that I wouldn't.
There are too many paths forward in life; I barely feel qualified to make decisions about what to do in my own life, much less recommend strategies for others in theirs. On some level I feel like Jared Fogle, who lost 245 pounds eating nothing but Subway subs. Maybe that worked for him, but how does that make it a valid diet strategy for the rest of the world? In other words, what I did worked for me, but I'm crazy.
That's also never stopped anyone else from handing out terrible life advice hand over fist before. So I figure why not. Who wants to live forever?
Under pressure to make some sense of what I've been doing with my life for the last eight years, I put together a small presentation which I delivered yesterday at this year's Atlassian summit.
How to Stop Sucking and Be Awesome Instead
If you're reading this abstract, you're not awesome enough. Attend this session to unlock the secrets of Jeff Atwood, world famous blogger and industry leading co-founder of Stack Overflow and Stack Exchange. Learn how you too can determine clear goals for your future and turn your dreams into reality through positive-minded conceptualization techniques.* Within six to eight weeks, you'll realize the positive effects of Jeff Atwood's wildly popular Coding Horror blog in your own life, transporting you to an exciting new world of wealth, happiness and political power.
* May or may not also include working hard on things that matter for the rest of your life.
I hope you can forgive me for the title, and I guess the rest of the abstract, and probably the entirety of the presentation too, but I find it's easier to be serious when I'm not being entirely serious. At any rate, it's complicated.
Here's what I've seen work:1. Embrace the Suck
2. Do It in Public
3. Pick Stuff That Matters
The slides explain. When put on the spot, under duress, I have selectively doled out this advice to a few people over the years – and miraculously, I've seen them succeed using these rules, too.
(I put a lot of additional explanatory detail in the slide notes that you'll only see if you download the full presentation.)
Mostly, I think it's the fear that gets us, in all its forms. Fear of not achieving. Fear of not keeping up. Fear of looking dumb. Fear of being inadequate. Fear of being exposed. Fear of failure. The only thing preventing us from being awesome is our own fear of sucking.
So that's why I say we embrace it. Who wants to live forever?
| [advertisement] Stack Overflow Careers matches the best developers (you!) with the best employers. You can search our job listings or create a profile and even let employers find you. |
I didn't intend for Please Don't Learn to Code to be so controversial, but it seemed to strike a nerve. Apparently a significant percentage of readers stopped reading at the title.
So I will open with my own story. I think you'll find it instructive.
My mom once told me that the only reason she dated my father is because her mother told her to stay away from that boy, he's a bad influence.
If she had, I would not exist.
True story, folks.
I'd argue that the people who need to learn to code will be spurred on most of all by honesty, not religious faith in the truthiness of code as a universal good. Go in knowing both sides of the story, because there are no silver bullets in code. If, after hearing both the pros and cons, you still want to learn to code, then by all means learn to code. If you're so easily dissuaded by hearing a few downsides to coding, there are plenty of other things you could spend your time learning that are more unambiguously useful and practical. Per Michael Lopp, you could learn to be a better communicator. Per Gina Trapani, you could learn how to propose better solutions. Slinging code is just a tiny part of the overall solution in my experience. Why optimize for that?
On the earliest computers, everyone had to be a programmer because there was no software. If you wanted the computer to do anything, you wrote code. Computers in the not so distant past booted directly to the friendly blinking cursor of a BASIC interpreter. I view the entire arc of software development as a field where we programmers spend our lives writing code so that our fellow human beings no longer need to write code (or even worse, become programmers) to get things done with computers. So this idea that "everyone must know how to code" is, to me, going backwards.
I fully support a push for basic Internet literacy. But in order to be a competent driver, does everyone need to know, in detail, how their automobile works? Must we teach all human beings the basics of being an auto mechanic, and elevate shop class to the same level as English and Mathematics classes? Isn't knowing how to change a tire, and when to take your car in for an oil change, sufficient? If your toilet is clogged, you shouldn't need to take a two week in depth plumbing course on toiletcademy.com to understand how to fix that. Reading a single web page, just in time, should be more than adequate.
What is code, in the most abstract sense?
code (kōd) …
- A system of signals used to represent letters or numbers in transmitting messages.
- A system of symbols, letters, or words given certain arbitrary meanings, used for transmitting messages requiring secrecy or brevity.
- A system of symbols and rules used to represent instructions to a computer…
— The American Heritage Dictionary of the English Language
Is it punchcards? Remote terminals? Emacs? Textmate? Eclipse? Visual Studio? C? Ruby? JavaScript? In the 1920s, it was considered important to learn how to use slide rules. In the 1960s, it was considered important to learn mechanical drawing. None of that matters today. I'm hesitant to recommend any particular approach to coding other than the fundamentals as outlined in Code: The Hidden Language of Computer Hardware and Software, because I'm not sure we'll even recognize coding in the next 20 or 30 years. To kids today, perhaps coding will eventually resemble Minecraft, or building levels in Portal 2.
But everyone should try writing a little code, because it somehow sharpens the mind, right? Maybe in the same abstract way that reading the entire Encyclopedia Brittanica from beginning to end does. Honestly, I'd prefer that people spend their time discovering what problems they love and find interesting, first, and researching the hell out of those problems. The toughest thing in life is not learning a bunch of potentially hypothetically useful stuff, but figuring out what the heck it is you want to do. If said research and exploration leads to coding, then by all means learn to code with my blessing … which is worth exactly what it sounds like, nothing.
So, no, I don't advocate learning to code for the sake of learning to code. What I advocate is shamelessly following your joy. For example, I received the following email yesterday.
I am a 45 year old attorney/C.P.A. attempting to abandon my solo law practice as soon as humanly possible and strike out in search of my next vocation. I am actually paying someone to help me do this and, as a first step in the "find yourself" process, I was told to look back over my long and winding career and identify those times in my professional life when I was doing something I truly enjoyed.
Coming of age as an accountant during the PC revolution (when I started my first "real" job at Arthur Andersen we were still billing clients to update depreciation schedules manually), I spend a lot of time learning how to make computers, printers, and software (VisiCalc anyone?) work. This quasi-technical aspect of my work reached its apex when I was hired as a healthcare financial analyst for a large hospital system. When I arrived for my first day of work in that job, I learned that my predecessor had bequeathed me only a one page static Excel spreadsheet that purported to "analyze" a multi-million dollar managed care contract for a seven hospital health system. I proceeded to build my own spreadsheet but quickly exceeded the database functional capacity of Excel and had to teach myself Access and thereafter proceeded to stretch the envelope of Access' spreadsheet capabilities to their utmost capacity – I had to retrieve hundreds of thousands of patient records and then perform pro forma calculations on them to see if the proposed contracts would result in more or less payment given identical utilization.
I will be the first to admit that I was not coding in any professional sense of the word. I did manage to make Access do things that MS technical support told me it could not do but I was still simply using very basic commands to bend an existing application to my will. The one thing I do remember was being happy. I typed infinitely nested commands into formula cells for twelve to fourteen hours a day and was still disappointed when I had to stop.
My experience in building that monster and making it run was, to date, my most satisfying professional accomplishment, despite going on to later become CFO of another healthcare facility, a feat that should have fulfilled all of my professional ambitions at that time. More than just the work, however, was the group of like-minded analysts and IT folks with whom I became associated as I tried, failed, tried, debugged, and continued building this behemoth of a database. I learned about Easter Eggs and coding lore and found myself hacking into areas of the hospital mainframe which were completely offlimits to someone of my paygrade. And yet, I kept pursuing my "professional goals" and ended up in jobs/careers I hated doing work I loathed.
Here's a person who a) found an interesting problem, b) attempted to create a solution to the problem, which naturally c) led them to learning to code. And they loved it. This is how it's supposed to work. I didn't become a programmer because someone told me learning to code was important, I became a programmer because I wanted to change the rules of the video games I was playing, and learning to code was the only way to do that. Along the way, I too fell in love.
All that to say that as I stand at the crossroads once more, I still hear the siren song of those halcyon days of quasi-coding during which I enjoyed my work. My question for you is whether you think it is even possible for someone of my vintage to learn to code to a level that I could be hired as a programmer. I am not trying to do this on the side while running the city of New York as a day job. Rather, I sincerely and completely want to become a bona fide programmer and spend my days creating (and/or debugging) something of value.
Unfortunately, calling yourself a "programmer" can be a career-limiting move, particularly for someone who was a CFO in a previous career. People who work with money tend to make a lot of money; see Wall Street.
But this isn't about money, is it? It's about love. So, if you want to be a programmer, all you need to do is follow your joy and fall in love with code. Any programmer worth their salt immediately recognizes a fellow true believer, a person as madly in love with code as they are, warts and all. Welcome to the tribe.
And if you're reading this and thinking, "screw this Jeff Atwood guy, who is he to tell me whether I should learn to code or not", all I can say is: good! That's the spirit!
| [advertisement] Hiring developers? Post your open positions with Stack Overflow Careers and reach over 20MM awesome devs already on Stack Overflow. Create your satisfaction-guaranteed job listing today! |
If you've studied design at all, you've probably encountered Lorem Ipsum placeholder text at some point. Anywhere there is text, but the meaning of that text isn't particularly important, you might see Lorem Ipsum.
Most people recognize it as Latin. And it is. But it is arbitrarily rearranged and not quite coherent Latin, extracted from a book Cicero wrote in 45 BC. Here's the complete quote, with the bits and pieces that make up Lorem Ipsum highlighted.
Nemo enim ipsam voluptatem, quia voluptas sit, aspernatur aut odit aut fugit, sed quia consequuntur magni dolores eos, qui ratione voluptatem sequi nesciunt, neque porro quisquam est, qui dolorem ipsum, quia dolor sit amet, consectetur, adipisci[ng] velit, sed quia non numquam [do] eius modi tempora inci[di]dunt, ut labore et dolore magnam aliquam quaerat voluptatem. Ut enim ad minima veniam, quis nostrum exercitationem ullam corporis suscipit laboriosam, nisi ut aliquid ex ea commodi consequatur? Quis autem vel eum iure reprehenderit, qui in ea voluptate velit esse, quam nihil molestiae consequatur, vel illum, qui dolorem eum fugiat, quo voluptas nulla pariatur?
At vero eos et accusamus et iusto odio dignissimos ducimus, qui blanditiis praesentium voluptatum deleniti atque corrupti, quos dolores et quas molestias excepturi sint, obcaecati cupiditate non provident, similique sunt in culpa, qui officia deserunt mollitia animi, id est laborum et dolorum fuga.
But what does it all mean? Here's an English translation with the same parts highlighted.
Nor again is there anyone who loves or pursues or desires to obtain pain of itself, because it is pain, but occasionally circumstances occur in which toil and pain can procure him some great pleasure. To take a trivial example, which of us ever undertakes laborious physical exercise, except to obtain some advantage from it? But who has any right to find fault with a man who chooses to enjoy a pleasure that has no annoying consequences, or one who avoids a pain that produces no resultant pleasure?
On the other hand, we denounce with righteous indignation and dislike men who are so beguiled and demoralized by the charms of pleasure of the moment, so blinded by desire, that they cannot foresee the pain and trouble that are bound to ensue; and equal blame belongs to those who fail in their duty through weakness of will, which is the same as saying through shrinking from toil and pain.
Of course the whole point of Lorem Ipsum is that the words aren't supposed to mean anything, so attempting to divine its meaning is somewhat … unsatisfying, perhaps by design. Lorem Ipsum is a specific form of what is generally referred to somewhat cheekily as "Greeking":
Greeking is a style of displaying or rendering text or symbols, not always from the Greek alphabet. Greeking obscures portions of a work for the purpose of either emphasizing form over details or displaying placeholders for unavailable content. The name is a reference to the phrase "Greek to me", meaning something that one cannot understand, so that it might as well be in a foreign language.
So when you need filler or placeholder text, you naturally reach for Lorem Ipsum as the standard. The theory is that, since it's unintelligible, nobody will attempt to read it, but instead focus on other aspects of the design. If you put readable text in the design, people might think the text is important to the design, that the text represents the sort of content you expect to see, or that the text somehow itself needs to be copyedited and updated and critiqued.
(Regular readers of this blog may remember that I am fond of using Alice in Wonderland in this manner, when I need a bit of text to demonstrate something in a post.)
However, not everyone agrees that relying on a standard boilerplate greeked placeholder text is appropriate, even going so far as to call for the death of Lorem Ipsum. I think it depends what you're trying to accomplish. I once noted that it's better to use real content to avoid Blank Page Syndrome, for example.
There are quite a few websites that helpfully offer up the classic Lorem Ipsum text in various eminently copy-and-pastable forms.
Beyond that, if you just want a bunch of, uh, interesting text to fill an area, there a lot – and I mean a lot – of websites to choose from. So many in fact that I was a little overwhelmed trying to index them all. I've tried to broadly categorize the ones I did find, below. If you know of more, feel free to leave a comment and I'll update the list.
Novelty
Clever English Tricks
Literature |
ProfessionsSocial NetworksTV, Movies and Media
Possibly NSFWRegional |
This is a lot to go through. If I had to pick a favorite, I'd say Fillerati because it's all dignified and stuff. But I think truer to the spirit of Lorem Ipsum are definitely the homophonic transformations, which consistently blow my mind every time I attempt to read them. Isn't that the implied goal of any properly greeked text? You were one deliciously perverse professor of romance languages, Howard L. Chace.
In today's Pinteresting world, images are arguably more important than text. But what is the Lorem Ipsum of images? Is there even one? I guess you could just slap some Lorem Ipsum text in an image, but where is the fun in that? Anyway, there are also plenty of websites offering up placeholder images of various types to go along with your Lorum Ipsum placeholder text.
I'm not sure the world needs any more Lorem Ipsum-alikes than we already have at this point. Like the market for ironic t-shirts, the Internet has ensured that our placeholder greeked text needs have not merely been met but vastly exceeded for the forseeable future. But after discovering all the creative things people have done with Lorem Ipsum, and text placeholders in general, it's sure tempting to dream yet another one up, isn't it?
| [advertisement] Hiring developers? Post your open positions with Stack Overflow Careers and reach over 20MM awesome devs already on Stack Overflow. Create your satisfaction-guaranteed job listing today! |
The whole "everyone should learn programming" meme has gotten so out of control that the mayor of New York City actually vowed to learn to code in 2012.
A noble gesture to garner the NYC tech community vote, for sure, but if the mayor of New York City actually needs to sling JavaScript code to do his job, something is deeply, horribly, terribly wrong with politics in the state of New York. Even if Mr. Bloomberg did "learn to code", with apologies to Adam Vandenberg, I expect we'd end up with this:
10 PRINT "I AM MAYOR" 20 GOTO 10
Fortunately, the odds of this technological flight of fancy happening – even in jest – are zero, and for good reason: the mayor of New York City will hopefully spend his time doing the job taxpayers paid him to do instead. According to the Office of the Mayor home page, that means working on absenteeism programs for schools, public transit improvements, the 2013 city budget, and … do I really need to go on?
To those who argue programming is an essential skill we should be teaching our children, right up there with reading, writing, and arithmetic: can you explain to me how Michael Bloomberg would be better at his day to day job of leading the largest city in the USA if he woke up one morning as a crack Java coder? It is obvious to me how being a skilled reader, a skilled writer, and at least high school level math are fundamental to performing the job of a politician. Or at any job, for that matter. But understanding variables and functions, pointers and recursion? I can't see it.
Look, I love programming. I also believe programming is important … in the right context, for some people. But so are a lot of skills. I would no more urge everyone to learn programming than I would urge everyone to learn plumbing. That'd be ridiculous, right?
The "everyone should learn to code" movement isn't just wrong because it falsely equates coding with essential life skills like reading, writing, and math. I wish. It is wrong in so many other ways.
I suppose I can support learning a tiny bit about programming just so you can recognize what code is, and when code might be an appropriate way to approach a problem you have. But I can also recognize plumbing problems when I see them without any particular training in the area. The general populace (and its political leadership) could probably benefit most of all from a basic understanding of how computers, and the Internet, work. Being able to get around on the Internet is becoming a basic life skill, and we should be worried about fixing that first and most of all, before we start jumping all the way into code.
Please don't advocate learning to code just for the sake of learning how to code. Or worse, because of the fat paychecks. Instead, I humbly suggest that we spend our time learning how to …
These are skills that extend far beyond mere coding and will help you in every aspect of your life.
| [advertisement] How are you showing off your awesome? Create a Stack Overflow Careers profile and show off all of your hard work from Stack Overflow, Github, and virtually every other coding site. Who knows, you might even get recruited for a great new position! |
Fair warning: this is a blog post about automated cat feeders. Sort of. But bear with me, because I'm also trying to make a point about software. If you have a sudden urge to click the back button on your browser now, I don't blame you. I don't often talk about cats, but when I do, I make it count.
We've used automated cat feeders since 2007 with great success. (My apologies for the picture quality, but it was 2007, and camera phones were awful.)
Feeding your pets using robots might sound impersonal and uncaring. Perhaps it is. But I can't emphasize enough how much of a daily lifestyle improvement it really is to have your pets stop associating you with ritualized, timed feedings. As my wife so aptly explained:I do not miss the days when the cats would come and sit on our heads at 5 AM, wanting their breakfast.
Me neither. I haven't stopped loving our fuzzy buddies, but this was also before we had onetwothree children. We don't have a lot of time for random cat hijinks these days. Anyway, once we set up the automated feeders in 2007, it was a huge relief to outsource pet food obsessions to machines. They reliably delivered a timed feeding at 8am and 8pm like clockwork for the last five years. No issues whatsoever, other than changing the three D batteries about once a year, filling the hopper with kibble about once a month, and an occasional cleaning.
Although they worked, there were still many details of the automated feeders' design that were downright terrible. I put up with these problems because I was so happy to have automatic feeders that worked at all. So when I noticed that the 2012 version of these feeders appeared to be considerably updated, I went ahead and upgraded immediately on faith alone. After all, it had been nearly five years! Surely the company had improved their product a bit since then … right? Well, a man can dream, can't he?
When I ordered the new feeders, I assumed they would be a little better than what I had before.
The two feeders don't look so radically different, do they? But pay attention to the details.
These are, to be sure, a bunch of dumb, nitpicky details. Did the old version feed our cats reliably? Yes, it did. But it was also a pain to clean and maintain, a sort of pain that I endured weekly, for reasons that made no sense to me other than arbitrarily poor design choices. But when I bought the new version of the automated feeder, I was shocked to discover that nearly every single problem I had with the previous generation was addressed. I felt as if the Petmate Corporation™ was actually listening to all the feedback from the people who used their product, and actively refined the product to address our complaints and suggestions.
My point, and I do have one, is that details matter. Details matter, in fact, a hell of a lot. Whether in automatic cat feeders, or software. As my friend Wil Shipley once said:
This is still one of my favorite quotes about software. It's something we internalized heavily when building Stack Overflow. Getting the details right is the difference between something that delights, and something customers tolerate.
Your software, your product, is nothing more than a collection of tiny details. If you don't obsess over all those details, if you think it's OK to concentrate on the "important" parts and continue to ignore the other umpteen dozen tiny little ways your product annoys the people who use it on a daily basis – you're not creating great software. Someone else is. I hope for your sake they aren't your competitor.
The details are hard. Everyone screws up the details at first, just like Petmate did with the first version of this automatic feeder. And it's OK to screw up the details initially, provided …
We were maniacal about listening to feedback from avid Stack Overflow users from the earliest days of Stack Overflow in August 2008. Did you know that we didn't even have comments in the first version of Stack Overflow? But it was obvious, based on user feedback and observed usage, that we desperately needed them. There are now, at the time I am writing this, 1,569 completed feature requests; that's more than one per day on average.
Imagine that. Someone who cares about the details just as much as you do.
| [advertisement] Stack Overflow Careers matches the best developers (you!) with the best employers. You can search our job listings or create a profile and even let employers find you. |
Despite popular assertions to the contrary, science tells us that money can buy happiness. To a point.
Recent research has begun to distinguish two aspects of subjective well-being. Emotional well-being refers to the emotional quality of an individual's everyday experience — the frequency and intensity of experiences of joy, stress, sadness, anger, and affection that make one's life pleasant or unpleasant. Life evaluation refers to the thoughts that people have about their life when they think about it. We raise the question of whether money buys happiness, separately for these two aspects of well-being. We report an analysis of more than 450,000 responses to the Gallup-Healthways Well-Being Index, a daily survey of 1,000 US residents conducted by the Gallup Organization. […] When plotted against log income, life evaluation rises steadily. Emotional well-being also rises with log income, but there is no further progress beyond an annual income of ~$75,000.
For reference, the federal poverty level for a family of four is currently $23,050. Once you reach a little over 3 times the poverty level in income, you've achieved peak happiness, as least far as money alone can reasonably get you.
This is something I've seen echoed in a number of studies. Once you have "enough" money to satisfy the basic items at the foot of the Maslow's Hierarchy of Needs pyramid – that is, you no longer have to worry about food, shelter, security, and perhaps having a bit of extra discretionary money for the unknown – stacking even more money up doesn't do much, if anything, to help you scale the top of the pyramid.
But even if you're fortunate enough to have a good income, how you spend your money has a strong influence on how happy – or unhappy – it will make you. And, again, there's science behind this. The relevant research is summarized in If money doesn't make you happy, then you probably aren't spending it right (pdf).
Most people don't know the basic scientific facts about happiness — about what brings it and what sustains it — and so they don't know how to use their money to acquire it. It is not surprising when wealthy people who know nothing about wine end up with cellars that aren't that much better stocked than their neighbors', and it should not be surprising when wealthy people who know nothing about happiness end up with lives that aren't that much happier than anyone else's. Money is an opportunity for happiness, but it is an opportunity that people routinely squander because the things they think will make them happy often don't.
You may also recognize some of the authors on this paper, in particular Dan Gilbert, who also wrote the excellent book Stumbling on Happiness that touched on many of the same themes.
What is, then, the science of happiness? I'll summarize the basic eight points as best I can, but read the actual paper (pdf) to obtain the citations and details on the underlying studies underpinning each of these principles.
Things get old. Things become ordinary. Things stay the same. Things wear out. Things are difficult to share. But experiences are totally unique; they shine like diamonds in your memory, often more brightly every year, and they can be shared forever. Whenever possible, spend money on experiences such as taking your family to Disney World, rather than things like a new television.
Human beings are intensely social animals. Anything we can do with money to create deeper connections with other human beings tends to tighten our social connections and reinforce positive feelings about ourselves and others. Imagine ways you can spend some part of your money to help others – even in a very small way – and integrate that into your regular spending habits.
Because we adapt so readily to change, the most effective use of your money is to bring frequent change, not just "big bang" changes that you will quickly grow acclimated to. Break up large purchases, when possible, into smaller ones over time so that you can savor the entire experience. When it comes to happiness, frequency is more important than intensity. Embrace the idea that lots of small, pleasurable purchases are actually more effective than a single giant one.
Humans adapt readily to both positive and negative change. Extended warranties and insurance prey on your impulse for loss aversion, but because we are so adaptable, people experience far less regret than they anticipate when their purchases don't work out. Furthermore, having the easy "out" of insurance or a generous return policy can paradoxically lead to even more angst and unhappiness because people deprived themselves of the emotional benefit of full commitment. Thus, avoid buying insurance, and don't seek out generous return policies.
Immediate gratification can lead you to make purchases you can't afford, or may not even truly want. Impulse buying also deprives you of the distance necessary to make reasoned decisions. It eliminates any sense of anticipation, which is a strong source of happiness. For maximum happiness, savor (maybe even prolong!) the uncertainty of deciding whether to buy, what to buy, and the time waiting for the object of your desire to arrive.
We tend to gloss over details when considering future purchases, but research shows that our happiness (or unhappiness) largely lies in exactly those tiny details we aren't thinking about. Before making a major purchase, consider the mechanics and logistics of owning this thing, and where your actual time will be spent once you own it. Try to imagine a typical day in your life, in some detail, hour by hour: how will it be affected by this purchase?
Comparison shopping focuses us on attributes of products that arbitrarily distinguish one product from another, but have nothing to do with how much we'll enjoy the purchase. They emphasize characteristics we care about while shopping, but not necessarily what we'll care about when actually using or consuming what we just bought. In other words, getting a great deal on cheap chocolate for $2 may not matter if it's not pleasurable to eat. Don't get tricked into comparing for the sake of comparison; try to weight only those criteria that actually matter to your enjoyment or the experience.
Don't overestimate your ability to independently predict how much you'll enjoy something. We are, scientifically speaking, very bad at this. But if something reliably makes others happy, it's likely to make you happy, too. Weight other people's opinions and user reviews heavily in your purchasing decisions.
Happiness is a lot harder to come by than money. So when you do spend money, keep these eight lessons in mind to maximize whatever happiness it can buy for you. And remember: it's science!
| [advertisement] Hiring developers? Post your open positions with Stack Overflow Careers and reach over 20MM awesome devs already on Stack Overflow. Create your satisfaction-guaranteed job listing today! |
We reflexively instruct our children to always tell the truth. It's even encoded into Boy Scout Law. It's what adults do, isn't it? But do we? Isn't telling the truth too much and too often a bad life strategy – perhaps even dangerous? Is telling children to always tell the truth even itself the whole truth?
One of the most thought provoking articles on the topic, and one I keep returning to, year after year, is I Think You're Fat. It's about the Radical Honesty movement, which proposes that adults follow their own advice and always tell the truth. No matter what.
The [Radical Honesty] movement was founded by a sixty-six-year-old Virginia-based psychotherapist named Brad Blanton. He says everybody would be happier if we just stopped lying. Tell the truth, all the time. This would be radical enough – a world without fibs – but Blanton goes further. He says we should toss out the filters between our brains and our mouths. If you think it, say it. Confess to your boss your secret plans to start your own company. If you're having fantasies about your wife's sister, Blanton says to tell your wife and tell her sister. It's the only path to authentic relationships. It's the only way to smash through modernity's soul-deadening alienation. Oversharing? No such thing.
Yes. I know. One of the most idiotic ideas ever, right up there with Vanilla Coke and giving Phil Spector a gun permit. Deceit makes our world go round. Without lies, marriages would crumble, workers would be fired, egos would be shattered, governments would collapse.
And yet … maybe there's something to it. Especially for me. I have a lying problem. Mine aren't big lies. They aren't lies like "I cannot recall that crucial meeting from two months ago, Senator." Mine are little lies. White lies. Half-truths. The kind we all tell. But I tell dozens of them every day. "Yes, let's definitely get together soon." "I'd love to, but I have a touch of the stomach flu." "No, we can't buy a toy today – the toy store is closed." It's bad. Maybe a couple of weeks of truth-immersion therapy would do me good.
The author, A.J. Jacobs, is a great writer who made a cottage industry out of treating himself like a guinea pig, such as attempting to become the smartest man in the world, spend a year living exactly like the Bible tells us to, and to become the fittest person on Earth. Based on the strength of this article, I bought two of his books; experiments like Radical Honesty are right up his alley.
Radical honesty itself isn't exactly a new concept. It's been parodied in any number of screwball Hollywood comedies such as Liar, Liar (1997) and The Invention of Lying (2009). But there's a big difference between milking this concept for laughs and exploring it as an actual lifestyle among real human beings. Among the ideas raised in the article, which you should go read now, are:
What we often don't acknowledge is that the truth is kind of scary. That's why we have a hard time being honest with ourselves, much less those around us. Reading through all these ambiguous situations that A.J. put himself through, you start to wonder if you understand what truth is, or what it means to decide that something is "true". After summarizing the article in bullet form, I'm surprised there are so many points in favor of honesty, maybe even radical honesty.
But uncompromisingly committing to the whole truth, and nothing but the truth, has a darker side.
My wife tells me a story about switching operating systems on her computer. In the middle, I have to go help our son with something, then forget to come back.
"Do you want to hear the end of the story or not?" she asks.
"Well...is there a payoff?"
"F**k you."
It would have been a lot easier to have kept my mouth closed and listened to her. It reminds me of an issue I raised with Blanton: Why make waves? "Ninety percent of the time I love my wife," I told him. "And 10 percent of the time I hate her. Why should I hurt her feelings that 10 percent of the time? Why not just wait until that phase passes and I return to the true feeling, which is that I love her?"
Blanton's response: "Because you're a manipulative, lying son of a bitch."
Rather than embrace the truth, as Radical Honesty would have us do, Adrian Tan advises us to be wary of the truth.
Most of you will end up in activities which involve communication. To those of you I have a second message: be wary of the truth. I’m not asking you to speak it, or write it, for there are times when it is dangerous or impossible to do those things. The truth has a great capacity to offend and injure, and you will find that the closer you are to someone, the more care you must take to disguise or even conceal the truth. Often, there is great virtue in being evasive, or equivocating. There is also great skill. Any child can blurt out the truth, without thought to the consequences. It takes great maturity to appreciate the value of silence.
I think he's right. But Radical Honesty isn't altogether wrong, either. Let me be clear: Radical Honesty, as a lifestyle, is ridiculous and insane. Advocating telling the truth 100% of the time, no matter what, is harmful extremism. But it's also wonderfully seductive as a concept, because it illustrates how needlessly afraid most of us are of truth – even truths that could potentially help us. Radical Honesty teaches us to be more brave. That is, when it's not destroying our lives and the lives of everyone around us.
Ask yourself:
I believe the true lesson of Radical Honesty is that truth, real truth, is honesty with a purpose. Ideally a noble purpose, but any purpose at all other than "because I could" will suffice. By all means, be brave; embrace the truth. But if your honesty has no purpose, if you can't imagine any positive outcome from being honest, I suggest you're better off keeping it to yourself.
Or even lying.
| [advertisement] What's your next career move? Stack Overflow Careers has the best job listings from great companies, whether you're looking for opportunities at a startup or Fortune 500. You can search our job listings or create a profile and let employers find you. |
To understand this story, you need to understand that grandchildren are like crack cocaine to grandparents. I'm convinced that if our parents could somehow snort our children up their noses to get a bigger fix, they would. And when your parents live out of state, like ours do, access to the Internet isn't just important. No. It is life threatening.
Like Gator in Jungle Fever, grandparents just gotta get their fix of the grandkids every month. And if they don't, if their Internet is broken for any reason, you're going to get an earful via telegraph and facsimile and registered letter until you fix it.
Either way, they're gonna get high. On your kids.
My mom is no exception. So when her computer suddenly stopped working, and she couldn't get updates on her three grandkids, I got frantic calls. Which is odd, because everything had been working fine for a few years now. Once Henry was born in 2009, I set her up with a netbook that had Skype and Firefox set to auto update and she'd been able to video chat with us regularly, no problem at all, since then. So what happened?
My first thought was to hell with it, I'll just buy her a new iPad online via the Apple Store. I'm a big fan of the retina display, and surely the touchy-feely iPad would be more resistant to whatever problem she was having than a netbook, what with its archaic "operating system" and "updates" and "keyboard" and "mouse".
With some urging from my wife (I married well), cooler heads prevailed. What if her problem had nothing to do with the computer, but her Internet connection in some way? Then I'd just be trading one set of problems for another with the iPad. I have no idea how things are set up over there, thousands of miles away. I needed help. Help from a fellow geek who lives nearby and is willing to drive out and assist my poor mom.
My mom doesn't live near where I grew up any more, so I have no friend network there. All I could think of was Geek Squad. I've seen the trucks in our neighborhood, and they've been around a while, so I checked out their website. Maybe they'd work?
When I can buy my mom a new iPad for $399, the idea of paying $299 just to have someone come out and fix her old stuff starts to feel like a really bad idea. But I suppose it's a preview of our disposable computer future, because it's increasingly cheaper to buy a new one than it is to bother fixing the old one. This is the stuff that my friend and iFixit founder Kyle Wiens' nightmares are made of. I'm sorry, Kyle. But it's coming.
I posted my discontent on Twitter, as I am wont to do, and received an interesting recommendation for a site I'd never heard of – Geekatoo.
I was intrigued, first because the site didn't appear to suck which is more than I can say for about half the links I click on, and second because it appealed to my geek instincts. I could post a plea for help for my mom, and a fellow geek, one of my kind who happened to be local, would be willing to head out and assist. I could send out the geek bat-signal! But I was still skeptical. My mom lives in Charlotte, North Carolina which, while not exactly the sticks, isn't necessarily a big tech hub city, either. I figured I had nothing to lose at this point, so I posted the request titled "Mom Needs Tech Support" with the info I had.
Much to my surprise, I got two great bids within 24 hours, geeks with good credentials, and I picked the first one. The estimate was two hours for $45, and he was on-site helping my mom within 2 days from the time I posted.
It turns out that my wife's intuition was correct: the cable internet installer had inexplicably decided to connect my mother's computer to a neighbor's wireless, instead of setting up a WiFi access point for her. So when that neighbor moved away, calamity ensued.
And the results? Well, I think they speak for themselves.
My mom, as usual, exaggerates about her only son. I am far, far from the best son ever. But any website that can make me look like a hero to my mom, and keep my fellow Super User geeks gainfully employed doing superhero work on my behalf gets a huge thumbs up from me.
Needless to say, strongly recommended. If you need reliable local tech support that won't break the bank, and you want to support both your family and your local geek community at the same time, check out Geekatoo.
| [advertisement] How are you showing off your awesome? Create a Stack Overflow Careers profile and show off all of your hard work from Stack Overflow, Github, and virtually every other coding site. Who knows, you might even get recruited for a great new position! |
I've been an eBay user since 1999, and I still frequent eBay as both buyer and seller. In that time, eBay has transformed from a place where geeks sell broken laser pointers to each other, into a global marketplace where businesses sell anything and everything to customers. If you're looking for strange or obscure items, things almost nobody sells new any more, or grey market items for cheap, eBay is still not a bad place to look.
At least for me, eBay still basically works, after all these years. But one thing hasn't changed: the eBay website has always been difficult to use and navigate. They've updated the website recently to remove some of the more egregious cruft, but it's still way too complicated. I guess I had kind of accepted old, complex websites as the status quo, because I didn't realize how bad it had gotten until I compared the experience on the eBay website with the experience of the eBay apps for mobile and tablet.
Unless you're some kind of super advanced eBay user, you should probably avoid the website. The tablet and mobile eBay apps are just plain simpler, easier, and faster to use than the eBay website itself. I know this intuitively from using eBay on my devices and computers, but there's also usability studies with data to prove it, too. To be fair, eBay is struggling under the massive accumulated design debt of a website originally conceived in the late 90s, whereas their mobile and tablet app experiences are recent inventions. It's not so much that the eBay apps are great, but that the eBay website is so very, very bad.
The implied lesson here is to embrace constraints. Having a limited, fixed palette of UI controls and screen space is a strength. A strength we used to have in early Mac and Windows apps, but seem to have lost somewhere along the way as applications got more powerful and complicated. And it's endemic on the web as well, where the eBay website has been slowly accreting more and more functionality since 1999. The nearly unlimited freedom that you get in a modern web browser to build whatever UI you can dream up, and assume as large or as small a page as you like, often ends up being harmful to users. It certainly is in the case of eBay.
If you're starting from scratch, you should always design the UI first, but now that we have such great mobile and tablet device options, consider designing your site for the devices that have the strictest constraints first, too. This is the thinking that led to mobile first design strategy. It helps you stay focused on a simple and uncluttered UI that you can scale up to bigger and beefier devices. Maybe eBay is just going in the wrong direction here; design simple things that scale up; not complicated things you need to scale down.
Above all else, simplify! But why stop there? If building the mobile and tablet apps first for a web property produces a better user experience – why do we need the website, again? Do great tablet and phone applications make websites obsolete?
I don't think there's a clear winner, only pros and cons. But apps will always need websites, if for nothing else other than a source of data, as a mothership to phone home to, and a place to host the application downloads for various devices.
And if you're obliged to build a website, why not build it out so it offers a reasonable experience on a mobile or tablet web browser, too? I have nothing against a premium experience optimized to a particular device, but shouldn't all your users have a premium experience? eBay's problem here isn't mobile or tablets per se, but that they've let their core web experience atrophy so badly. I understand that there's a lot of inertia around legacy eBay tools and long time users, so it's easy for me to propose radical changes to the website here on the outside. Maybe the only way eBay can redesign at all is on new platforms.
Will mobile and tablet apps kill websites? A few, certainly. But only the websites stupid enough to let them.
| [advertisement] What's your next career move? Stack Overflow Careers has the best job listings from great companies, whether you're looking for opportunities at a startup or Fortune 500. You can search our job listings or create a profile and let employers find you. |
It's only a matter of time until your email gets hacked. Don't believe me? Just read this harrowing cautionary tale.
When [my wife] came back to her desk, half an hour later, she couldn’t log into Gmail at all. By that time, I was up and looking at e‑mail, and we both quickly saw what the real problem was. In my inbox I found a message purporting to be from her, followed by a quickly proliferating stream of concerned responses from friends and acquaintances, all about the fact that she had been “mugged in Madrid.” The account had seemed sluggish earlier that morning because my wife had tried to use it at just the moment a hacker was taking it over and changing its settings—including the password, so that she couldn’t log in again.
…
The greatest practical fear for my wife and me was that, even if she eventually managed to retrieve her records, so much of our personal and financial data would be in someone else’s presumably hostile hands that we would spend our remaining years looking over our shoulders, wondering how and when something would be put to damaging use. At some point over the past six years, our [email] correspondence would certainly have included every number or code that was important to us – credit card numbers, bank-account information, medical info, and any other sensitive data you can imagine.
Now get everyone you know to read it, too. Please. It's for their own good.
Your email is the skeleton key to your online identity. When you lose control of your email to a hacker – not if, but when you lose control of your email to a hacker – the situation is dire. Email is a one stop shop for online identity theft. You should start thinking of security for your email as roughly equivalent to the sort of security you'd want on your bank account. It's exceedingly close to that in practice.
The good news, at least if you use GMail, is that you can make your email virtually hacker-proof today, provided you own a cell phone. The fancy geek technical term for this is two factor authentication, but that doesn't matter right now. What matters is that until you turn this on, your email is vulnerable. So let's get started. Not tomorrow. Not next week. Right. Freaking. Now.
Make sure you're logged in. Expand the little drop-down user info panel at the top right of most Google pages. From here, click "Account" to view your account settings.
On the account settings page, click "edit" next to 2-step verification and turn it on.
GMail will walk you through the next few steps. You just need a telephone that can receive SMS text messages. Enter the numeric code sent through the text message to proceed.
Now your password alone is no longer enough to access your email.
Once this is enabled, accessing your email always requires the password, and a code delivered via your cell phone. (You can check the "remember me for 30 days on this device" checkbox so you don't have to do this every time.) With this in place, even if they discover your super sekrit email password, would-be hackers can't do anything useful with it! To access your email, they'd need to somehow gain control of your cell phone, too. I can't see that happening unless you're in some sort of hostage situation, and at that point I think email security is the least of your problems.
Your cell phone isn't the only way to get the secondary PIN you need to access your email. On the account page there are multiple ways to generate verification codes, including adding a secondary backup phone number, and downloading mobile applications that can generate verification codes without a text message (but that requires a smart phone, naturally).
Applications or websites that access your email, and thus necessarily store your email address and password, are also affected. They have no idea that they now need to enter a PIN, too, so they'll all be broken. You'll need to generate app-specific passwords for your email. To do that, visit the accounts page.
Click on authorizing applications & sites, then enter a name for the application and click the Generate Password button.
Let me be clear about this, because it can be confusing: enter that specially generated password in the application, not your master email password.
This effectively creates a list of passwords specific to each application. So you can see the date each one was last used, and revoke each app's permission to touch your email individually as necessary without ever revealing your primary email password to any application, ever. See, I told you, there is a method to the apparent madness.
Either nag your email provider to provide two-factor authentication, or switch over. Email security is critically important these days, and switching is easy(ish). GMail has had fully secure connections for quite a while now, and once you add two-factor authentication to the mix, that's about as much online email safety as you can reasonably hope to achieve short of going back to snail mail.
I know what you're thinking. Yes, this is a pain in the ass. I'll fully acknowledge that. But you know what's an even bigger pain in the ass? Having your entire online identity stolen and trashed by a hacker who happens to obtain your email password one day. Remember that article I exhorted you to read at the beginning? Oh, you didn't read it? Go freaking read it now!
Permit me to channel Jamie Zawinski one last time: "OMG, entering these email codes on every device I access email would be a lot of work! That sounds like a hassle!" Shut up. I know things. You will listen to me. Do it anyway.
I've been living with this scheme for a few months now, and I've convinced my wife to as well. I won't lie to you; it hasn't all been wine and roses for us either. But it is inconvenient in the same way that bank vaults and door locks are. The upside is that once you enable this, your email becomes extremely secure, to the point that you can (and I regularly do) email yourself highly sensitive data like passwords and logins to other sites you visit so you can easily retrieve them later.
If you choose not to do this, well, at least you've educated yourself about the risks. And I hope you're extremely careful with your email password and change it regularly to something complex. You're making life all too easy for the hackers who make a fabulous living from stealing and permanently defacing online identities just like yours.
| [advertisement] Hiring developers? Post your open positions with Stack Overflow Careers and reach over 20MM awesome devs already on Stack Overflow. Create your satisfaction-guaranteed job listing today! |
In the calculus of communication, writing coherent paragraphs that your fellow human beings can comprehend and understand is far more difficult than tapping out a few lines of software code that the interpreter or compiler won't barf on.
That's why, when it comes to code, all the documentation probably sucks. And because writing for people is way harder than writing for machines, the documentation will continue to suck for the forseeable future. There's very little you can do about it.
Except for one thing.
You can learn to read the source, Luke.
The transformative power of "source always included" in JavaScript is a major reason why I coined – and continue to believe in – Atwood's Law. Even if "view source" isn't built in (but it totally should be), you should demand access to the underlying source code for your stack. No matter what the documentation says, the source code is the ultimate truth, the best and most definitive and up-to-date documentation you're likely to find. This will be true forever, so the sooner you come to terms with this, the better off you'll be as a software developer.
I had a whole entry I was going to write about this, and then I discovered Brandon Bloom's brilliant post on the topic at Hacker News. Read closely, because he explains the virtue of reading source, and in what context you need to read the source, far better than I could:
I started working with Microsoft platforms professionally at age 15 or so. I worked for Microsoft as a software developer doing integration work on Visual Studio. More than ten years after I first wrote a line of Visual Basic, I wish I could never link against a closed library ever again.
Using software is different than building software. When you're using most software for its primary function, it's a well worn path. Others have encountered the problems and enough people have spoken up to prompt the core contributors to correct the issue. But when you're building software, you're doing something new. And there are so many ways to do it, you'll encounter unused bits, rusty corners, and unfinished experimental code paths. You'll encounter edge cases that have been known to be broken, but were worked around.
Sometimes, the documentation isn't complete. Sometimes, it's wrong. The source code never lies. For an experienced developer, reading the source can often be faster… especially if you're already familiar with the package's architecture. I'm in a medium-sized co-working space with several startups. A lot of the other CTOs and engineers come to our team for guidance and advice on occasion. When people report a problem with their stack, the first question I ask them is: "Well, did you read the source code?"
I encourage developers to git clone anything and everything they depend on. Initially, they are all afraid. "That project is too big, I'll never find it!" or "I'm not smart enough to understand it" or "That code is so ugly! I can't stand to look at it". But you don't have to search the whole thing, you just need to follow the trail. And if you can't understand the platform below you, how can you understand your own software? And most of the time, what inexperienced developers consider beautiful is superficial, and what they consider ugly, is battle-hardened production-ready code from master hackers. Now, a year or two later, I've had a couple of developers come up to me and thank me for forcing them to sink or swim in other people's code bases. They are better at their craft and they wonder how they ever got anything done without the source code in the past.
When you run a business, if your software has a bug, your customers don't care if it is your fault or Linus' or some random Rails developer's. They care that your software is bugged. Everyone's software becomes my software because all of their bugs are my bugs. When something goes wrong, you need to seek out what is broken, and you need to fix it. You fix it at the right spot in the stack to minimize risks, maintenance costs, and turnaround time. Sometimes, a quick workaround is best. Other times, you'll need to recompile your compiler. Often, you can ask someone else to fix it upstream, but just as often, you'll need to fix it yourself.
- Closed-software shops have two choices: beg for generosity, or work around it.
- Open source shops with weaker developers tend to act the same as closed-software shops.
- Older shops tend to slowly build the muscles required to maintain their own forks and patches and whatnot.
True hackers have come to terms with a simple fact: If it runs on my machine, it's my software. I'm responsible for it. I must understand it. Building from source is the rule and not an exception. I must control my environment and I must control my dependencies.
| [advertisement] Stack Overflow Careers matches the best developers (you!) with the best employers. You can search our job listings or create a profile and even let employers find you. |
I adore words, but let's face it: books suck.
More specifically, so many beautiful ideas have been helplessly trapped in physical made-of-atoms books for the last few centuries. How do books suck? Let me count the ways:
What's the point of a bookshelf full of books other than as an antiquated trophy case of written ideas trapped in awkward, temporary physical relics?
Books should not be celebrated. Words, ideas, and concepts should be celebrated. Books were necessary to store these things, simply because we didn't have any other viable form to contain them. But now we do.
At the risk of stating the obvious, if your goal is to get a written idea in front of as many human beings as efficiently as possible, you shouldn't be publishing dead tree books at all. You should be editing a wiki, writing a blog, or creating a website. That's why the Encyclopedia Britannica officially went out of print in 2012, after a 244 year print run. In the straight-up match between paper and Web, the Encyclopedia Britannica lost. Big time.
The EB couldn’t cover enough: 65,000 topics compared to the almost 4M in the English version of Wikipedia.
Topics had to be consistently shrunk or discarded to make room for new information. E.g., the 1911 entry on Oliver Goldsmith was written by no less than Thomas Macaulay, but with each edition, it got shorter and shorter. EB was thus in the business of throwing out knowledge as much as it was in the business of adding knowledge.
Topics were confined to rectangles of text. This is of course often a helpful way of dividing up the world, but it is also essentially false. The “see also’s” and the attempts at synthetic indexes and outlines (Propædi) helped, but they were still highly limited, and cumbersome to use.
This is why the book scanning efforts of Google Books and The Internet Archive are so important – to unlock the knowledge trapped in all those books and place it online so the entire world can benefit.
In the never-ending human quest for communication, bits have won decisively over atoms. But bits haven't completely replaced atoms for publishing quite yet; that will take a few more decades.
While the Internet is perfectly adequate for basic printed text juxtaposed with images and tables, it is a far cry from the beautiful, complex layout and typography of modern books. Sometimes the medium is part of the message. That's what led computer scientists to create PostScript and TeX, systems of representing the printed page in code as pure mathematics that can scale infinitely, or at least to the best possible resolution of the particular device you're viewing it on. Packaging written content into a special file format preserves these beautiful layouts so you can read the text as originally designed by the author.
It's also fair to argue that writers should be fairly compensated for their work. Clearly nobody is going to pay 5 cents per web page. But there's a long established commercial model of packaging a set of writing together into a coherent format, or "book", and selling that.
You can't always rely on the Internet being available. What if you have no Internet connectivity, or intermittent connectivity? You could periodically harvest a bunch of related web pages every month and package the current versions into a file. And that file can be stored and cached locally on laptops, phones, and servers all over the world. Local files have built in, persistent offline availability.
No, the Internet will not kill the book. But it will change their form permanently; books are no longer pages printed with atoms, they're files printed with bits: eBooks.
The road from atoms to bits is not an easy one, and we're only at the beginning of this journey. eBooks are vastly more flexible than printed books, but they come with their own set of tradeoffs:
The copy protection issue alone is deeply troubling; with eBooks, book publishers now have an unprecedented level of control over when, where, and how you can read their books. In the world of atoms, once the book is shipped out, the publisher cedes all control to the reader. Once you've bought that physical book, you can do with it whatever you will: read it, burn it, photocopy it (for personal use), share it, resell it, loan it, donate it, even throw it at passers-by as a makeshift weapon. But in the world of bits, the publisher has an iron grip over their eBook, which isn't so much sold to you as "licensed" for your use, maybe even only for specific devices like an Amazon Kindle or an Apple iPad. And they can silently remove the book from your device at their whim.
In the brave new world of eBooks, book publishers are waking up drunk with newfound power. And honestly I can't say I blame them. After centuries of publishers having virtually no control at all over the books they publish, they've now been granted near total control.
Consider one of my favorite books, the classic Don't Make Me Think. How much does it cost to buy, as an eBook or otherwise?
| Amazon print new | $22.88 |
| Amazon print used | $13.98 |
| Amazon eBook | $14.16 |
| Publisher eBook | $25.60 |
| Apple eBook | $33.16 |
Except for Amazon, all the eBooks are more expensive than the print version. This … makes no sense. How can the bits in the digital version, which require no printing, no shipping, no physical storage whatsoever, be more expensive than the atoms?
What you actually end up reading when you buy the eBook can vary wildly. Here are pages 80 and 81 of my print copy of Don't Make Me Think. I attempted to take a photograph of the book, then realized it's incredibly difficult to take a decent picture of two pages of a book for a photography noob like myself, so I manually scanned the pages in instead.
If you buy the eBook from the publisher, you get a PDF which appears to be based on the exact same data used to print the book. Pages 80 and 81 are nearly identical to print, with page numbers, footnotes, layout and typography completely intact. (There are some unrelated minor differences on page 81 because the print version is from the second edition.)
But when you buy the eBook from Amazon, you get a proprietary eBook format which contains very little of the original formatting. Pages 80 and 81 are quite different. The footnotes are gone. The title font and font colors are lost. The layout and spacing is completely off, and to my eye the page frankly looks a little broken.
When you buy the book from Apple, you get yet another proprietary eBook format. For comparison, here's page 3 of Don't Make Me Think from the publisher's PDF, which as we've previously established is very nearly the same as print.
I downloaded the sample chapter of Don't Make Me Think from Apple's iBooks, and it appears to be an even worse representation than Amazon's. I have all the same criticisms of Amazon's eBook format here – page 3 has broken layout, no footnotes, missing title fonts and colors, plus now it takes four, yes, four pages to read that very same single print page.
With Don't Make Me Think, I intentionally chose a book that highlights the remaining gap between atoms and bits in books. I've read dozens of other eBooks on Kindle and iPad, and generally the experience is good. For books that are entirely text, with very little layout, the various eBook formats do a great job. This may very well be a majority of books in the world. All eBook formats handle text and basic fonts perfectly fine. But then, so does the Internet. If an eBook can't outperform the Internet at layout, it loses one of the strongest arguments in its favor.
Still, there's no way Amazon's or Apple's current eBook versions of Don't Make Me Think are suitable replacements for the print version. Worse, you won't even know what you'll be missing unless you download a sample and compare it with the print version, as I have. That's disappointing, because part of the joy a book brings to the words inside is by expertly packaging those words into a whole experience. If an eBook can't capture the nuance of the layout at least as well as a hoary old PDF does, again, why bother?
We, as readers, are easily giving up as much as we're getting in the transition from books made of atoms to eBooks made of bits. To make it worthwhile, I believe publishers need to do two things:
Because I love words, I want to love eBooks. I want to buy lots and lots of eBooks. But unless the publishers are willing to treat eBooks with the same respect and care that they give to their printed books – and most importantly of all, adjust their pricing to reflect the brave new economy of bits, and not an antiquated economy of atoms – they're destined to eventually suffer the same fate as the Encyclopedia Britannica.
| [advertisement] How are you showing off your awesome? Create a Stack Overflow Careers profile and show off all of your hard work from Stack Overflow, Github, and virtually every other coding site. Who knows, you might even get recruited for a great new position! |
Hashes are a bit like fingerprints for data.
A given hash uniquely represents a file, or any arbitrary collection of data. At least in theory. This is a 128-bit MD5 hash you're looking at above, so it can represent at most 2128 unique items, or 340 trillion trillion trillion. In reality the usable space is substantially less; you can start seeing significant collisions once you've filled half the square root of the space, but the square root of an impossibly large number is still impossibly large.
Back in 2005, I wondered about the difference between a checksum and a hash. You can think of a checksum as a person's full name: Eubediah Q. Horsefeathers. It's a shortcut to uniqueness that's fast and simple, but easy to forge, because security isn't really the point of naming. You don't walk up to someone and demand their fingerprints to prove they are who they say they are. Names are just convenient disambiguators, a way of quickly determining who you're talking to for social reasons, not absolute proof of identity. There can certainly be multiple people in the world with the same name, and it wouldn't be too much trouble to legally change your name to match someone else's. But changing your fingerprint to match Eubediah's is another matter entirely; that should be impossible except in the movies.
A properly designed secure hash function changes its output radically with tiny single bit changes to the input data, even if those changes are malicious and intended to cheat the hash. Unfortunately, not all hashes were designed properly, and some, like MD5, are outright broken and should probably be reverted to checksums.
As we will explain below, the algorithm of Wang and Yu can be used to create files of arbitrary length that have identical MD5 hashes, and that differ only in 128 bytes somewhere in the middle of the file. Several people have used this technique to create pairs of interesting files with identical MD5 hashes:
- Magnus Daum and Stefan Lucks have created two PostScript files with identical MD5 hash, of which one is a letter of recommendation, and the other is a security clearance.
- Eduardo Diaz has described a scheme by which two programs could be packed into two archives with identical MD5 hash. A special "extractor" program turn one archive into a "good" program and the other into an "evil" one.
- In 2007, Marc Stevens, Arjen K. Lenstra, and Benne de Weger used an improved version of Wang and Yu's attack known as the chosen prefix collision method to produce two executable files with the same MD5 hash, but different behaviors. Unlike the old method, where the two files could only differ in a few carefully chosen bits, the chosen prefix method allows two completely arbitrary files to have the same MD5 hash, by appending a few thousand bytes at the end of each file.
- Didier Stevens used the evilize program (below) to create two different programs with the same Authenticode digital signature. Authenticode is Microsoft's code signing mechanism, and although it uses SHA1 by default, it still supports MD5.
If you could mimic another person's fingerprint or DNA at will, you could do some seriously evil stuff. MD5 is clearly compromised, and SHA-1 is not looking too great these days.
The good news is that hashing algorithms (assuming you didn't roll your own, God forbid) were designed by professional mathematicians and cryptographers who knew what they were doing. Just pick a hash of a newer vintage than MD5 (1991) and SHA-1 (1995), and you'll be fine – at least as far as collisions and uniqueness are concerned. But keep reading.
Speed of a checksum calculation is important, as checksums are generally working on data as it is being transmitted. If the checksum takes too long, it can affect your transfer speeds. If the checksum incurs significant CPU overhead, that means transferring data will also slow down or overload your PC. For example, imagine the sort of checksums that are used on video standards like DisplayPort, which can peak at 17.28 Gbit/sec.
But hashes aren't designed for speed. In fact, quite the opposite: hashes, when used for security, need to be slow. The faster you can calculate the hash, the more viable it is to use brute force to mount attacks. Unfortunately, "slow" in 1990 and 2000 terms may not be enough. The hashing algorithm designers may have anticipated predicted increases in CPU power via Moore's Law, but they almost certainly did not see the radical increases in GPU computing power coming.
How radical? Well, compare the results of CPU powered hashcat with the GPU powered oclHashcat when calculating MD5 hashes:
Radeon 7970 8213.6 M c/s 6-core AMD CPU 52.9 M c/s
The GPU on a single modern video card produces over 150 times the number of hash calculations per second compared to a modern CPU. If Moore's Law anticipates a doubling of computing power every 18 months, that's like peeking 10 years into the future. Pretty amazing stuff, isn't it?
Let's talk about passwords, since hashing and passwords are intimately related. Unless you're storing passwords incorrectly, you always store a user's password as a salted hash, never as plain text. Right? Right? This means if your database containing all those hashes is compromised or leaked, the users are still protected – nobody can figure out what their password actually is based on the hash stored in the database. Yes, there are of course dictionary attacks that can be surprisingly effective, but we can't protect users dead-set on using "monkey1" for their password from themselves. And anyway, the real solution to users choosing crappy passwords is not to make users remember ever more complicated and longer passwords, but to do away with passwords altogether.
This has one unfortunate ramification for password hashes: very few of them were designed with such massive and commonly available GPU horsepower in mind. Here are my results on my current PC, which has two ATI Radeon 7970 cards generating nearly 16000 M c/s with MD5. I used oclHashcat-lite with the full range of a common US keyboard – that is, including uppercase, lowercase, numbers, and all possible symbols:
| all 6 character password MD5s | 47 seconds |
| all 7 character password MD5s | 1 hour, 14 minutes |
| all 8 character password MD5s | ~465 days |
| all 9 character password MD5s | fuggedaboudit |
The process scales nearly perfectly as you add GPUs, so you can cut the time in half by putting four video cards in one machine. It may sound crazy, but enthusiasts have been doing it since 2008. And you could cut it in half again by building another PC with four more video cards, splitting the attack space. (Keep going if you're either crazy, or working for the NSA.) Now we're down to a semi-reasonable 117 days to generate all 8 character MD5s. But perhaps this is a worst-case scenario, as a lot of passwords have no special characters. How about if we try the same thing using just uppercase, lowercase, and numbers?
| all 6 character password MD5s | 3 seconds |
| all 7 character password MD5s | 4 minutes |
| all 8 character password MD5s | 4 hours |
| all 9 character password MD5s | 10 days |
| all 10 character password MD5s | ~625 days |
| all 11 character password MD5s | fuggedaboudit |
If you're curious about the worst case scenario, a 12 character all lowercase password is attainable in about 75 days on this PC. Try it yourself; here's the script I used:
set BIN=oclHashcat-lite64 set OPTS=--gpu-accel 200 --gpu-watchdog 0 --outfile-watch 0 --restore-timer 0 --pw-min 6 --pw-max 6 --custom-charset1 ?l?d?s?u %BIN% %OPTS% --hash-type 0 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa ?1?1?1?1?1?1?1?1?1?1?1?1?1
Just modify the pw-min, pw-max and the custom-charset as appropriate. Or, if you're too lazy to try it yourself, browse through the existing oclHashcat benchmarks others have run. This will also give you some idea how computationally expensive various known hashes are on GPUs relative to each other, such as:
| MD5 | 23070.7 M/s |
| SHA-1 | 7973.8 M/s |
| SHA-256 | 3110.2 M/s |
| SHA-512 | 267.1 M/s |
| NTLM | 44035.3 M/s |
| DES | 185.1 M/s |
| WPA/WPA2 | 348.0 k/s |
Rainbow tables are huge pre-computed lists of hashes, trading off table lookups to massive amounts of disk space (and potentially memory) for raw calculation speed. They are now utterly and completely obsolete. Nobody who knows what they're doing would bother. They'd be wasting their time. I'll let Coda Hale explain:
Rainbow tables, despite their recent popularity as a subject of blog posts, have not aged gracefully. Implementations of password crackers can leverage the massive amount of parallelism available in GPUs, peaking at billions of candidate passwords a second. You can literally test all lowercase, alphabetic passwords which are ≤7 characters in less than 2 seconds. And you can now rent the hardware which makes this possible to the tune of less than $3/hour. For about $300/hour, you could crack around 500,000,000,000 candidate passwords a second.
Given this massive shift in the economics of cryptographic attacks, it simply doesn’t make sense for anyone to waste terabytes of disk space in the hope that their victim didn’t use a salt. It’s a lot easier to just crack the passwords. Even a “good” hashing scheme of
SHA256(salt + password)is still completely vulnerable to these cheap and effective attacks.
Hey, awesome, you're smart enough to not just use a hash, but also to salt the hash. Congratulations.
$saltedpassword = sha1(SALT . $password);
I know what you're thinking. "I can hide the salt, so the attacker won't know it!" You can certainly try. You could put the salt somewhere else, like in a different database, or put it in a configuration file, or in some hypothetically secure hardware that has additional layers of protection. In the event that an attacker obtains your database with the password hashes, but somehow has no access to or knowledge of the salt it's theoretically possible.
This will provide the illusion of security more than any actual security. Since you need both the salt and the choice of hash algorithm to generate the hash, and to check the hash, it's unlikely an attacker would have one but not the other. If you've been compromised to the point that an attacker has your password database, it's reasonable to assume they either have or can get your secret, hidden salt.
The first rule of security is to always assume and plan for the worst. Should you use a salt, ideally a random salt for each user? Sure, it's definitely a good practice, and at the very least it lets you disambiguate two users who have the same password. But these days, salts alone can no longer save you from a person willing to spend a few thousand dollars on video card hardware, and if you think they can, you're in trouble.
If you are a user:
Make sure all your passwords are 12 characters or more, ideally a lot more. I recommend adopting pass phrases, which are not only a lot easier to remember than passwords (if not type) but also ridiculously secure against brute forcing purely due to their length.
If you are a developer:
Use bcrypt or PBKDF2 exclusively to hash anything you need to be secure. These new hashes were specifically designed to be difficult to implement on GPUs. Do not use any other form of hash. Almost every other popular hashing scheme is vulnerable to brute forcing by arrays of commodity GPUs, which only get faster and more parallel and easier to program for every year.
| [advertisement] Hiring developers? Post your open positions with Stack Overflow Careers and reach over 20MM awesome devs already on Stack Overflow. Create your satisfaction-guaranteed job listing today! |
In Preserving Our Digital Pre-History I nominated Jason Scott to be our generation's digital historian in residence. It looks like a few people must have agreed with me, because in March 2011, he officially became an archivist at the Internet Archive.
Jason recently invited me to visit the Internet Archive office in nearby San Francisco. The building alone is amazing; when you imagine the place where they store the entire freaking Internet, this enormous former Christian Science church seems … well, about right.
It's got a built in evangelical aura of mission, with new and old computer equipment strewn like religious totems throughout.
Doesn't it look a bit like the place where we worship servers, with Jason Scott presiding over the invisible, omnipresent online flock? It's all that and so much more. Maybe the religious context is appropriate, because I always thought the Internet Archive's mission – to create a permanent copy of every Internet page ever created, as it existed at the time – was audacious bordering on impossible. You'd need to be a true believer to even consider the possibility.
The Internet Archive is about the only ally we have in the fight against pernicious and pervasive linkrot all over the Internet. When I go back and review old Coding Horror blog entries I wrote in 2007, it's astonishing just how many of the links in those posts are now, after five years, gone. I've lost count of all the times I've used the Wayback Machine to retrieve historical Internet pages I once linked to that are now permanently offline – pages that would have otherwise been lost forever.
The Internet Archive is a service so essential that its founding is bound to be looked back on with the fondness and respect that people now have for the public libraries seeded by Andrew Carnegie a century ago … Digitized information, especially on the Internet, has such rapid turnover these days that total loss is the norm. Civilization is developing severe amnesia as a result; indeed it may have become too amnesiac already to notice the problem properly. The Internet Archive is the beginning of a cure – the beginning of complete, detailed, accessible, searchable memory for society, and not just scholars this time, but everyone.
Without the Internet Archive, the Internet would have no memory. As the world's foremost expert on backups I cannot emphasize enough how significant the Internet Archive is to the world, to any average citizen of the Internet who needs to source an old hyperlink. Yes, maybe it is just the world's largest and most open hard drive, but nobody else is doing this important work that I know of.
While what I wrote above is in no way untrue, it is only a small part of the Internet Archive's mission today. Where I always thought of the Internet Archive as, well, an archive of the bits on the Internet, they have long since broadened the scope of their efforts to include stuff made of filthy, dirty, nasty atoms. Stuff that was never on the Internet in the first place.
The Internet Archive isn't merely archiving the Internet any more, they are attempting to archive everything.
All of this, in addition to boring mundane stuff like taking snapshots of the entire Internet every so often. That's going to take, uh … a lot of hard drives. I snapped a picture of a giant pile of 3 TB drives waiting to be installed in one of the storage rooms.
The Internet Archive is a big organization now, with 30 employees in the main San Francisco office you're seeing above, and 200 staff all over the world. With a mission of such overwhelming scope and scale, they're going to need all the help they can get.
The Internet Archive is a non-profit organization, so you could certainly donate money. If your company does charitable donations and cares at all about the Internet, or free online access to human knowledge, I'd strongly encourage them to donate to the Internet Archive as well. I made sure that Stack Exchange donated every year.
But more than money, what the Internet Archive needs these days is … your stuff. I'll let Jason explain exactly what he's looking for:
I'm trying to acquire as much in the way of obscure video, obscure magazines, unusual pamphlets and printed items of a computer nature or even of things like sci-fi, zines – anything that wouldn't normally find itself inside most libraries. Hence my computer magazines collection – tens of thousands of issues in there. I'd love to get my hands on more.Also as mentioned, I love, love, love shareware CDs. Those are the most bang for the buck with regards to data and history that I want to get my hands on.
Being the obsessiveconscientious geeks that I know you are, I bet you have a collection of geeky stuff exactly like that somewhere in your home. If so, the best way you can help is to send it in as a contribution! Email jscott@archive.org about what you have, and if you're worried about rejection, don't be:
There's seriously nothing we don't want. I don't question. I take it in, I put it in items. I am voracious. Omnivorous. I don't say no.
The Internet Archive has an impossible mission on an immense scale. It is an unprecedented kind of open source archiving, not driven by Google or Microsoft or some other commercial entity with ulterior motives, but a non-profit organization motivated by nothing more than the obvious common good of building a massive digital Library of Alexandria to preserve our history for future generations. Let's do our part to help support the important work of the Internet Archive in whatever way we can.
| [advertisement] Stack Overflow Careers matches the best developers (you!) with the best employers. You can search our job listings or create a profile and even let employers find you. |
In What You Can't See You Can't Get I mentioned in passing how frustrated I was that the state of the art in code editors and IDE has advanced so little since 2003. A number of commenters pointed out the amazing Bret Victor talk Inventing on Principle. I hadn't seen this, but thanks for mentioning it, because I definitely should have. Maybe you haven't seen it either?
It's a bit long at 54 minutes, but worth viewing in its entirety. What Bret shows here is indeed exactly the sort of thing we should be doing, but aren't.
In some ways we've actually regressed from my ancient Visual Basic 6.0 days, when you'd get dynamically notified about errors as you typed, not just when you compiled or ran unit tests. The idea that you should be able to type (or gesture, or speak) and immediately see the result of that change is simple, but extremely powerful. It's speed of iteration in the small. That's essentially the basis for my argument that showing markup and rendered output side-by-side, and dynamically updating them as you type, is vastly superior for learning and experimentation compared to any attempt at WYSIWYG.
But Bret goes further than that – why not show the effects of predicted changes, and change over time? Time is the missing element in a static display of code and rendered output; how do we show that?
Again, watch the video because it's easier to see in action than it is to explain. But maybe you'd like to play with it yourself? That's sort of the point, isn't it? As I wrote in 2007:
I yearn for the day when web pages are regularly illustrated with the kind of beautiful, dynamic visualizations that Ben Fry creates.
That day, I'm happy to report, seems to have arrived. Bret's article, Up and Down the Ladder of Abstraction is extremely interactive in plain old boring HTML 5.
Yes, it's artsy, yes these are mostly toy projects, but this isn't entirely abstract art house visualization nonsense. Designing tools that let you make rapid changes, and see the effects of those changes as soon as possible can be transformative.
Paul realized that what we needed to be solved was not, in fact, human powered flight. That was a red-herring. The problem was the process itself, and along with it the blind pursuit of a goal without a deeper understanding how to tackle deeply difficult challenges. He came up with a new problem that he set out to solve: how can you build a plane that could be rebuilt in hours not months. And he did. He built a plane with Mylar, aluminum tubing, and wire.
The first airplane didn't work. It was too flimsy. But, because the problem he set out to solve was creating a plane he could fix in hours, he was able to quickly iterate. Sometimes he would fly three or four different planes in a single day. The rebuild, retest, relearn cycle went from months and years to hours and days.
Eighteen years had passed since Henry Kremer opened his wallet for his vision. Nobody could turn that vision into an airplane. Paul MacCready got involved and changed the understanding of the problem to be solved. Half a year later later, MacCready's Gossamer Condor flew 2,172 meters to win the prize. A bit over a year after that, the Gossamer Albatross flew across the channel.
Don't get me wrong, we're failing plenty fast with our existing tools. But I can't shake the feeling that we could we fail even faster if we optimized our IDEs and code editors to better visualize the effects of our changes in real time as we make them.
| [advertisement] How are you showing off your awesome? Create a Stack Overflow Careers profile and show off all of your hard work from Stack Overflow, Github, and virtually every other coding site. Who knows, you might even get recruited for a great new position! |
What do you do when you have a lot of things to display to the user, far more than can possibly fit on the screen? Paginate, naturally.
There are plenty of other real world examples in this 2007 article, but I wouldn't bother. If you've seen one pagination scheme, you've seen them all. The state of art in pagination hasn't exactly changed much – or at all, really – in the last 5 years.
I can understand paginating when you have 10, 50, 100, maybe even a few hundred items. But once you have thousands of items to paginate, who the heck is visiting page 964 of 3810? What's the point of paginating so much information when there's a hard practical limit on how many items a human being can view and process in any reasonable amount of time?
Once you have thousands of items, you don't have a pagination problem. You have a search and filtering problem. Why are we presenting hundreds or thousands of items to the user? What does that achieve? In a perfect world, every search would result in a page with a single item: exactly the thing you were looking for.
But perhaps you don't know exactly what you're looking for: maybe you want a variety of viewpoints and resources, or to compare a number of similar items. Fair enough. I have a difficult time imagining any scenario where presenting a hundred or so items wouldn't meet that goal. Even so, the items would naturally be presented in some logical order so the most suitable items are near the top.
Once we've chosen a suitable order and a subset of relevant items … do we really need pagination at all? What if we did some kind of endless pagination scheme, where we loaded more items into the view dynamically as the user reaches the bottom? Like so:
It isn't just oddball disemvowelled companies, either. Twitter's timeline and Google's image search use a similar endless pagination approach. Either the page loads more items automatically when you scroll down to the bottom, or there's an explicit "show more results" button.
Pagination is also friction. Ever been on a forum where you wished like hell the other people responding to the thread had read all four pages of it before typing their response? Well, maybe some of them would have if the next page buttons weren't so impossibly small, or better yet, not there at all because pagination was automatic and seamless. We should be actively removing friction where we want users to do more of something.
I'm not necessarily proposing that all traditional pagination be replaced with endless pagination. But we, as software developers, should avoid mindlessly generating a list of thousands upon thousands of possible items and paginating it as a lazy one-size-fits-all solution. This puts all the burden on the user to make sense of the items. Remember, we invented computers to make the user's life easier, not more difficult.
Once you've done that, there's a balance to be struck, as Google's research tells us:
User testing has taught us that searchers much prefer the view-all, single-page version of content over a component page containing only a portion of the same information with arbitrary page breaks.
Interestingly, the cases when users didn’t prefer the view-all page were correlated with high latency (e.g., when the view-all page took a while to load, say, because it contained many images). This makes sense because we know users are less satisfied with slow results. So while a view-all page is commonly desired, as a webmaster it’s important to balance this preference with the page’s load time and overall user experience.
Traditional pagination is not particularly user friendly, but endless pagination isn't without its own faults and pitfalls, either:
pushState.
For further reading, there's some excellent Q&A on the topic of pagination at ux.stackexchange.
Above all else, you should strive to make pagination irrelevant because the user never has to look at more than a few items to find what they need. That's why I suspect Google hasn't done much with this technique in their core search result pages; if they aren't providing great results on page 1, it doesn't really matter what kind of pagination they use because they're not going to be in business much longer. Take that lesson to heart: you should be worried most of all about presenting a relevant list of items to the user in a sensible order. Once you've got that licked, then and only then should you think about your pagination scheme.
| [advertisement] What's your next career move? Stack Overflow Careers has the best job listings from great companies, whether you're looking for opportunities at a startup or Fortune 500. You can search our job listings or create a profile and let employers find you. |
I suppose What You See Is What You Get has its place, but as an OCD addled programmer, I have a problem with WYSIWYG as a one size fits all solution. Whether it's invisible white space, or invisible formatting tags, it's been my experience that forcing people to work with invisible things they cannot directly control … inevitably backfires. A lot.
I have a distinctly Ghostbusters attitude to this problem.
I need to see these invisible things, so that I can zap them with my proton pack. I mean, er, control them. And more importantly, understand them; perhaps even master them.
I recently had the great privilege of meeting Ted Nelson, who gave me an in-person demo of his ZigZag project and his perpetually in-progress since 1960 Xanadu project, currently known as Xanadu Space. But one thing he mentioned as he gave the demo particularly intrigued me. Being Ted Nelson, of course he went much further than my natural aversion to invisible, hidden markup in content – he insisted that markup and content should never be in the same document. Far more radical.
I want to discuss what I consider one of the worst mistakes of the current software world, embedded markup; which is, regrettably, the heart of such current standards as SGML and HTML. (There are many other embedded markup systems; an interesting one is RTF. But I will concentrate on the SGML-HTML theology because of its claims and fervor.)
There is no one reason this approach is wrong; I believe it is wrong in almost every respect.
I propose a three-layer model:
- A content layer to facilitate editing, content linking, and transclusion management.
- A structure layer, declarable separately. Users should be able to specify entities, connections and co-presence logic, defined independently of appearance or size or contents; as well as overlay correspondence, links, transclusions, and "hoses" for movable content.
- A special-effects-and-primping layer should allow the declaration of ever-so-many fonts, format blocks, fanfares, and whizbangs, and their assignment to what's in the content and structure layers.
It's an interesting, albeit extremely hand-wavy and complex, alternative. I'm unclear how you would keep the structure layer in sync with the content layer if someone is editing the content. I don't even know if there are any real world examples of this three layer approach in action. (And as usual, feel free to correct me in the comments if I've missed anything!)
Instead, what we do have are existing, traditional methods of intermixing content and markup ala HTML or TeX.
When editing, there are two possible interfaces:
What I didn't realize is that there's actually a third editing option: keep the markup visible, and switch rapidly back and forth between the markup and rendered view with a single keystroke. That's what the Gliimpse project reveals:
Please watch the video. The nearly instantaneous and smooth transition that Gliimpse demonstrates between markup and preview has to be seen to be appreciated. The effect is a bit like Expose on the Mac, or Switcher on PC. I'm not sure how I feel about this, mainly because I don't know of any existing IDEs that even attempt to do anything remotely like it.
But I'd sure like to try it. As a software developer, it's incredibly frustrating to me that we have generational improvements in games like Skyrim and Battlefield 3 that render vastly detailed, dynamic worlds at 60 frames per second, yet our source code editors are advancing only in tiny incremental steps, year after year.
What was Microsoft's original mission?
In 1975, Gates and Allen form a partnership called Microsoft. Like most startups, Microsoft begins small, but has a huge vision – a computer on every desktop and in every home.
The existential crisis facing Microsoft is that they achieved their mission years ago, at least as far as the developed world is concerned. When was the last time you saw a desktop or a home without a computer? 2001? 2005? We're long since past the point where Microsoft's original BHAG was met, and even exceeded. PCs are absolutely ubiquitous. When you wake up one day to discover that you've completely conquered the world … what comes next?
Apparently, the Post PC era.
Microsoft never seemed to recover from the shock of achieving their original 1975 goal. Or perhaps they thought that they hadn't quite achieved it, that there would always be some new frontier for PCs to conquer. But Steve Jobs certainly saw the Post PC era looming as far back as 1996:
The desktop computer industry is dead. Innovation has virtually ceased. Microsoft dominates with very little innovation. That's over. Apple lost. The desktop market has entered the dark ages, and it's going to be in the dark ages for the next 10 years, or certainly for the rest of this decade.
If I were running Apple, I would milk the Macintosh for all it's worth – and get busy on the next great thing. The PC wars are over. Done. Microsoft won a long time ago.
What's more, Jobs did something about it. Apple is arguably the biggest (and in terms of financials, now literally the biggest) enemy of general purpose computing with the iPhone and iPad. These days, their own general purpose Mac operating system, OS X, largely plays second fiddle to the iOS juggernaut powering the iPhone and iPad.
The slope of this graph is the whole story. The complicated general purpose computers are at the bottom, and the simpler specialized computers are at the top.
I'm incredibly conflicted, because as much as I love the do-anything computer …
But the primary wake up call, at least for me, is that the new iPad finally delivered an innovation that general purpose computing has been waiting on for thirty years: a truly high resolution display at a reasonable size and price. In 2007 I asked where all the high resolution displays were. Turns out, they're only on phones and tablets.
That's why I didn't just buy the iPad 3 (sorry, The New iPad). I bought two of them. And I reserve the right to buy more!
iPad 3 reviews that complain "all they did was improve the display" are clueless bordering on stupidity. Tablets are pretty much by definition all display; nothing is more fundamental to the tablet experience than the quality of the display. These are the first iPads I've ever owned (and I'd argue, the first worth owning), and the display is as sublime as I always hoped it would be. The resolution and clarity are astounding, a joy to read on, and give me hope that one day we could potentially achieve near print resolution in computing. The new iPad screen is everything I've always wanted on my desktops and laptops for the last 5 years, but I could never get.
Don't take my word for it. Consider what screen reading pioneer, and inventor of ClearType, Bill Hill has to say about it:
The 3rd Generation iPad has a display resolution of 264ppi. And still retains a ten-hour battery life (9 hours with wireless on). Make no mistake. That much resolution is stunning. To see it on a mainstream device like the iPad - rather than a $13,000 exotic monitor - is truly amazing, and something I've been waiting more than a decade to see.
It will set a bar for future resolution that every other manufacturer of devices and PCs will have to jump.
And the display calibration experts at DisplayMate have the measurements and metrics to back these claims up, too:
… the new iPad’s picture quality, color accuracy, and gray scale are not only much better than any other Tablet or Smartphone, it’s also much better than most HDTVs, laptops, and monitors. In fact with some minor calibration tweaks the new iPad would qualify as a studio reference monitor.
Granted, this is happening on tiny 4" and 10" screens first due to sheer economics. It will take time for it to trickle up. I shudder to think what a 24 or 27 inch display using the same technology as the current iPad would cost right now. But until the iPhone and iPad, near as I can tell, nobody else was even trying to improve resolution on computer displays – even though all the existing HCI research tells us that higher resolution displays are a deep fundamental improvement in computing.
At the point where these simple, fixed function Post-PC era computing devices are not just "enough" computer for most folks, but also fundamentally innovating in computing as a whole … well, all I can say is bring on the post-PC era.
| [advertisement] What's your next career move? Stack Overflow Careers has the best job listings from great companies, whether you're looking for opportunities at a startup or Fortune 500. You can search our job listings or create a profile and let employers find you. |
At Stack Exchange, we insist that people who ask questions put some effort into their question, and we're kind of jerks about it. That is, when you set out to ask a question, you should …
We have a great How to Ask page that explains all of this, which is linked generously throughout the network. (And on Stack Overflow, due to massive question volume, we actually force new users to click through that page before asking their first question. You can see this yourself by clicking on Ask Question in incognito or anonymous browser mode.)
What we're trying to prevent, most of all, is the unanswerable drive-by question. Those help nobody, and left unchecked they can ruin a Q&A site, turning it into a virtual ghost town. On Stack Exchange, questions that are so devoid of information and context that they can't reasonably be answered will be actively closed, and if they aren't improved, eventually deleted.
As I said, we're kinda jerks about this rule. But for good reason: we're not-so-subtly trying to help you help yourself, by teaching you Rubber Duck problem solving. And boy does it ever work. I've gotten tons of feedback over the years about how people, in the process of writing up their thorough, detailed question for Stack Overflow or another Stack Exchange site, figured out the answer to their own problem.
It's quite common. See for yourself:
How can I thank the community when I solve my own problems?
I've only posted one question so far, and almost posted another. In both cases, I answered my own questions at least partially while writing it out. I credit the community and the process itself for making me think about the answer. There's nothing explicit in what I'm writing that states quite obviously the answer I needed, but something about writing it down makes me think along extra lines of thought.
Why is it that properly formulating your question often yields you your answer?
I don't know how many times this has happened:
- I have a problem
- I decide to bring it to stack overflow
- I awkwardly write down my question
- I realize that the question doesn't make any sense
- I take 15 minutes to rethink how to ask my question
- I realize that I'm attacking the problem from a wrong direction entirely.
- I start from scratch and find my solution quickly.
Does this happen to you? Sometimes asking the right question seems like half the problem.
Beginning to ask a question actually helps me debug my problem myself
Beginning to ask a question actually helps me debug my problem myself, especially while trying to formulate a coherent and detailed enough question body in order to get decent answers. Has this happened to anybody else before?
It's not a new concept, and every community seems to figure it out on their own given enough time, but "Ask the Duck" is a very powerful problem solving technique.
Bob pointed into a corner of the office. "Over there," he said, "is a duck. I want you to ask that duck your question."
I looked at the duck. It was, in fact, stuffed, and very dead. Even if it had not been dead, it probably would not have been a good source of design information. I looked at Bob. Bob was dead serious. He was also my superior, and I wanted to keep my job.
I awkwardly went to stand next to the duck and bent my head, as if in prayer, to commune with this duck. "What," Bob demanded, "are you doing?"
"I'm asking my question of the duck," I said.
One of Bob's superintendants was in his office. He was grinning like a bastard around his toothpick. "Andy," he said, "I don't want you to pray to the duck. I want you to ask the duck your question."
I licked my lips. "Out loud?" I said.
"Out loud," Bob said firmly.
I cleared my throat. "Duck," I began.
"Its name is Bob Junior," Bob's superintendant supplied. I shot him a dirty look.
"Duck," I continued, "I want to know, when you use a clevis hanger, what keeps the sprinkler pipe from jumping out of the clevis when the head discharges, causing the pipe to..."
In the middle of asking the duck my question, the answer hit me. The clevis hanger is suspended from the structure above by a length of all-thread rod. If the pipe-fitter cuts the all-thread rod such that it butts up against the top of the pipe, it essentially will hold the pipe in the hanger and keep it from bucking.
I turned to look at Bob. Bob was nodding. "You know, don't you," he said.
"You run the all-thread rod to the top of the pipe," I said.
"That's right," said Bob. "Next time you have a question, I want you to come in here and ask the duck, not me. Ask it out loud. If you still don't know the answer, then you can ask me."
"Okay," I said, and got back to work.
I love this particular story because it makes it crystal clear how the critical part of rubber duck problem solving is to totally commit to asking a thorough, detailed question of this imaginary person or inanimate object. Yes, even if you end up throwing the question away because you eventually realize that you made some dumb mistake. The effort of walking an imaginary someone through your problem, step by step and in some detail, is what will often lead you to your answer. But if you aren't willing to put the effort into fully explaining the problem and how you've attacked it, you can't reap the benefits of thinking deeply about your own problem before you ask others to.
If you don't have a coding buddy (but you totally should), you can leverage the Rubber Duck problem solving technique to figure out problems all by yourself, or with the benefit of the greater Internet community. Even if you don't get the answer you wanted, forcing yourself to fully explain your problem – ideally in writing – will frequently lead to new insights and discoveries.
| [advertisement] What's your next career move? Stack Overflow Careers has the best job listings from great companies, whether you're looking for opportunities at a startup or Fortune 500. You can search our job listings or create a profile and let employers find you. |
There's no magic bullet for hiring programmers. But I can share advice on a few techniques that I've seen work, that I've written about here and personally tried out over the years.
I know it sounds crazy, but some people who call themselves programmers can barely program. To this day, I still get regular pings from people who tell me they had candidates fail the most basic programming test imaginable.
That's why extremely simple programming tests are step one of any sane interview process. These tests should happen online, and the goal is not to prove that the candidate is some kind of coding genius, but that they know what the heck programming is. Yes, it's sad and kind of depressing that this is even necessary, but if you don't perform this sanity check, trust me – you'll be sorry.
Some services that do online code screening (I am sure there are more, but these are the ones I know about) are Interview Zen and codility.
Any programmer worth their salt should have a portfolio of the things they've worked on. It doesn't have to be fancy. I'm just looking for a basic breadcrumb trail of your awesomeness that you've left on the Internet to help others. Show me a Stack Overflow profile where I can see what kind of communicator and problem solver you are. Link me to an open-source code repository of your stuff. Got a professional blog? A tumblr? A twitter? Some other word I've never heard of? Excellent, let's have a look. Share applications you've designed, or websites you worked on, and describe what parts were yours.
Just seeing what kind of work people have done, and what sort of online artifacts they've created, is tremendously helpful in getting a sense of what people do and what they're good (or bad) at.
Like GitHub, I find that cultural fit is often a stronger predictor of success than mad programming chops.
We talk about [philosophy] during the hiring process, which we take very seriously. We want any potential GitHubber to know what they’re getting into and ensure it’s a good fit. Part of that is having dinner and talking about stuff like the culture, philosophy, mistakes we’ve made, plans, whatever.
Early on we made a few hires for their skills with little regard to how they’d fit into the culture of the company or if they understood the philosophy. Naturally, those hires didn’t work out. So while we care about the skills of a potential employees, whether or not they “get” us is a major part too.
I realize that not every business has a community around what they do, but if you do have a community you should try like hell to hire from your community whenever possible. These are the folks who were naturally drawn to what you do, that were pulled into the gravitational well of your company completely of their own accord. The odds of these candidates being a good cultural fit are abnormally high. That's what you want!
Did a few of your users build an amazing mod for your game? Did they find an obscure security vulnerability and try to tell you about it? Hire these people immediately!
Once you've worked through the above, it's time to give the candidate a call. Bear in mind that the phone screen is not for chatting, it's for screening. The call should be technical and structured, so both of you can get out immediately if it clearly isn't a fit. Getting the Interview Phone Screen Right covers the basics, but in summary:
What you're looking for is not magical perfect answers, necessarily, but some context into how this person solves problems, and whether they know their stuff (plus or minus 10 percent). The goal is to make sure that the candidates that do make it to the next step are not wasting their time or yours. So don't be shy about sticking to your guns and ending the call early if there are too many warning flags.
So the candidate breezed through the hello world programming tests, has an amazing portfolio, is an excellent cultural fit, and also passed the phone screen with flying colors. Time to get them in for a face-to-face interview, right? Not so fast there cowboy!
I've seen candidates nail all of the above, join the company, and utterly fail to Get Things Done. Have I mentioned that hiring programmers is hard?
If you want to determine beyond the shadow of a doubt if someone's going to be a great hire, give them an audition project. I'm not talking about a generic, abstract programming problem, I'm talking about a real world, honest-to-God unit of work that you need done right now today on your actual product. Something you would give to a current employee, if they weren't all busy, y'know, doing other stuff.
This should be a regular consulting gig with an hourly rate, and a clearly defined project mission statement. Select a small project that can ideally be done in a few days, maybe at most a week or two. Either the candidate can come in to the office, or they can work remotely. I know not every business has these bite-sized units of work that they can slice off for someone outside the company – but trying desperately to make it inside the company – to take on. I'd argue that if you can't think of any way to make an audition mini-project work for a strong hiring candidate, perhaps you're not structuring the work properly for your existing employees, either.
If the audition project is a success, fantastic – you now have a highly qualified candidate that can provably Get Things Done, and you've accomplished something that needed doing. To date, I have never seen a candidate who passes the audition project fail to work out. I weigh performance on the audition project heavily; it's as close as you can get to actually working the job without being hired. And if the audition project doesn't work out, well, consider the cost of this little consulting gig a cheap exit fee compared to an extensive interview process with 4 or 5 other people at your company. Worst case, you can pass off the audition project to the next strong candidate.
(A probationary period of conditional employment can also work, and is conceptually quite similar. You could hire with a 6-8 week review "go or no go" decision everyone agrees to in advance.)
Finally, you should meet candidates face-to-face at some point. It's inevitable, but the point of the earlier steps is that you should be 95% certain that a candidate would be a great hire before they ever set foot in an interview room.
I'm far from an expert on in person interviews, but I don't like interview puzzle questions, to put it mildly.
Instead, I have my own theory about how we should interview programmers: have the candidate give a 15 minute presentation on their area of expertise. I think this is a far better indicator of success than a traditional interview, because you'll quickly ascertain …
The one thing every programmer should know, per Steve Yegge, is how to market yourself, your code, and your project. I wholeheartedly agree. Now pitch me!
Please take this list at face value. I've seen these techniques work, and I've occasionally seen them not work. Adapt this advice to your your particular situation, keep what you think makes sense, and ignore the rest (although I'd strongly advise you to never, ever skip step #1). Even in the best of circumstances, hiring human beings is hard. A job opportunity may not work out for reasons far beyond anyone's control. People are, as they say, complicated.
If you think of work as a relationship, one you'll spend 40 hours a week (or more) in the rest of your life, it behooves everyone involved to "date smart". Both the company and the candidate should make a good faith best effort to determine if there's a match. Your goal shouldn't be merely to get a job, or hire someone for a job, but to have fun and create a love connection. Don't rush into anything unless it feels right on both sides.
(as an aside, if you're looking for ways to attract programmers, you can't go wrong with this excellent advice from Samuel Mullen.)
| [advertisement] What's your next career move? Stack Overflow Careers has the best job listings from great companies, whether you're looking for opportunities at a startup or Fortune 500. You can search our job listings or create a profile and let employers find you. |
The prevalence of free, open WiFi has made it rather easy for a WiFi eavesdropper to steal your identity cookie for the websites you visit while you're connected to that WiFi access point. This is something I talked about in Breaking the Web's Cookie Jar. It's difficult to fix without making major changes to the web's infrastructure.
In the year since I wrote that, a number of major websites have "solved" the WiFi eavesdropping problem by either making encrypted HTTPS web traffic an account option or mandatory for all logged in users.
For example, I just noticed that Twitter, transparently to me and presumably all other Twitter users, switched to an encrypted web connection by default. You can tell because most modern browsers show the address bar in green when the connection is encrypted.
I initially resisted this as overkill, except for obvious targets like email (the skeleton key to all your online logins) and banking.
Yes, you can naively argue that every website should encrypt all their traffic all the time, but to me that's a "boil the sea" solution. I'd rather see a better, more secure identity protocol than ye olde HTTP cookies. I don't actually care if anyone sees the rest of my public activity on Stack Overflow; it's hardly a secret. But gee, I sure do care if they somehow sniff out my cookie and start running around doing stuff as me! Encrypting everything just to protect that one lousy cookie header seems like a whole lot of overkill to me.
Of course, there's no reason to encrypt traffic for anonymous, not-logged-in users, and Twitter doesn't. You get a plain old HTTP connection until you log in, at which point they automatically switch to HTTPS encryption. Makes sense.
It was totally painless for me, as a user, and it makes stealing my Twitter identity, or eavesdropping on my Twitter activity (as fascinating as I know that must sound), dramatically more difficult. I can't really construct a credible argument against doing this, even for something as relatively trivial as my Twitter account, and it has some definite benefits. So perhaps Twitter has the right idea here; maybe encrypted connections should be the default for all web sites. As tinfoil hat as this seemed to me a year ago, now I'm wondering if that might actually be the right thing to do for the long-term health of the overall web, too.
Why not boil the sea, then? Let us encrypt all the things!
Yes, in the hoary old days of the 1999 web, HTTPS was quite computationally expensive. But thanks to 13 years of Moore's Law, that's no longer the case. It's still more work to set up, yes, but consider the real world case of GMail:
In January this year (2010), Gmail switched to using HTTPS for everything by default. Previously it had been introduced as an option, but now all of our users use HTTPS to secure their email between their browsers and Google, all the time. In order to do this we had to deploy no additional machines and no special hardware. On our production frontend machines, SSL/TLS accounts for less than 1% of the CPU load, less than 10KB of memory per connection and less than 2% of network overhead. Many people believe that SSL takes a lot of CPU time and we hope the above numbers (public for the first time) will help to dispel that.
Since all the traffic between you and the websites you log in to would now be encrypted, the ability of nefarious evildoers to either …
… is, if not completely eliminated, drastically limited. Regardless of whether you're on open public WiFi or not.
Personally, I don't care too much if people see what I'm doing online since the whole point of a lot of what I do is to … let people see what I'm doing online. But I certainly don't subscribe to the dangerous idea that "only criminals have things to hide"; everyone deserves the right to personal privacy. And there are lots of repressive governments out there who wouldn't hesitate at the chance to spy on what their citizens do online, or worse. Much, much worse. Why not improve the Internet for all of them at once?
Security always comes at a cost, and encrypting a web connection is no different. HTTPS is going to be inevitably slower than a regular HTTP connection. But how much slower? It used to be that encrypted content wouldn't be cached in some browsers, but that's no longer true. And Google's SPDY protocol, intended as a drop-in replacement for HTTP, even goes so far as to bake encryption in by default, and not just for better performance:
[It is a specific technical goal of SPDY to] make SSL the underlying transport protocol, for better security and compatibility with existing network infrastructure. Although SSL does introduce a latency penalty, we believe that the long-term future of the web depends on a secure network connection. In addition, the use of SSL is necessary to ensure that communication across existing proxies is not broken.
There's also SSL False Start which requires a modern browser, but reduces the painful latency inherent in the expensive, but necessary, handshaking required to get encryption going. SSL encryption of HTTP will never be free, exactly, but it's certainly a lot faster than it used to be, and getting faster every year.
Bolting on encryption for logged-in users is by no means an easy thing to accomplish, particularly on large, established websites. You won't see me out there berating every public website for not offering encrypted connections yesterday because I know how much work it takes, and how much additional complexity it can add to an already busy team. Even though HTTPS is way easier now than it was even a few years ago, there are still plenty of tough gotchas: proxy caching, for example, becomes vastly harder when the proxies can no longer "see" what the encrypted traffic they are proxying is doing. Most sites these days are a broad mashup of content from different sources, and technically all of them need to be on HTTPS for a properly encrypted connection. Relatively underpowered and weakly connected mobile devices will pay a much steeper penalty, too.
Maybe not tomorrow, maybe not next year, but over the medium to long term, adopting encrypted web connections as a standard for logged-in users is the healthiest direction for the future of the web. We need to work toward making HTTPS easier, faster, and most of all, the default for logged in users.
| [advertisement] What's your next career move? Stack Overflow Careers has the best job listings from great companies, whether you're looking for opportunities at a startup or Fortune 500. You can search our job listings or create a profile and let employers find you. |
How many meetings did you have today? This week? This month?
Now ask yourself how many of those meetings were worthwhile, versus the work that you could have accomplished in that same time.
This might lead one to wonder why we even have meetings at all.
At GitHub we don't have meetings. We don't have set work hours or even work days. We don't keep track of vacation or sick days. We don't have managers or an org chart. We don't have a dress code. We don't have expense account audits or an HR department.
Now, I'm sure Tom was being facetious when he said that GitHub doesn't have meetings, because I sure as heck saw meeting rooms when I recently visited their offices to give a talk. Who knows, maybe they use them to store all the extra forks.
Although some meetings are inevitable, even necessary, the principle he's advocating here is an important one. Meetings should be viewed skeptically from the outset, as risks to productivity. We have meetings because we think we need them, but all too often, meetings are where work ends up going to die. I have a handful of principles that I employ to keep my meetings useful:
The first and most important constraint on any meeting is the most precious imaginable resource at any company: time. If you can't fit your meeting in about an hour, there is something deeply wrong with it, and you should fix that first. Either it involves too many people, the scope of the meeting is too broad, or there's a general lack of focus necessary to keep the meeting on track. I challenge anyone to remember anything that happens in a multi-hour meeting. When all else fails, please keep it short!
What's the mission statement of your meeting? Can you define the purpose of your meeting in a single succinct sentence? I hesitate to recommend having an "agenda" and "agenda items" because the word agenda implies a giant, tedious bulleted list of things to cover. Just make sure the purpose of the meeting is clear to everyone; the rest will take care of itself.
Since your meeting has a clearly defined mission statement, everyone attending the meeting knows in advance what they need to talk about and share, and has it ready to go before they walk into the room. Right? That's how we can keep the meeting down to an hour. If you haven't done your homework, you shouldn't be in the meeting. If nobody has done their homework, the meeting should be cancelled.
"Mandatory" meetings are a cop-out. Everyone in the meeting should be there because they want to be there, or they need to be there. One sure way to keep yourself accountable for a meeting is to make everyone optional. Imagine holding a meeting that people actually wanted to attend, because it was … useful. Or interesting. Or entertaining. Now make it happen!
If your meeting never happened, what would the consequences be? If the honest answer to that is almost nothing, then perhaps your meeting has no reason to exist. Any truly productive meeting causes stuff to happen as a direct result of the decisions made in that meeting. You, as a responsible meeting participant, are responsible for keeping track of what you need to do – and everyone in the room can prove it by summarizing their to-do list for everyone's benefit before they leave the meeting.
It's not that we shouldn't have meetings, but rather, we need to recognize the inherent risks of meetings and strive to make the (hopefully) few meetings we do have productive ones. Let's work fast, minimize BS, and get to the point.
| [advertisement] What's your next career move? Stack Overflow Careers has the best job listings from great companies, whether you're looking for opportunities at a startup or Fortune 500. You can search our job listings or create a profile and let employers find you. |
I am no longer a part of Stack Exchange.
I still have much literal and figurative stock in the success of Stack Exchange, of course, but as of March 1st I will no longer be part of the day to day operations of the company, or the Stack Exchange sites, in any way.
It's been almost exactly 4 years since I chose my own adventure. In those four years, we accomplished incredible things together. Stack Overflow is now an enormous bustling city, a hugely positive influence on the daily lives of programmers around the world, a place to learn from and teach your peers. And the entire Stack Exchange network, born out of the seed of Stack Overflow, is a reference model of high signal, low noise, no-nonsense Q&A that makes the internet better for all of us. I could quote traffic figures, but to me that's not what it's all about. I prefer to think of it building something awesome, because I know that if you build it, they will come.
And they did. I'll be damned if we didn't change our little corner of the Internet for the better. Possibly permanently. This is more than I could have ever hoped for, and I am honored to have been a founding and guiding part of it for the last four years. But I don't need to be a part of it forever – nor should I be, if I've been doing my job correctly. Stack Exchange was always about designing software and creating recipes for self-governing communities who love a particular topic. It is an honor to be a "just" a citizen of this community again, because as a citizen, I too have the power to shape its future. Just like you do.
Startup life is hard on families. We just welcomed two new members into our family, and running as fast as you can isn't sustainable for parents of multiple small children. The death of Steve Jobs, and his subsequent posthumous biography, highlighted the risks for a lot of folks:
For a long time, work was my only thing. I worked evenings, weekends, and Christmas. At those rare times when I wasn’t at work in body, I was there in spirit, unable to speak or think of much else. I wanted so badly to climb the mountain that I stopped asking why I was doing it.
I admire Steve for the mountains he climbed. At the same time, I wonder if he missed the whole point, becoming the John Henry of our time. He won the race, but at what cost?
Me? I may turn out to be a failure in business, but I refuse to fail my kids.
I've followed Brad Wardell's success for a long time, and he had a very similar reaction to Jobs' death.
In the last several years, the company has been successful enough to generate a substantial amount of capital. And with it, I have been fortunate to bring in people with great talent. And so I started thinking of all the amazing things we would do. I would put in crazy hours to do it, of course, but we would go and do amazing things.
Then Steve Jobs died.
And suddenly I realized something. What is the objective here? My oldest child just turned 15. My other two are no longer little either. And I have been missing out on them. And my wife.
For all the success and amazing accomplishments of Steve Jobs, in the end, nothing could save him. Death can come at any time. And I realized that if I found myself on death’s door, I would regret deeply not having spent more time with my kids when they were…well, kids.
You may have more discipline than I do. But for me, the mission is everything; I'm downright religious about it. Stack Overflow and Stack Exchange have been wildly successful, but I finally realized that success at the cost of my children is not success. It is failure.
I've met so many amazing people through Stack Exchange. First, the incredibly talented team of people who work for the company, many of whom I personally recruited. As far as I'm concerned, you are among the best in the world at what you do. That's why we hired you, and it has been an honor to serve with you. But more than that, the broader community that formed around a shared vision of making the Internet better through these beautiful public parks of curated, creative commons Q&A. I have continually been humbled by the brilliant minds that saw fit to work alongside us towards this goal, who selflessly contributed their own time and effort because they just plain loved this stuff as much as we do.
I will miss you all terribly.
What's next for me? I honestly don't know. I do know that I love the Internet, and I remain passionate as ever about making the Internet better – but right now I need to be with my family. In six months, perhaps I'll be ready to choose another adventure. I have total confidence that the team at Stack Exchange, and the thriving community that makes it so great, will carry Stack Exchange onward. After all, our shared voyage never ends, it just takes different forms.
Come, my friends.
'Tis not too late to seek a newer world.
Push off, and sitting well in order smite
the sounding furrows; for my purpose holds
To sail beyond the sunset, and the baths
Of all the western stars, until I die.
It may be that the gulfs will wash us down;
It may be that we shall touch the Happy Isles,
And see the great Achilles, whom we knew.
Though much is taken, much abides; and though
We are not now that strength which in old days
Moved earth and heaven, that which we are, we are —
One equal temper of heroic hearts,
Made weak by time and fate, but strong in will
To strive, to seek, to find, and not to yield.
Farewell, Stack Exchange. I hope you can understand that if I was hard on you at times, it was because I wanted you to be the best you could possibly be.
It was because I loved you.
| [advertisement] What's your next career move? Stack Overflow Careers has the best job listings from great companies, whether you're looking for opportunities at a startup or Fortune 500. You can search our job listings or create a profile and let employers find you. |
You know how interviewers love asking about your greatest weakness, or the biggest mistake you've ever made? These questions may sound formulaic, maybe even borderline cliche, but be careful when you answer: they are more important than they seem.
So when people ask me what our biggest mistake was in building Stack Overflow I'm glad I don't have to fudge around with platitudes. I can honestly and openly point to a huge, honking, ridiculously dumb mistake I made from the very first day of development on Stack Overflow – and, worse, a mistake I stubbornly clung to for a solid nine month period after that over the continued protestations of the community. I even went so far as to write a whole blog post decrying its very existence.
For the longest time, I had an awfully Fight Club-esque way of looking at this: the first rule of Stack Overflow was that you didn't discuss Stack Overflow! After all, we were there to learn about programming with our peers, not learn about a stupid website. Right?
I didn't see the need for a meta.
Meta is, of course, the place where you go to discuss the place. Take a moment and think about what that means. Meta is for people who care so deeply about their community that they're willing to go one step further, to come together and spend even more of their time deciding how to maintain and govern it. So, in a nutshell, I was telling the people who loved Stack Overflow the most of all to basically … f**k off and go away.
As I said, not my finest hour.
In my defense, I did eventually figure this out, thanks to the continued prodding of the community. Although we'd used an external meta site since beta, we eventually launched our very own meta.stackoverflow in June 2009, ten months after public beta. And we fixed this very definitively with Stack Exchange. Every Stack Exchange site we launch has a meta from day one. We now know that meta participation is the source of all meaningful leadership and governance in a community, so it is cultivated and monitored closely.
I also paid penance for my sins by becoming the top user of our own meta. I've spent the last 2 years and 7 months totally immersed in the morass of bugs, feature requests, discussions, and support that is our meta. As you can see in my profile, I've visited meta 901 unique days in that time frame, which is disturbingly close to every day. I consider my meta participation stats a badge of honor, but more than that, it's my job to help build this thing alongside you. We explicitly do everything in public on Stack Exchange – it's very intentionally the opposite of Ivory Tower Development.
Along the way I've learned a few lessons about building software with your community, and handling community feedback.
Let's get this out of the way immediately. Sturgeon's Law can't be denied by any man, woman, child … or community, for that matter. Meta community, I love you to death, so let's be honest with each other: most of the feedback and feature requests you give us are just not, uh, er … actionable, for a zillion different reasons.
But take heart: this means 10% of the community feedback you'll get is awesome! I guarantee you'll find ten posts that are pure gold, that have the potential to make the site clearly better for everyone … provided you have the intestinal fortitude to look at a hundred posts to get there. Be prepared to spend a lot of time, and I mean a whole freaking lot of time, mining through community feedback to extract those rare gems. I believe every community has users savvy enough to produce them in some quantity, and they're often startlingly wonderful.
You should immediately triage the feedback and feature requests you get into two broad buckets:
We need power windows in this car!
or
We need a truck bed in this car!
The former is, of course, a reasonable thing to request adding to a car, while the latter is a request to change the fundamental nature of the vehicle. The malleable form of software makes it all too tempting to bolt that truck bed on to our car. Why not? Users keep asking for it, and trucks sure are convenient, right?
Don't fall into this trap. Stay on mission. That car-truck hybrid is awfully tempting to a lot of folks, but then you end up with a Subaru Brat. Unless you really want to build a truck after all, the users asking for truck features need to be gently directed to their nearest truck dealership, because they're in the wrong place.
It always depressed me to see bug trackers and feedback forums with thousands of items languishing there in no man's land with no status at all. That's a sign of a neglected community, and worse, a dishonest relationship with the community. It is sadly all too typical. Don't do this!
I'm not saying you should tell your community that their feedback sucks, even when it frequently does. That'd be mean. But don't be shy about politely declining requests when you feel they don't make sense, or if you can't see any way they could be reasonably implemented. (You should always reserve the right to change your mind in the future, of course.) Sure, it hurts to be rejected – but it hurts far more to be ignored. I believe very, very strongly that if you're honest with your community, they will ultimately respect you more for that.
All relationships are predicated on honesty. If you're not willing to be honest with your community, how can you possibly expect them to respect you … or continue the relationship?
It's tempting to take meta community requests as a wholesale template for development of your software or website. The point of a meta is to listen to your community, and act on that feedback, right? On the contrary, acting too directly on community feedback is incredibly dangerous, and the reason many of these community initiatives fail when taken too literally. I'll let Tom Preston-Werner, the co-founder of GitHub, explain:
Consider a feature request such as “GitHub should let me FTP up a documentation site for my project.” What this customer is really trying to say is “I want a simple way to publish content related to my project,” but they’re used to what’s already out there, and so they pose the request in terms that are familiar to them. We could have implemented some horrible FTP based solution as requested, but we looked deeper into the underlying question and now we allow you to publish content by simply pushing a Git repository to your account. This meets requirements of both functionality and elegance.
Community feedback is great, but it should never be used as a crutch, a substitute for thinking deeply about what you're building and why. Always try to identify what the underlying needs are, and come up with a sensible roadmap.
Half of community relationships isn't doing what the community thinks they want at any given time, but simply being there to listen and respond to the community. When the co-founder of Stack Exchange responds to your meta post – even if it wasn't exactly what you may have wanted to hear – I hope it speaks volumes about how committed we are to really, truly building this thing alongside our community.
Regardless of whether money is changing hands or not, you should love discovering some small gem of a community request or bugfix on meta that makes your site or product better, and swooping in to make it so. That's a virtuous public feedback loop: it says you matter and we care and everything just keeps on getting better all in one delightful gesture.
And isn't that what it's all about?
| [advertisement] What's your next career move? Stack Overflow Careers has the best job listings from great companies, whether you're looking for opportunities at a startup or Fortune 500. You can search our job listings or create a profile and let employers find you. |
I enjoy my iPhone, but I can't quite come to terms with one aspect of its design: Apple's insistence that there can be only ever be one, and only one, button on the front of the device.
I also own a completely buttonless Kindle Fire, and you'll get no argument from me that there should be at least one obvious "Jesus Handle" button on the front of any gadget. I do wonder why Amazon decided to make the Fire buttonless, when every other Kindle they ship has a home button. Amazon has a track record of making some awfully rough version 1.0 devices; I'm sure they'll add a home button in a version or two. And, hey, at only $199 I'm willing to cut them a little slack. For now.
Even Apple is no stranger to buttonless devices. Consider the oddly buttonless third generation iPod Shuffle, where you had to double and even triple click the controls on the headphones to do basic things like advance tracks. Oh, and by the way, this also made every set of headphones you own obsolete, at least for use with this model. The fourth gen shuffle rapidly switched back to physical controls on the device, and the fifth gen went to touch controls on the device, as expected.
Microsoft is just as guilty. I sometimes struggle with the otherwise awesome Xbox 360 Wireless Microphone. It has only a power button and some lights.
In its defense, for the most part it does just work when you pick it up and start singing (badly, in my case), but I admit to being slightly perplexed every time I have to sync it with an Xbox, or figure out what's going on with it. Can you blame me?
When you turn on the microphone, the built-in lights shine to display the microphone status as follows:
- Power on: lights flash green one time every second
- Connecting: lights flash green four times every second
- Connection complete: lights flash blue, and then stops
When your battery power is low, the built-in lights shine to display the battery charge status as follows:
- Low: Lights flash amber one time every three seconds
- Critical: Lights flash amber one time every second
When your microphone moves out of the wireless range of your console, the lights flash green one time every second. The lights can also change color together with supported game titles.
If we can agree that no buttons is clearly a bad idea, I think it follows that one button is problematic in its own way. I have the same issue with the single button on the iPhone that I do with the single button mouse – it may be OK-ish at the very beginning, but over time it leads to absurd, almost comical overloading of functionality. Consider how many different things the single button on the face of an iPhone now controls:
(diagram courtesy Andrew Durdin, source)
The iPhone home button? Why, it's easy! You have your choice of…
All of which have different meanings at different times, of course. In particular I spend a lot of time double-clicking to get to the active apps list, and I often mis-tap which kicks me over to the home screen. I have so many apps installed on my iPhone that search is the only rational way to navigate. This means I search a lot, which requires clicking once to get to the default home page, pausing, then clicking again. Sometimes I click too long, which is then detected as click-and-hold, and I get the voice search app which I am … er, not a fan of, to put it mildly.
I've gotten to the point where I dread using the home button on my iPhone because it Makes Me Think. And I get it wrong a significant percentage of the time. This isn't the way it's supposed to be.
You might be expecting me to turn into a rabid Windows Phone or Android fanboy about now and snarkily note how they get it right. I'm not sure they do. Either of them. They all manage to suck in their own special way.
When there's one button on the device, at least it's clear what that button is supposed to do, right? Well, sometimes.
There is one theme I agree with here – the clearly marked back button on both Android and Windows phones, just like a web browser. I mostly use my iPhone as a platform for the Internet, and the simplicity of the Internet is its primary strength: a collection of obvious things to click, and an easy, giant honking back button so you never get lost in its maze of twisty passages, all alike. It is true that browsers have a home button, but the latest versions of Chrome, Firefox, and Internet Explorer have all but pushed that home button off the UI in favor of the ginormous back button. While I'll tentatively agree that not all phone apps have to behave like the Internet, the Internet is becoming more and more of a platform for bona fide applications every day. The back button is a UI paradigm that works like gangbusters for webapps, and I'd argue strongly in favor of that being a hard button on a device.
But once you add three buttons, thinking starts to creep in again. Am I pressing the correct button? That's never good. And I don't even know what that third button is supposed to be on the Android phone! I could possibly be in favor of the hard search button on the Windows phone, I suppose, but I'd rather see good, consistent use of two buttons on the face of a device before willy-nilly adding Yet Another Button. I think there's a reason the industry has more or less standardized on a two-button mouse, for example. (Yes, there is that pesky middle button, but it's a nice to have, not an essential part of the experience.)
What about the one finger solution? Even with touch devices, one finger does not seem to be enough; there's a curious overloading of the experience over time.
On the iPad, there are a number of system-wide gestures, such as swiping left or right with four fingers to switch between apps. Four-finger swipes? That's convoluted, but imagine a virtual mixing console with horizontal sliders. Quickly move four of them at once...and you switch apps. Application designers have to work around these, making sure that legitimate input methods don't mimic the system-level gestures.
The worst offender is this: swipe down from the top of the screen to reveal the Notification Center (a window containing calendar appointments, the weather, etc.). A single-finger vertical motion is hardly unusual, and many apps expect such input. The games Flight Control and Fruit Ninja are two prime examples. Unintentionally pulling down the Notification Center during normal gameplay is common. A centered vertical swipe is natural in any paint program, too. Do app designers need build around allowing such controls? Apparently, yes.
Yes, our old friend overloading is now on the touch scene in spades: for all but the simplest use of a tablet, you will inevitably find yourself double-tapping, tapping and holding, swiping with two fingers, and so on.
Apple's done a great job of embodying simplicity and clean design, but I often think they go too far, particularly at the beginning. For example, the first Mac didn't even have cursor keys. Everything's a design call, and somewhat subjective, but like Goldilocks, I'm going to maintain that the secret sauce here is not to get the porridge too cold (no buttons) or too hot (3 or more buttons), but just right. I'd certainly be a happier iPhone user if I didn't have to think so much about what's going to happen when I press my home button for the hundredth time in a day.
| [advertisement] What's your next career move? Stack Overflow Careers has the best job listings from great companies, whether you're looking for opportunities at a startup or Fortune 500. You can search our job listings or create a profile and let employers find you. |
SOPA and PIPA are two pieces of proposed legislation designed to "stop" Internet piracy… in the most hamfisted way imaginable. As Mitchell Baker explains:
Assume there's a corner store in your neighborhood that rents movies. But the movie industry believes that some or even all of the videos in that store are unauthorized copies, so that they're not being paid when people watch their movies. What should be done?SOPA/PIPA do not aim at the people trying to get to the store, or even the store itself. The solution under the proposed bills is to make it as difficult as possible to find or interact with the store:
- Maps showing the location of the store must be changed to hide it.
- The road to the store must be blocked off so that it is difficult to physically get to there.
- Directory services must delist the store’s phone number and address.
- Credit card companies would have to cease providing services to the store.
- Local newspapers would no longer be allowed to place ads for the video store.
- To make sure it all happens, any person or organization who doesn’t do this is subject to penalties. Even publishing a newsletter that tells people where the store is would be prohibited by this legislation.
Just substitute "corner store" with "website" and I think you can see where this is going. These bills are so rife with potential for abuse and misuse, so clearly dangerous to the very fabric of the Internet, that frankly I have a hard time getting worked up about them. The Internet is under constant siege by large companies, and will be for the forseeable future. This is nothing new. These bills will be defeated, because they must be.
Instead, I'm scratching my head and wondering how such boneheaded bills made it this far in Congress. I can think of a few reasons:
I often bemoan the state of Slacktivism on the internet, where changing your Facebook or Twitter picture is considered a valid and effective form of protest. But this time, I am happy to say, was indeed different.
Perhaps because of the obvious danger of these bills, geek websites and communities banded together weeks ago to protect themselves and the greater Internet. Like many other technical communities, we wrote about it on our blog, talked about it on our podcast, and even put up a little banner on Stack Overflow for a day. Users were encouraged to call, fax, and write their representatives in Congress and express their concerns. And they did, in droves! But outside of our technical geek ghettos, there was precious little mainstream coverage of this dangerous legislation.
That is, until major sites like Wikipedia, Google, and Craigslist joined the bandwagon today. Most notably, Wikipedia actually went dark for all of today, January 18th, rendering all of English language Wikipedia inaccessible. That turned the tide, and transformed SOPA/PIPA into something that average people would actually talk about and care about. There's no better way to raise awareness of the danger these bills pose than blacklisting one of the greatest resources the Internet has ever produced.
While SOPA/PIPA are still alive -- barely -- for now, I think it's safe to say that they are well on their way to defeat. I'm glad to be a part of that, however tiny, but I cannot in good conscience celebrate.
Yes, we likely succeeded in defeating these two specific bills and galvanizing the political will of major Internet communities, including our very own Stack Exchange. These are good and noble and just and necessary things. They are things to be proud of. But instead of celebrating, let's take this time to reflect and ask ourselves a deeper question: how is it that these dangerous bills came to exist in the first place?
First, and again, this is a critical battle to wage and win. SOPA is just the latest, but in many ways, the most absurd campaign in the endless saga of America’s copyright wars. It will be yet another failed attempt in a failed war, and I obviously believe it should be opposed.But second, and as you describe, this isn’t my war anymore. Not because my heart isn’t in it, but because I don’t believe we will win that war (or better, win the peace and move on) — even if we can win battles like this one — until the more basic corruption that is our government gets addressed. That’s the fight I have spent the last 4 years working on. That’s where I’ll be for at least the next 6.
For this is what I know: We will never (as in not ever) win the war you care about until we win the war against this corruption of our Republic.
Of course, as my book, Republic, Lost: How Money Corrupts Congress -- and a Plan to Stop It, describes, this is an insanely difficult, possibly impossible, fight. But whether difficult or not, it is the fight that must be waged.
We have done much. But in our celebratory enthusiasm, please take a moment to hear out Mr. Lessig, and appreciate just how far we have yet to go.
So yes, join us in fighting the obvious insanity of legislation like SOPA and PIPA that threaten the open, unfettered Internet. But please, please also join us in attacking the far more pernicious problem of lobbyist money subtly corrupting our government. If we don't deal with that, we will never stop fighting bills like SOPA and PIPA.
| [advertisement] What's your next career move? Stack Overflow Careers has the best job listings from great companies, whether you're looking for opportunities at a startup or Fortune 500. You can search our job listings or create a profile and let employers find you. |
In November, I delivered the keynote presentation at Øredev 2011. It was the second and probably final presentation in the series I call Building Social Software for the Anti-Social.
I've spent almost four years thinking about the Q&A format, and these two presentations are the culmination of that line of thought. In them I present ten "scary ideas", ideas which are counterintuitive for most folks. These are the building blocks we used to construct Stack Overflow, and by extension, Server Fault, Super User, and the rest of the Stack Exchange network.
It's not the same experience as attending the actual live presentation, of course, but you can certainly get the gist of it by viewing the slides for these two presentations online:
The Øredev organizers hired ImageThink to draw each presentation on a whiteboard live on stage as it was presented. I was skeptical that this would work, but the whiteboard visualizations came out great for all the presentations. Here's the two whiteboard drawings ImageThink created during my presentation. (Yes, they had two artists on stage "live whiteboarding", one on the left side, and one on the right side.)
It's not a bad approximation of what was covered. If you're curious about live whiteboard visualizations, ImageThink posted a great set of links on their blog that I highly recommend.
After four years, we've mostly figured out what works and what doesn't work for our particular brand of low noise, high signal Q&A at Stack Exchange. But the title Social Software for the Anti-Social is only partially tongue in cheek. If you want to learn anything online, you have to design your software to refocus and redirect people's natural social group impulses, and that's what these presentations attempt to explain. I hope you enjoy them!
Update: Part II is now available as a full talk, with audio and video courtesy of Oredev. Watch it now!
| [advertisement] What's your next career move? Stack Overflow Careers has the best job listings from great companies, whether you're looking for opportunities at a startup or Fortune 500. You can search our job listings or create a profile and let employers find you. |
Between founding Stack Overflow (and later, running Stack Exchange) and having a child, I haven't had much time to blog about the holidays for a few years now. The last Gifts for Geeks I did was in 2008. Those recommendations are still as valid as ever, but I just couldn't muster the enthusiasm to do it every year.
I've also come to realize, especially after having a child, that the goal in life is not to own a lot of "stuff", but rather, to free yourself from everything except that which is essential, and that which you love.
I'm still working on this, and I probably will be until I die. That said, there are a few essential things I think any self respecting geek should have, things I use all the time and I truly love – and I feel it's my responsibility to let my fellow geeks, and the spouses and significant others of geeks, know about them. Otherwise you might end up with yet another WiFi Detecting Shirt as a gift this year, and that'd just be … sad, for everyone involved. So consider this a public service, and feel free to share this post, lest you show up to work in January and find yourself and all your coworkers wearing Wifi Detecting Shirts.
As I wrote in What's On Your Utility Belt? I've been carrying LED flashlights since 2005, and just in that time the average LED flashlight has gone from bright, to very bright, to amazingly bright, to ridiculously blinding laser-like bright. You can thank Haitz's Law for that:
[Haitz's Law] states that every decade, the cost per lumen (unit of useful light emitted) falls by a factor of 10, the amount of light generated per LED package increases by a factor of 20, for a given wavelength (color) of light. It is considered the LED counterpart to Moore's law, which states that the number of transistors in a given integrated circuit doubles every 18 to 24 months. Both laws rely on the process optimization of the production of semiconductor devices.
Or, as I like to call it, "why you will be regularly blinded by flashlights for the rest of your natural life." But on the plus side, it also means that today even inexpensive LED flashlights are plenty bright for all but the most niche applications. You no longer have to pay a big premium to get one that's usefully bright. LED lights are so awesome, in fact, that I own and recommend no less than three form factors:
If you do any kind of DIY work at all, at some point you're going to want a focused light exactly where you are looking. If you can get over the "hey, I have this lamp strapped to my head and I look like a dork" factor, headlamps are ridiculously convenient. I had a much less bright (~40 lumens) headlamp and switching to this 90 lumen HL21 was a major improvement. I use this thing all the time. Looking cool is overrated.
The E21 is much smaller than your typical full-size flashlight but it is every bit as bright as those giant police-baton like Maglites. It runs off two ubiquitous AA batteries, and has a pleasingly simple design, with an obvious switch in the rear and only two configurable light levels: low (48 lumens) and high (150 lumens). This is a flashlight you could buy your parents without baffling them. We own three, and each of our cars has one in the glove box. This is, in my opinion, what LED lights were meant to be.
The latest revision of the LD01 is the proverbial Every Day Carry; a compact single AAA flashlight. As long as you have your keys with you, you'll never without a reliable, bright enough light. Twist the cap to balance between runtime and light output; the three modes are 85 lumens for 1 hour, 28 lumens for 3.5 hours, and 9 lumens for 11 hours. Pretty incredible from a single AAA battery! Oh, and I recommend a lithium AAA battery because they run longer and are 1/3 lighter than other types of batteries. Normally I wouldn't care, but the reduced weight is surprisingly noticeable in something you'll have in your pocket all the time.
All these LED lights have one thing in common: batteries. It's unavoidable. Because you're a responsible geek, of course you use modern rechargeable battery technology. And as I wrote in Adventures in Rechargeable Batteries, sophisticated battery chargers are like geek catnip.
This is the LaCrosse BC1000 ($60), and it's a ton of fun to mess around with. Also, it recharges batteries. It might seem a little spendy, but it can do miraculous things like bring old nearly-dead rechargeable batteries back to life. And it comes with a bunch of actually useful accessories in the box:
Yep, you can simulate C and D cells by putting the AA and AAA batteries inside the shells. The only battery type not represented here is the 9 volt. I own two of these LaCrosse chargers, and given the stupid number of AA and AAA powered devices in the house I'm thinking of buying a third. If you're a geek, you almost certainly have 99 battery problems, but armed with this baby, recharging ain't one. And don't forget the low self-discharge NiMH batteries, while you're at it.
Ah, the dremel. I think this Canadian forumgoer expressed it best:
It truly is hard for me to express the joy I feel when I am forced to break out the dremel; the last resort, the "Trojan Horse" of tools. In a dark place when all other tools abandon me and leave me heartbroken, the dremel always provides a loving shoulder to help complete my tasks. The dremel is a very selfless tool, he/she has no purpose to which they cling, yet is always willing to assist its fellow tools in completing theirs...Drill strip a screw? The dremel can help... The jigsaw leave some nasty edges? dremel can restore them. I like to think of the dremel as the Jesus of tools.
They say Jesus performed many miracles and although it's not thoroughly documented, I believe his first miracle was, in fact, the dremel blueprint (he was a carpenter after all). The good Lord presented me with an image in a dream... I would like to share it.
If you don't own a dremel, I'm sorry, but I'm going to have to ask you to turn in your geek card. The dremel is truly the swiss army knife of DIY projects. Any DIY project.
I use my Dremel about once every few months, mostly for things that I probably shouldn't even be attempting. But that's the beauty of the Dremel. It doesn't judge; it just helps you get s**t done, by any means necessary. I don't recommend buying a big Dremel kit to start, because it's hard to tell which accessories you'll actually want or need until you begin using this insanely versatile tool. I suggest starting with the entry-level high power Dremel kit ($90).
Finally, I have to put in a mention for an updated version of what is probably the most frequently used thing on my keychain, with the biggest bang for the gram other than my front door key -- the Leatherman Squirt PS4 ($24).
That's right, you no longer have to face the terrible existential conundrum of choosing between pliers or scissors. The new PS4 model now includes both pliers and scissors. This is nothing less than a Christmas miracle, people! (Oh yeah, and get this awesome tiny carabiner to attach it to your keychain so you can easily detach it when you need to bust it out.)
So that's it this year. Nothing extravagant. Nothing too expensive. No frills. Just essential stuff I love and use regularly. I hope you, or someone you love, will love them too.
| [advertisement] What's your next career move? Stack Overflow Careers has the best job listings from great companies, whether you're looking for opportunities at a startup or Fortune 500. You can search our job listings or create a profile and let employers find you. |
Anti-aliasing has an intimidating name, but what it does for our computer displays is rather fundamental. Think of it this way -- a line has infinite resolution, but our digital displays do not. So when we "snap" a line to the pixel grid on our display, we can compensate by imagineering partial pixels along the line, pretending we have a much higher resolution display than we actually do. Like so:
As you can see on these little squiggly black lines I drew, anti-aliasing produces a superior image by using grey pixels to simulate partial pixels along the edges of the line. It is a hack, but as hacks go, it's pretty darn effective. Of course, the proper solution to this problem is to have extremely high resolution displays in the first place. But other than tiny handheld devices, I wouldn't hold your breath for that to happen any time soon.
This also applies to much more complex 3D graphics scenes. Perhaps even more so, since adding motion amplifies the aliasing effects of all those crawling lines that make up the edges of the scene.
But anti-aliasing, particularly at 30 or 60 frames per second in a complex state of the art game, with millions of polygons and effects active, is not cheap. Per my answer here, you can generally expect a performance cost of at least 25% for proper 4X anti-aliasing. And that is for the most optimized version of anti-aliasing we've been able to come up with:
Super-Sampled Anti-Aliasing (SSAA). The oldest trick in the book - I list it as universal because you can use it pretty much anywhere: forward or deferred rendering, it also anti-aliases alpha cutouts, and it gives you better texture sampling at high anisotropy too. Basically, you render the image at a higher resolution and down-sample with a filter when done. Sharp edges become anti-aliased as they are down-sized. Of course, there's a reason why people don't use SSAA: it costs a fortune. Whatever your fill rate bill, it's 4x for even minimal SSAA.
Multi-Sampled Anti-Aliasing (MSAA). This is what you typically have in hardware on a modern graphics card. The graphics card renders to a surface that is larger than the final image, but in shading each "cluster" of samples (that will end up in a single pixel on the final screen) the pixel shader is run only once. We save a ton of fill rate, but we still burn memory bandwidth. This technique does not anti-alias any effects coming out of the shader, because the shader runs at 1x, so alpha cutouts are jagged. This is the most common way to run a forward-rendering game. MSAA does not work for a deferred renderer because lighting decisions are made after the MSAA is "resolved" (down-sized) to its final image size.
Coverage Sample Anti-Aliasing (CSAA). A further optimization on MSAA from NVidia [ed: ATI has an equivalent]. Besides running the shader at 1x and the framebuffer at 4x, the GPU's rasterizer is run at 16x. So while the depth buffer produces better anti-aliasing, the intermediate shades of blending produced are even better.
Pretty much all "modern" anti-aliasing is some variant of the MSAA hack, and even that costs a quarter of your framerate. That's prohibitively expensive, unless you have so much performance you don't even care, which will rarely be true for any recent game. While the crawling lines of aliasing do bother me, I don't feel anti-aliasing alone is worth giving up a quarter of my framerate and/or turning down other details to pay for it.
But that was before I learned that there are some emerging alternatives to MSAA. And then, much to my surprise, these alternatives started showing up as actual graphics options in this season's PC games -- Battlefield 3, Skyrim, Batman: Arkham City, and so on. What is this FXAA thing, and how does it work? Let's see it in action:
| No AA | 4x MSAA | FXAA |
|
|
|
|
(this is a zoomed fragment; click through to see the full screen)
FXAA stands for Fast Approximate Anti-Aliasing, and it's an even more clever hack than MSAA, because it ignores polygons and line edges, and simply analyzes the pixels on the screen. It is a pixel shader program documented in this PDF that runs every frame in a scant millisecond or two. Where it sees pixels that create an artificial edge, it smooths them. It is, in the words of the author, "the simplest and easiest thing to integrate and use".
FXAA has two major advantages:
The only downside, and it is minor, is that you may see a bit of unwanted edge "reduction" inside textures or in other places. I'm not sure if it's fair to call this a downside, but FXAA can't directly be applied to older games; games have to be specifically coded to call the FXAA pixel shader before they draw the game's user interface, otherwise it will happily smooth the edges of on-screen HUD elements, too.
The FXAA method is so good, in fact, it makes all other forms of full-screen anti-aliasing pretty much obsolete overnight. If you have an FXAA option in your game, you should enable it immediately and ignore any other AA options.
FXAA is an excellent example of the power of simple hacks and heuristics. But it's also a great demonstration of how attacking programming problems from a different angle -- that is, rather than thinking of the screen as a collection of polygons and lines, think of it as a collection of pixels -- can enable you to solve computationally difficult problems faster and arguably better than anyone thought possible.
| [advertisement] What's your next career move? Stack Overflow Careers has the best job listings from great companies, whether you're looking for opportunities at a startup or Fortune 500. You can search our job listings or create a profile and let employers find you. |
I've talked about computer workstation ergonomics before, but one topic I didn't address is lighting. We computer geeks like it dark. Really dark. Ideally, we'd be in a cave. A cave … with an internet connection.
The one thing that we can't abide is direct overhead lighting. Every time the overhead light gets turned on in this room, I feel like a Gremlin shrieking Bright light! Bright light! Oh, how it burns!
But there is a rational basis for preferring a darkened room. The light setup in a lot of common computing environments causes glare on the screen:
If your room's lit, as most are, by fittings hanging from the ceiling, you'll be wanting to set up your monitor so that you don't see reflections of the lights in it. The flat screens on many modern monitors (like the excellent Samsung I review here) help, because they reflect less of the room behind you. And anti-reflective screen coatings are getting better and better too. But lots of office workers still just can't avoid seeing one or more ceiling fluoros reflected in their screen.A good anti-reflective coating can reduce most such reflections to annoyance level only. But if you can see lights reflected in your screen, you can probably also directly see lights over the top of your monitor. Direct line of sight, or minimally darkened reflected line of sight, to light sources is going to give you glare problems.
Glare happens when there are small things in your field of vision that are much brighter than the general scene. Such small light sources can't be handled well by your irises; your eyes' pupil size is matched to the overall scene illumination, and so small light sources will appear really bright and draw lines on your retinas. The more of them there are, and the brighter they are, the more work your eyes end up doing and the sooner they'll get tired.
While a darkened room is better for viewing most types of computer displays, it has risks of its own. It turns out that sitting in a dark room staring at a super bright white rectangle is … kind of bad for your eyes, too. It doesn't help that most LCDs come from the factory with retina-scorching default brightness levels. To give you an idea of how crazy the defaults truly are, the three monitors I'm using right now have brightness set to 25/100. Ideally, your monitors shouldn't be any brighter than a well-lit book. Be sure to crank that brightness level down to something reasonable.
You don't want total darkness, what you want is some indirect lighting – specifically bias lighting. It helps your eyes compensate and adapt to bright displays.
"[Bias lighting] works because it provides enough ambient light in the viewing area that your pupils don't have to dilate as far. This makes for less eyestrain when a flashbang gets thrown your way or a bolt of lightning streams across the screen," he told Ars. "Because the display is no longer the only object emitting light in the room, colors and black levels appear richer than they would in a totally black environment. Bias lighting is key in maintaining a reference quality picture and reducing eye-strain."
Bias lighting is the happy intersection of indirect lighting and light compensation. It reduces eye strain and produces a better, more comfortable overall computing display experience.
The good news is that it's trivially easy to set up a bias lighting configuration these days due to the proliferation of inexpensive and bright LEDs. You can build yourself a bias light with a clamp and a fluorescent bulb, or with some nifty IKEA LED strips and double-sided foam tape. It really is that simple: just strap some lights to the back of your monitors.
I'm partial to the IKEA Dioder and Ledberg technique myself; I currently have an array of Ledbergs behind my monitors. But if you don't fancy any minor DIY work, you can try the Antec Halo 6 LED Bias Lighting Kit. It also has the benefit of being completely USB powered.
Of course, lighting conditions are a personal preference, and I'd never pitch bias lighting as a magic bullet. But there is science behind it, it's cheap and easy to try, and I wish more people who regularly work in front of a computer knew about bias lighting. If nothing else, I hope this post gets people to turn their LCD monitors down from factory brightness level infinity to something a tad more gentle on the old Mark I Eyeball.
| [advertisement] What's your next career move? Stack Overflow Careers has the best job listings from great companies, whether you're looking for opportunities at a startup or Fortune 500. You can search our job listings or create a profile and let employers find you. |
Subscribe in a reader
Subscribe via email
|
|
Traffic Stats |