Technology

DavidCo's Robert Peake on "Getting Software Done" (part 2)

Merlin — Wed, 18 Oct 2006 12:20:24 +0000

This is the second of a two-part article by Robert Peake, CTO of the David Allen Company. Be sure to start with yesterday's first part, "Why GTD Matters To Programmers."

Part II: GTD and Extreme Programming

by Robert Peake, David Allen Company

I have to admit that I'm not a perfect adopter of Extreme Programming. We don't program in pairs, for example -- quite the opposite, our coders are flung far and wide, tethered together only by a broadband connection. However, as much as GTD is "advanced common sense", so to my mind is Extreme Programming a form of "best practices on steroids" -- and for this reason, there are not only many parallels, but great crossover when it comes to managing programming projects.

Software didn't used to have to be very adaptable. Mainframe software systems were only slightly less mutable than the hardware they ran on, and dependability -- not responsiveness, new features, or interoperation with some other cool, new application -- was key. Along came the internet, and the ability to patch and change software online. All that changed.

Likewise, while even forty years ago dependability seemed to exist both in terms of job definition and job security, adapting to change may well be the single most important trait of the knowledge worker today. And increasingly, the ability to manage large volumes of information, focusing on what's important and ignoring the dross, has become key. For this reason, a few critical concepts in programming apply to getting software done with maximum efficiency and also suggest some important directions for any kind of project -- they are: regression testing, refactoring, and documentation.

Regression testing is, quite simply, spelling out a list of tests to perform so that you can verify that what you have created works as expected. The "regression" part of it is that you often want to run the same rudimentary tests you ran in the beginning of the project much later in the evolution of the product. This is to make sure you didn't break something. Regression testing goes hand in hand with documentation, which stems from the same inspiration: describing how the thing should work. Once you have described how the thing should work, and made tests you can perform later to prove it, you need to make sure that documentation exists within the source code. In our case, we use automatic tools to pull out the documentation we mix in with our source code, and have created for ourselves an automatically updated manual of how various functions and parts of our system work. We even set up shortcuts so that with a couple keystrokes, we can access documentation for not only the core language, but our own collection of application-specific functions, right from within the source code we are working on at the moment. The result? Six months after writing something critical, I don't have to go crawling back through file after file of source code to figure out how to use that particular building block or tool.

All of this relates to GTD when you bring in the concept of outcome-based thinking. Every time you pick up an artifact of your own thinking (be it a scribble on a note-taker wallet page or a mind map on butcher paper) and then decide that what you've really notated for yourself is a project, the very next question is: what is the desired outcome? In other words, how will I know I've finished this project? What will be the result? Likewise, all the activities in Extreme Programming such as gathering user stories, writing regression tests for each unit and component of the software, and documenting the intended behavior inside the code itself so someone else can later understand what you were trying to do -- embody outcome-oriented thinking for software. Jumping to the end first works consistently and well to line up your thinking in the right direction. Getting that thinking captured appropriately into your trusted system -- and not over-thinking into all the possible ramifications and rabbit trails that will likely only get blown away when new real-world input arrives -- is key to staying agile, flexible, and dynamic.

Another key to programming in an agile way is refactoring. This is going back to what you've written -- not to add features or fix bugs per se, but to clean up your thinking and make it line up with your new understanding of the project. The truth is that thinking takes time, and it evolves over time. So, revisiting the code on a regular basis, purely for the sake of shoring things up and reworking things into a more effective paradigm, may seem like a lateral shift on the surface -- but makes a huge difference in the overall maintainability of the code. Likewise, the maintainability of your life and your trusted system that runs it can also be equated to how often you perform a weekly review. The weekly review is refactoring for life -- a time to take stock, reevaluate your understanding of and progress on projects, make sure all actions are tied to projects and projects to actions, and to scrub out all the stuff that's been either completed or rendered irrelevant by time (sort of like getting rid of the variables you thought you'd need in your code but didn't -- preventing memory leaks and tightening things up for later). Refactoring is as important in life as it is in software.

We used these three branches of Extreme Programming to great success in building GTD Connect. One other critical technique or skill involved was being able to flip from a very high-level creative brainstorming session with our senior people into sussing out the specific outcomes that would demonstrate we've done our job on the technology side. None of this precluded writing up documents spelling out our understanding of what's important and what's nice to have, the timing involved, as well as some of the mechanics of what we are doing and the business side of how much it would cost. But ultimately, being able to differentiate between and translate from the right-brain mind mapping sessions into left-brain outcomes led to just enough of a specification to get our coders excited. Trusting this process gives you the freedom to be wildly creative in the brainstorming session (because you're not nailing anything down yet). It also empowers programmers with the flexibility to find a smart, dependable, architecturally sound approach to solving the problem on the other end -- because when you feed programmers outcomes rather than dictating precise specifications in pseudo-code, you give them the freedom to work within the context of the whole system to come up with the best solution. And you leave room for constructive, creative surprises -- the unexpected killer features that can only thrive in a healthy, outcome-oriented relationship.

One of the tenets of Extreme Programming Merlin mentioned in our panel is the idea that, "You ain't gonna need it." While I never overtly said this to The David in our sessions, the spirit of this approach is something that has pervaded the process of leaning into the great (and so far highly successful) experiment of launching Connect. That spirit of the idea is to build to a need, rather than a nice idea. In balance with this, we also tried to cast our net wide enough in terms of variety of features so that we can test and see what people gravitate toward, and what might fall away. This natural process of meeting customer feature demand on its own terms is highly analogous to the GTD approach of getting through each work day on its own terms, using action lists tied to projects rather than other forms of "best laid plans."

A big key to the mechanics of getting a project as big as Connect done (and then maintaining and improving it incrementally) has been a shared project list accessible by all our developers. First of all, we trust our people. I have never seen the approach of trying to enforce people's job constraints through software permissions really work when it comes to project management. Instead, anyone can add, edit or mark a project complete in our system. This means that our development people can keep their complete project inventory in a shared format and can edit projects assigned by others to keep notes and add important details. We use a Lotus Notes database for this, but this approach could also be easily implemented via one of many web-based applications or even a shared whiteboard if everyone works in the same room.

Another key with all of this, and a somewhat revolutionary approach, is that we don't track bugs and feature requests in separate places. It all has to get done anyway. And because maintaining a comprehensive inventory of everything that needs to get done in one place, accessible by all the relevant people, we can very quickly re-calibrate to focus on what's critical. Sometimes that's a bug. Sometimes it's a great new feature. Either way, we use the system to support us like a giant radar screen, and good communication in person, by phone, email, and IM to determine what's critical and go after it. So far, it's worked great to keep us engaged with our members and our own staff and be responsive to their input.

Connect has been a lot of fun to build, and it's great to watch it start to really thrive. Hopefully this little peek under the hood has got your own gears turning about software development with GTD and perhaps even other areas of your work or life where these analogies hold. If you're feeling particularly geeky, more platform-specific details on the best practices we drew from when pulling Connect together are here.

And if any of this has rung your bell and you want to chat, please drop me a line at robert at davidco dot com, or catch me on the forums. Until next time, happy coding, happy GTD'ing, and be well.

Robert Peake used to teach programming languages to computer science students at Berkeley before earning his degree in poetry. These days he is the CTO of The David Allen Company, where he reads, writes, and thinks about many things in many languages.

Update 2006-10-18 10:05:52 - For your convenience, here's an easy-to-print HTML version of both of Robert's posts.

”DavidCo's Robert Peake on "Getting Software Done" (part 2)” was written by Merlin Mann for 43Folders.com and was originally posted on October 18, 2006. Except as noted, it's ©2010 Merlin Mann and licensed for reuse under CC BY-NC-ND 3.0. "Why a footer?"

Guest Post: DavidCo's Robert Peake on "Getting Software Done" (part 1)

Merlin — Tue, 17 Oct 2006 12:15:01 +0000

Robert Peake is the brainiac CTO for the David Allen Company (a/k/a, "DavidCo"). I first met Robert when I was down in Ojai a few weeks ago to record some stuff with The David, including our Productive Talk podcasts and that TechGTD panel we did with Robert and Eric Mack.

Robert really impressed me with his humor, his insight, and his mad Macintosh skillz. Also -- off the record -- I happen to think Robert's probably the most articulate evangelist for geek GTD I've ever met. He really gets both pieces so well that, of course, I demanded he write an article for 43F, right on the spot. He was kind enough to play along, and flipped around this terrific piece in record time.

As he covers in this series, a lot of Robert's time over the past few months has been spent putting together the GTD Connect membership program, as well as making sure all the company's lights stay on from a technology standpoint. Since I know a lot 43F readers share Robert and my interest in GTD and programming, I'm sure you'll dig hearing from him. He successfully pulls together some pieces I've had floating around in my own head, and I thank him much for sharing this.

[Note: Part 2 of Robert's article, entitled "GTD and Extreme Programming," appears Wednesday on 43 Folders.]

Getting Software Done

by Robert Peake, David Allen Company

Since launching GTD Connect, we have gotten a lot of great feedback not only on the content, but on the technical underpinnings of the system we built to deliver the audio, video, forums, podcasts, and other goodies on the site. What a lot of people may not realize is that, to my mind, a lot of the elegance expressed in the technology that drives Connect stems from the fact that we implement and use the GTD methodology in our software development process. We really do "eat our own dog food" at DavidCo, and I'm convinced that necessarily translates to a more positive user experience overall in every product we produce, and especially software. A lot of people also don't realize how highly relevant GTD is to the software development industry specifically, and how many interesting parallels there are between software best practices and workflow best practices (i.e. GTD).

So, I'd like to run through some of the relationships between GTD and developing software well, using the past eighteen months or so of building up GTD Connect from concept to reality. I'll use our experience building Connect as a kind of case study to ground some of the concepts and ideas with practical examples. Having seen a range of tactics deployed in software development by other companies, I can definitely say that our outcome-oriented, GTD-inspired approach to building out the web applications that make GTD Connect work has been far and away the most functional and positive approach I've encountered so far. So, if any of these tips and tactics strike a chord with you, I encourage you to consider looking at how you might fold these concepts into your own project management -- whether or not the project is software.

Part I: Why GTD Matters To Programmers

The first myth to dispel is that programmers don't need GTD. The Orwellian (or perhaps even Kafkaesque) world in which a programmer is nothing more than a human vessel for translating detailed design specifications into lines of code -- left to right, top to bottom -- is nothing more than a nightmare. The waking reality is that programmers in functional development companies make complex decisions and juggle multiple priorities constantly. And don't even get me started on interruptions. I have seen so much time, energy, and cash sunk into complex Gantt charts that get obliterated with the flick of a CEO's finger. Any company that thinks A,B,C priority codes and strap-on horse blinders for their programmers are effective means to stay on the leading edge of software is headed for a rude awakening.

Permit me, if you will, to borrow a few pages from computer science for a minute to illustrate the power of GTD in the programmer's world. The term "serialization" can refer to a process of basically freeze-drying data into a format that can later be reconstituted and played with elsewhere in the program. It's a very powerful technique for maintaining the state of the data, intact, as you transport it to another location (physically, virtually, whatever). Using a trusted system with the GTD methodology allows you to serialize your work life -- to freeze dry it in a readable format (your system, be that a Hipster PDA, a plain text file, or a fancy graphical task manager). By effectively bookmarking your complete working state just enough so that you can pick back up where you left off, GTD actually allows you to deal with the boss that comes in every five minutes to get an update on your TPS report cover sheet. The promise of a trusted GTD system is the promise of never having to think twice about what you were doing; just as the promise of serializing data is that you don't have to re-instantiate or re-calculate the structure you serialized. Store it, retrieve it, add water, and poof -- you're back up and running without any wasted cycles.

You can also handle massive changes in the architecture of the software you are working on -- whether that's coming from inside your company or via a customer -- because the beauty of the GTD system is that it deals with ambiguity in real time. The analogy I use here is data search trees. If you imagine a tree with many branches, the depth-first approach to searching the tree would be to go down to the end of every branch and back again. The breadth-first approach just involves checking out all the junctures on one level, then the next. GTD is a breadth-first approach to handling your life. Rather than trying to run down all the branches to the end, using GTD means thinking just as far ahead as you need to think in terms of your actions, and no further. So when things change in the real world, as they invariably do, you don't have to spend hours re-drawing the Gantt chart -- instead, you are already at the appropriate juncture, and can instantly re-calibrate and change course to take the next most appropriate path. This means you are constantly thinking at the level where the surprises really happen, rather than building out into the future on a potential house of cards. For risk mitigation, as well as remaining in step with an evolving understanding of complex projects, this is huge.

GTD in this way also provides the ultimate "safety net" for making sure stuff doesn't slip through the cracks. Sure, the act of programming in itself is highly linear: you run down the path until you have satisfied your test cases, then you move on to the next thing. However, in addition to bookmarking your progress along the path so that you can get right back to what's important after an interruption, GTD also gives you a complete, trusted inventory of all of the very next steps along all possible paths. Combined with an overall strategy (obviously), this means you can program with greater confidence and peace of mind -- can run down the trail knowing it is the perfect trail for you to be running down at this moment -- because you have scanned all the other options first, and know this course to be the best. Life, especially the life of a developer, is an open-ended, unknown tree. And the breadth-first approach of GTD is necessarily the most efficient option for traversing that tree.

For the old-timers in the crowd, a much cruder form of outputting data from the running program in a storable format is the famous core dump. So named because originally magnetic cores stored the ones and zeroes involved, this process is the software equivalent of downloading your entire brain into a file. Wouldn't that be nice? The "mind sweep" component of GTD is just that, and in fact David has often referred to it as a kind of core dump for "psychic RAM." This is how you periodically check in with your own brain to see what is holding your attention, and get it out of there to look at. This is how you assemble those lists of possibilities (projects and next actions) that serve as the safety net to give you confidence that what you are doing is the right thing to do, and combined with the two-minute rule and next-action thinking, gives you that freeze-dried bookmark of your working state so you can seamlessly pick up where you left off when (not if) you get interrupted.

Clearly, programmers need GTD more than Jolt or Domino's. And the people managing programmers, responsible for architecture on the front end and quality assurance on the other side, need it just as much. Permit me to explain...

[Note: Part 2 of Robert's article, entitled "GTD and Extreme Programming," appears Wednesday on 43 Folders.]

Update 2006-10-18 10:05:52 - For your convenience, here's an easy-to-print HTML version of both of Robert's posts.

”Guest Post: DavidCo's Robert Peake on "Getting Software Done" (part 1)” was written by Merlin Mann for 43Folders.com and was originally posted on October 17, 2006. Except as noted, it's ©2010 Merlin Mann and licensed for reuse under CC BY-NC-ND 3.0. "Why a footer?"

Merlin on MacBreak Weekly: Apple's "Showtime" event

Merlin — Wed, 13 Sep 2006 02:18:09 +0000

MacBreak Weekly 6: It's Showtime

Hosts: Leo Laporte, Merlin Mann, Chris Breen, Alex Lindsay, and Brett Larson

Complete coverage and analysis of Apple's "It's Showtime" announcements...

As usual, the perspicaciousness of my insight reveals itself in quips like "This is pretty" and "People should buy this" and "Apple seems smart." Is it any wonder the Windows People hate us? No, friends. No, it isn't any wonder at all.

Running time: 58:49

[Download MP3 file]

”Merlin on MacBreak Weekly: Apple's "Showtime" event” was written by Merlin Mann for 43Folders.com and was originally posted on September 13, 2006. Except as noted, it's ©2010 Merlin Mann and licensed for reuse under CC BY-NC-ND 3.0. "Why a footer?"

Samsung A-920 as a Bluetooth Mac modem

Merlin — Thu, 13 Jul 2006 11:19:33 +0000

noDRM.com » Blog Archive » How To: Use Sprint/Samsung A920 as an EVDO Bluetooth Modem with Mac

Earlier this year, like many of my siblings in the minor web dorkerati, your author was made a “Sprint Ambassador.” This is actually not nearly as fancy as it sounds — you still have to pay parking tickets and can’t necessarily have rude waiters whacked with impunity. Plus you get this really weird (Kansas? Missouri?) area code that makes all your friends think you’re a telemarketer or a Republican pollster.

Anyhow, the deal is that Sprint sends you their multimedia Samsung A-920 to use for free for a few months in exchange for offline comments (and, one speculates, the chance that their little blue unit might make an appearance in, say, a blog post along the lines of the one you're reading).

The phone’s okay, I guess — although why it takes 8 mother-scratching clicks to send a photo to Flickr from this purportedly high-end “multimedia phone” is just really hard for me to understand. Plus, until the other night, I’d never been able to use the EVDO modem functionality that’s one of the phone’s marquee features. The idea of internet access from any place that gets a phone signal made me salivate in the early days of my Ambassador tenure, but, as with so many of these things, I quickly made my peace with the usual excuse; unsupported on Macs. WANH-wahn. Still gotta drive to Starbucks to check my email on vacation. Oh, well.

Turns out I was wrong, and, boy, do I love being wrong about this.

It’s actually pretty easy to use the phone’s Bluetooth connectivity to get wireless internet via EVDO. I learned this a couple nights ago from an unbelievably helpful advanced tech support person from Sprint. She found some arcane tome that explained, yes, it’s unsupported, but, yes, here’s how to do it anyway on a Mac. And she sat there and walked me through the whole friggin’ thing over 15 minutes. Nice. (I checked three times to make sure this was actually someone from Sprint, since said help seemed antithetical to the global brand of assy customer service they’ve been crafting over the years).

I was going to write up a short tutorial on this, but a bit of Googling told me the work was already done when I turned up this lovely how-to from noDRM:

Here’s the key part - the Bluetooth Mobile Phone Setup Screen. Leave the Username and Password fields blank, but enter #777 as the Phone Number. Choose Sprint PCS Vision as the Modem Script and click Continue.

You should see a Congratulations screen. Click Quit.

Get Connected. To do this, with your phone paired, open Internet Connect on your Mac.

Click on the Bluetooth icon and click Connect.

Now, don’t just dash off to Bit Torrent to start downloading “Black Adder” episodes from your room at the Sheraton; this is really slow access. I don’t have enough experience to know whether this is a result of the EVDOness or Bluetoothiness of the connection, but I’m seeing approximately 100 kbps connection speeds. We’re talking 90s nostalgia speeds, here. It’s still plenty fast for grabbing your email and even (patiently) surfing the web. (If anyone has advice on improving this speed, do share, in comments). Also, I get the feeling that I’ll be paying through the nose if I want this service to continue after my Ambassadorhood is revoked some time this month; I’m hearing prices in the $50/month range, which seems, well, completely crazy to me.

I may have more to say about the phone later (like: GPS map locator; don’t need: CNN on my phone; hate: Bluetooth no sync-y with iSync) or I may not. Who knows? In any case, if your own Sprint Ambassadoritude is just beginning, or you’re a garden-variety Mac user who’s bought the A-920, give the tutorial a spin. Could make life on the road a lot easier this summer.

”Samsung A-920 as a Bluetooth Mac modem” was written by Merlin Mann for 43Folders.com and was originally posted on July 13, 2006. Except as noted, it's ©2010 Merlin Mann and licensed for reuse under CC BY-NC-ND 3.0. "Why a footer?"

NYT: Mixed blessings of workplace tech

Merlin — Thu, 08 Jun 2006 13:38:04 +0000

Attention- Juggling in the High-Tech Office - New York Times

NYT talks with Ed Reilly of the American Management Association on technology's "double-edged impact in the workplace."

Q. Do all the distractions mean that people don't have time to think deeply about what they're doing?

A. There is certainly some indication that in middle to upper management, that can be a problem. If you don't properly organize your thinking and your time, you can end up concentrating on the urgent rather than the important. You can get tied up being a traffic cop in terms of answering e-mails, when in fact those things can be answered later. Management, particularly the more senior management, needs time to think.

Q. If people have a sale happening on eBay, are using several e-mail platforms and their cellphones and their office lines, does that fracture their attention span?

A. Absolutely. When people switch gears and move from one process to another, our brains require some amount of time to begin thinking about something else. Forget the amount of time you actually spend browsing on the Internet and reading things you don't really need to read for your job. Just the fact that you're switching back and forth means you're not organizing your time correctly.

Q. What impact do the distractions have on working-level people?

A. There's a curious anomaly. These tools produce more productivity. But it doesn't imply that everyone is working at maximal effectiveness. There's a general consensus that managing the quality and quantity of work from knowledge workers has proven to be more difficult than managing the work-study processes that added so much productivity to the industrial age. For example, you can assign people to customer relations jobs. They will, if you make them, respond to, say, 120 inquiries a day. The real question is whether they take a few more minutes to think about what the customer really wants and try to be responsive.

For my money, though, this one is the quote of the week:

Companies go to great lengths to set up lists of authorized approvals, meaning who can approve what size of purchase. But you will find that people who are not authorized to spend $100 on their own are authorized to send e-mails to people and waste hundreds of thousands of dollars' worth of company time.

”NYT: Mixed blessings of workplace tech” was written by Merlin Mann for 43Folders.com and was originally posted on June 08, 2006. Except as noted, it's ©2010 Merlin Mann and licensed for reuse under CC BY-NC-ND 3.0. "Why a footer?"

Study: Brits blow 2hrs/day on inefficient tech communication

Merlin — Mon, 05 Jun 2006 13:46:58 +0000

[Misuse of office technology adds more than two hours to the average British working day]

Couldn't track down the source material from the UK productivity study referenced in this press release, but, if they're accurate, some of the data are interesting to say the least.

The misuse of telephones and email at work is hindering workers from doing their jobs, increasing bad habits at work and lengthening the working day...

Two hours, 10 minutes was the amount that people wasted each day at work on average, of which one hour 38 minutes was due to communication technologies not being used to good effect.

Seems conservative to me, but -- you know -- I'm a terrific karmasuck about these things.

Also intriguing are these bullets on "average times wasted each day:"

Travel not including to and from work: 14 minutes

Chasing responses to urgent emails: 42 minutes

Responding to voicemails or managing phone calls: 27 minutes

Trying to locate colleagues: 12 minutes

Meetings that are unnecessarily long: 12 minutes

Asking others for files or documents (e.g. version control): 9 minutes

Scheduling and rescheduling meetings: 8 minutes

Conference calls that could be far shorter: 6 minutes

I'd love to see a number on the people who refuse to capture/liberate the tasks from their incoming email; I'd wager there's 30-90 person-minutes a day in there for "Scrolling through inbox and staring haplessly at 1,200 unprocessed messages."

”Study: Brits blow 2hrs/day on inefficient tech communication” was written by Merlin Mann for 43Folders.com and was originally posted on June 05, 2006. Except as noted, it's ©2010 Merlin Mann and licensed for reuse under CC BY-NC-ND 3.0. "Why a footer?"

Evergreen advice on email and voicemail

Merlin — Tue, 30 May 2006 12:29:15 +0000

Managing the Trend Toward Increasing Use of Electronic Messaging Tools

I've been Googling around for good advice on how people deal with "email overload," and I think this 1999 report from the CommCore Consulting Group may contain some of the more sound and evergreen advice out there for not contributing to the noise (cf: "Writing sensible email messages").

It covers etiquette and best practices for both voicemail and email. Some of the best tips on email:

Keep e-mail short and focused on one issue, and reflect this issue in the subject heading. Many people are inundated with e-mail. Focusing each e-mail on one issue allows time-crunched recipients to prioritize your e-mail and respond as necessary. Including a sharp, strong subject header can differentiate your e-mail and attract your reader to your message...

Don’t use the Reply to All function unless everyone needs to know the information. Copying people on messages unnecessarily can overload systems, annoy readers and waste everyone’s time...

Manage your e-mail. Try to keep the number of messages in your in-box at a minimum by cleaning out e-mail in-boxes and message logs frequently. Use the filing system in your e-mail program to save needed messages to the appropriate folder. This clears space in your in-box, but saves the e-mail for future reference...

And on voicemail:

Prepare for every telephone call expecting to get voicemail. This will help you focus your message and prevent rambling. You should treat your voicemail message as a short presentation, thinking it through ahead of time, not during the recording...

Keep your voicemail short and to the point. Don’t bore your listener or bury important information at the end...

If you are conducting a conversation via voicemail, i.e., trading repeat voicemails without reaching someone in person, summarize the situation and what you need from them in your message. This will help move the conversation along. For example, you might include a list of information that you need to close a deal. The recipient can gather the information and for the next phone call, or even leave it on a return voicemail to you...

Six-year-old advice -- but probably more useful and timely now than it was in 1999.

Seem all too obvious to you? See if it seems so obvious next time you're changing planes, have a coffee in one hand, your carry-on in another, and your ear pressed against the Nokia as you try to blow through twenty-some voice mails.

Dimes to donuts, half of your messages will have you wishing obvious advice like this had been absorbed by more of the people in your life.

”Evergreen advice on email and voicemail” was written by Merlin Mann for 43Folders.com and was originally posted on May 30, 2006. Except as noted, it's ©2010 Merlin Mann and licensed for reuse under CC BY-NC-ND 3.0. "Why a footer?"

Levy: The frazzled attention of the "always on"

Merlin — Thu, 30 Mar 2006 16:11:06 +0000

Levy: Digital Distractions Bad for the Workplace - Newsweek Technology - MSNBC.com

Steven Levy on continuous partial attention and "The Attention Economy" at ORA's Emerging Technology Conference.

But there's a problem in the workplace when the interruptions intrude on tasks that require real concentration or quiet reflection. And there's an even bigger problem when our bubble of connectedness stretches to ensnare us no matter where we are. A live BlackBerry or even a switched-on mobile phone is an admission that your commitment to your current activity is as fickle as Renée Zellweger's wedding vows. Your world turns into a never-ending cocktail party where you're always looking over your virtual shoulder for a better conversation partner. The anxiety is contagious: anyone who winds up talking to a person infected with [continuous partial attention] feels like he or she is accepting an Oscar, and at any moment the music might stop the speech.

In her talk, Stone was careful to acknowledge the benefits of perpetual contact. But her message is that the balance has tilted way too far toward distraction, creating a sense of constant crisis. "We're not ever in a place where we can make a commitment to anything," she explained to me when I called her a few days later. "Constantly being accessible makes you inaccessible." All so true.

I have to concur on the ironic hilarity of an ETech ostensibly being devoted to the topic of "The Attention Economy." As someone who's been both on the dais and down in the pit, I don't think I've ever seen so many overstimulated people struggling to find even more stimulation. It's harrowing.

[ via the 43F Board ]

”Levy: The frazzled attention of the "always on"” was written by Merlin Mann for 43Folders.com and was originally posted on March 30, 2006. Except as noted, it's ©2010 Merlin Mann and licensed for reuse under CC BY-NC-ND 3.0. "Why a footer?"

Open Thread: Whither Blackberry? What's your fallback plan?

Merlin — Thu, 01 Dec 2005 14:47:58 +0000

BlackBerry shutdown closer after ruling - U.S. Business - MSNBC.com

RICHMOND, Va. - A federal judge has rejected an effort by BlackBerry maker Research In Motion Ltd. to settle a patent case and moved a step closer to reissuing an injunction that threatens the device’s e-mail service in the United States.

RIM said in a statement that it has been preparing technology that would keep its service running in the U.S., where most of its 3.65 million BlackBerry customers are based.

[ via Slashdot ]

Damn, this could be pretty big stuff, eh?

I'm guessing at least a few of you out there are rabid Blackberry users -- I've never even used one myself, but I have friends who live on theirs. So, I'm curious: How do you feel about the possibility of losing Blackberry service? If it went away today, what would you use instead? Do you have a fallback plan?

”Open Thread: Whither Blackberry? What's your fallback plan?” was written by Merlin Mann for 43Folders.com and was originally posted on December 01, 2005. Except as noted, it's ©2010 Merlin Mann and licensed for reuse under CC BY-NC-ND 3.0. "Why a footer?"

Make #4 now available

Merlin — Thu, 20 Oct 2005 12:55:38 +0000

MAKE: Technology on Your Time, Volume 04

O'Reilly's quarterly Make Magazine Volume #4 is now available for order from Amazon.com.

As ever it will be filled with new ways to turn your doorbell into a death laser or make a functional hovercraft from a Mr. Coffee or even remove the DRM from a six-pack of Mr. Pibb. It's all in there, along with the usual "Life Hacks" column from Danny and me.

This month's column features our long-anticipated showdown/throwdown on digital vs. paper. Two step into the octagon and only one, One, ONE will step out. (Well, actually: after realizing it's all been a simple misunderstanding, they shake hands and agree to work quietly on separate projects.)

An excerpt:

Friends, we're here today to unveil the august secret that we hope will save potentially dozens of Important Technology Writers from needing to produce another wide-eyed report on how very odd it is that all these geeks seem to love paper so much. The trick is that there is no paradox, no more so than suggesting that people who buy screwdrivers must necessarily hate drills.

Geeks rely on paper for the same reason that the normals do: paper — along with conceptual cousins like whiteboards and magnets — is simply the most efficient tool for completing certain kinds of cognitive work. And no amount of enhanced technology will likely diminish this anytime soon.

Make #4 will be available soon in finer book stores, but if you want it soon, you need to get it from our friends at Amazon: $10.19 (Cheap). To get 'em all hot off the presses, you could also treat yourself to a 1-year subscription (currently: starts you with issue #3).

Just think of the hours you'll fritter away. It's intoxicating.

”Make #4 now available” was written by Merlin Mann for 43Folders.com and was originally posted on October 20, 2005. Except as noted, it's ©2010 Merlin Mann and licensed for reuse under CC BY-NC-ND 3.0. "Why a footer?"