Here are two amazing pieces that expose a great amount of detail about very different types of jobs that are specific to the Internet era. We learn about who is doing the work, what the work is like and what the culture is. There’s so much rich detail in both that I am not summarizing or drawing conclusions but simply pointing you to them for listening/reading.

(Jerry Bowley/flickr)

Brown Box is a a RadioLab piece about the order fulfillment centers that companies like Amazon and others use. The reporter gets a job in one of these places and describes the physical and emotional toil (although she meets some who really like the work). While you might imagine the way items are stored in those warehouses is incredibly ordered, she describes how it’s essentially random, while “pickers” who are preparing an order carry a handheld device that directs them item after item to each holding bin at random locations through the warehouse, counting down the seconds it has calculated for them to reach the next item. That sounds so stressful!

It used to be, when you ordered something on the Internet, you waited a week for it to show up. That was the deal: you didn’t have to get off the couch, but you had to wait. But in the last few years, that’s changed. Now, increasingly, the stuff we buy on the Internet shows up the next day or the same day, sometimes within hours. Free shipping included. Which got us wondering: How is this Internet voodoo possible?

A fleet of robots? Vacuum tubes? Teleportation? Hardly. In this short, reporter Mac McClelland travels into the belly of the beast that is the Internet retail system, and what she finds takes her breath away and makes her weak in the knees (in the worst way).

Also: a written story by Mac McClelland about the same experience.

Programming Sucks is an intensely hyperbolic piece that digs into the state of the art for developing computer code.

For example, say you’re an average web developer. You’re familiar with a dozen programming languages, tons of helpful libraries, standards, protocols, what have you. You still have to learn more at the rate of about one a week, and remember to check the hundreds of things you know to see if they’ve been updated or broken and make sure they all still work together and that nobody fixed the bug in one of them that you exploited to do something you thought was really clever one weekend when you were drunk. You’re all up to date, so that’s cool, then everything breaks.

“Double you tee eff?” you say, and start hunting for the problem. You discover that one day, some idiot decided that since another idiot decided that 1/0 should equal infinity, they could just use that as a shorthand for “Infinity” when simplifying their code. Then a non-idiot rightly decided that this was idiotic, which is what the original idiot should have decided, but since he didn’t, the non-idiot decided to be a dick and make this a failing error in his new compiler. Then he decided he wasn’t going to tell anyone that this was an error, because he’s a dick, and now all your snowflakes are urine and you can’t even find the cat.
…
So no, I’m not required to be able to lift objects weighing up to fifty pounds. I traded that for the opportunity to trim Satan’s pubic hair while he dines out of my open skull so a few bits of the internet will continue to work for a few more days.

• How commercial software products are developed (or "get some empathy for clients, right here") – I worked on the "Windows Mobile PC User Experience" team. This team was part of Longhorn from a feature standpoint but was organizationally part of the Tablet PC group. To find a common manager to other people I needed to work with required walking 6 or 7 steps up the org chart from me. My team's raison d'etre was: improve the experience for users on laptops, notebooks and ultra-mobile PCs. Noble enough. Of course the Windows Shell team, whose code I needed to muck about in to accomplish my tiny piece of this, had a charter of their own which may or may not have intersected ours.

  My team had a very talented UI designer and my particular feature had a good, headstrong program manager with strong ideas about user experience. We had a Mac [owned personally by a team member] that we looked to as a paragon of clean UI. Of course the Shell team also had some great UI designers and numerous good, headstrong PMs who valued (I can only assume) simplicity and so on.

• Not quite-credible story about Best Buy differentiating on making technology usable/understandable – Mr. Dunn said he wanted to create an atmosphere where consumers were attracted not just to products but also to services that help them master fast-changing technology and configure and connect devices.

  One of Best Buy’s main competitive strategies has been services, something it has done better in the past than any national electronics retailer. That translates into selling product warranties, or help with installing a home theater or configuring a computer.
  Mr. Dunn said a chief example of the kind of thing Best Buy wants to be known for is a service it calls Walk Out Working that it began introducing in May 2007. The service, which is free, helps consumers configure new mobile phones so that when they leave the store they are able to use features like music playback and Web surfing.

  …He argues that [other retailers] cannot compete with Best Buy when it comes to offering individual service, explaining technology to customers and charging to help them adapt to it.

• Jobless Benefits Web Site Adds Insult to Injury – Jobless people seeking information about their benefits on the Brazilian Labor Ministry's Web were forced to type in passwords such as "bum" and "shameless." A private company that created the site's security system is blamed; its contract with the ministry wasn't being renewed, which may have prompted the pranks.

Alan Cooper spoke earlier this week at a meeting of the San Francisco Interaction Design Association chapter. Cooper talked about programming as a craft, and Interaction Designers as potential facilitators of that craft within the business world.

Cooper is advocating what he calls an “insurgency of quality,” which he describes as being about how software design and production processes can and should be evolving-specifically, increasing the time spent refining products before they’re released as “finished.”

It’s an old carpenters’ adage to “measure twice, cut once.” The current software production model Cooper is speaking out against might be described as: measure once, cut once, ship once, repeat all steps for version 2.

Based on the insurgency Cooper is advocating, in which Interaction Designers and Programmers would take more time to get it right before a product goes to market, the development model would become: measure twice, cut twice (e.g. validate and iterate), ship once. The idea being that what gets shipped would be of higher quality then what generally gets produced in the current way, which prioritizes time-to-market.

We work with a lot of clients who are operating within very tight timelines. I’d be curious to know what kinds of successes and failures Cooper and his firm’s consultants have been having with their clients in trying to implement this new development model on actual projects. Are the Cooper folks finding that client organizations are ready, willing and able to add more development time to the front end? If not, what kinds of strategies are working and not working in trying to encourage that kind of change?

A lot of theoretical revolutions break down or dissolve when they meet real world complexities and constraints. It would be great to have some stories detailing how the ideas Cooper is advocating are getting played out in real project engagements.