Usually you don’t hear someone described as well-intentioned until they’ve messed up somewhere.

I know too many talented and well-intentioned people who are professionally ineffective. Ineffective, because the result of their effort isn’t meaningful progress toward making tomorrow better than today.

(Measuring better is going to depend on the task at hand. For knowledge work, let’s say better means less repeating yesterday through mindless zombie motions today.)

Never-ending droplets

In some roles, emptying a bucket that will never stop filling up with accumulated droplets is the job description.

The ineffective way to handle these never-empty buckets is to just occasionally dump them in the sink.

It would be a lot more productive to dump these buckets into a garden. Our endless tedium could help produce useful resources — food, flowers, trees, fish-stocked ponds.

Conservation of the point

My point isn’t that you should run around hugging trees (but feel free!). Instead, every time you’re barraged with tedious tasks that have no end in sight, and you can’t automate them, find a way to build a garden out of them.

Instead of repetitively laboring through the same questions in phone calls and e-mail, treat them as a resource for constantly improving your documentation or website in ways you hadn’t originally thought of. Tomorrow those improvements will undoubtedly save everyone time.

Using the same example, you could also make a habit of asking each person who calls or e-mails a question of your own. You could tune your marketing without obnoxious and impersonal surveys.

You’ll start to perk up every time the phone rings.

Paraphrased e-mail:

“You should be ashamed of yourselves for charging for software built on free software!”

Hey Potential Customer Who Feels All Software Should Be Free,

I wanted to write you a quick note about your “free software stack” jab.

Libraries, frameworks, languages and operating systems are the prime candidates for being open-source software.  Hobbyists, professionals and students can all share in the building, maintenance and testing of those components.  Everyone can benefit from them for many purposes, and anyone can feed in donations of time, word-of-mouth or money to projects they want to see flourish.

Those open-source components are also used by commercial companies to build applications which are high-level and specialized.  The libraries, components and syntax of a particular programming language act as glue that binds high-level concepts and business logic together into tools.  Such tools are a unified front-end for the constituent components that would individually have little (or no) consumer value or appeal on their own.  Such tools also require a lot of ongoing business-related miscellanea (e.g. support, marketing, documentation) that many open-source programmers would rather live without.

Commercial software has a vested interest in the open-source software it depends on, and an unspoken moral responsibility to provide time, money, recognition, or energy to those projects when possible.  It’s an ecosystem.

It would be a much bigger warning sign to me (of inexperience or misplaced priorities) if a project was rolling its own XML parsing libraries, building its own database abstraction layer, or writing its own templating system, if those components weren’t at the core of that project’s purpose for existing.

Component projects that have philosophical reasons for only promoting free software have the option of releasing their work under licenses like the GPL, which requires derivative software to follow suit.  We use LGPL or BSD/MIT licensed components, where the authors put their work (for varying reasons) into the ecosystem between free and paid software.

Complaining about that is like saying all books should be the cost of their paper because words are free.  There’s a lot of value created by someone who gathers innovative, efficient ideas and technology into a ready-to-use format for your business.

I’m certainly not ashamed of where we fit into that.  You’re a random human being on planet Earth who came into contact with us because of what we’re doing.  Did you also spend the same amount of time looking for programming languages or templating engines?  I imagine you were looking for something a little more immediately usable.

Signed,
 - A dedicated team of talented people who are perpetually immersed in building charming solutions to all those nasty business problems which led you to our doorstep in the first place.

[[ This is a first draft I posted rather quickly since I needed to share these instructions with a few people immediately. I'll be returning to this article to clean things up. ]]

Putting your screencast on most video sharing sites will require you to use resolutions much smaller than full-screen, high-definition video. It’s a shame, but so are bandwidth costs.

You can still provide an incredibly useful screencast in a small video window with a few clever tricks. I’ve found CamStudio to be one of the best screen recorders for these requirements. It has an excellent “follow the mouse” scanning feature, which lets you provide a moving region of your full resolution screen based on what you’re pointing at with the mouse. It’s also free and incredibly easy to use.

For sharing videos, I’ve come to like Jumpcut more than YouTube due to their online video editing toolset, slightly better resolution and more liberal allowances on file size and video length.

What you need to screencast:

• CamStudio: http://www.camstudio.org/CamStudio20.exe
• A Jumpcut login (http://www.jumpcut.com/)
• The DivX codec (http://www.divx.com/divx/windows/download/index.php)
• A headset microphone
• Little enough sleep or enough caffeine to make yourself interesting

CamStudio Setup:

• Install CamStudio 2.0
• Run the application.
• Region->Fixed Region->640×480
• Options->Record Audio from Microphone
• Options->Enable Autopan, Autopan Options->Speed->Max
• Options->Video Options, DivX, Quality 90%, Configure, Home Theater Profile
• Options->Cursor Options, Show Cursor + Use Actual Cursor, Highlight Cursor + Size Halfsize + Circle + Color Yellow (RGB: 255,255,125)
• Options->Keyboard Shortcuts->Record/Pause (CTRL+ F12)

Recording a Video:

• Minimize everything on your desktop and open the application you want to talk about.
• Harmonize your Chi and attempt to channel every great speaker you’ve ever heard.
• Press the record button in CamStudio (or CTRL+F12).
• A region will appear, you can place this anywhere since it will follow you around automatically, but it’s best to place it near where you want to start talking (and where the mouse is).
• Once you place the region, you’re LIVE. Start gesturing wildly and explaining your actions as a running narrative to an empty room.
• After you’ve covered what you wanted to talk about, press CTRL+F12 to pause recording. Open CamStudio in your systray and stop the video by clicking the huge blue square button in the toolbar.
• If all goes well, your video will compress using DivX and pop up a preview that you can play. By default this .AVI file will be saved in your Program Files\CamStudio directory.

Uploading and Editing the Video with Jumpcut:

• Log into Jumpcut (http://www.jumpcut.com/)
• Click “Upload” in the top menu. Click the exorbitant green upload button. Select your video file from the appropriate directory.
• Depending on your upload speed, you may want to get some more coffee or take a polyphasic powernap.
• Once the clip is uploaded, click “Create” in the top menu. Choose “Open the Editor” at the bottom of the page. Maximize your browser if you haven’t already (some options like to hide at the bottom).
• On the right, set the dropdown to “Your Media->all your clips and photos(1)”. Drag your clip to the white frame at the bottom.
• Click “Titles” from the editing toolbar in the middle of the page. I prefer “A Scanner Darky”, but feel free to shop around. Enter your title text and click “Add”. Drag the orange title timing bar from the timeline toward the left until it’s about a half-inch long. You’ll want to experiment with this when previewing your video.
• Click the rewind button in the video preview area (to the left of the play button). This resets the video to the beginning. Click the play button and watch your video.
• Unless you have a healthy ego, or you’re oblivious about your faults, you’ll probably fall to morose depths of self-deprecation while watching the preview. Attempt to remember that you’re going to be harder on yourself than other people will be, unless you had too much caffeine or you’re just really bad at explaining things off the top of your head. If you’ve had 4 cups of coffee and you’re still falling asleep while listening to yourself, it’s probably time for “take two”.
• There are a lot of other fun toys in Jumpcut, but I’m not going to bother explaining them. Play around on your own time!
• Once you’re happy with the video, or at least have resigned to the fact your voice really does sound like that, hit the “Publish” button at the bottom of the page.
• Enter title, tags, visibility and click the “Publish” button.
• You have a video! Even if you chose to make this video private, you can still share the URL with people you trust with your fragile ego in the palm of their hands.
• You can embed this video on your website by clicking the “share” link under the video and copying the “embed” HTML. There are also several other provided options for distributing your video.

Feel free to provide a link to your video in the comments here!

I’m clenching a rough rope tightly between my left thumb and forefinger as I descend down the throat of a bottomless pit. I am not encumbered by the panicky implications of safety equipment. My right arm is gesturing wildly into empty space, acting as the ground-wire for an overstimulated mind.

I tilt my head back and let my eyes reassuringly trace the taut lifeline up to the tiny disc of blue sky, the size of a full moon, capping the vertical chamber. The sight sparks an anonymous memory, which flutters to dutifully provoke a faint aftertaste of life in the center of my chest. Never willful to leave anything unanswered, a familiar dream-like reality superimposes itself on my surroundings. It’s as if I’m standing in a subway tunnel, directly facing an oncoming car, while being pulled backwards strongly by something’s insistence that it’s the proper place for me to be. I twist my head to look over my right shoulder, but everything is dark and shapeless. The illusion melts. I find myself still inching downward, carnally addicted to the growing clarity of my thoughts; paternally insulating them from everything that only knows how to dampen and mute.

I pause to contemplate how I’m as equally dependent on the rope staying anchored from above as I am on my desire to not let go of it. While the only biofeedback I’ve received so far has promised that further down is better, I ask myself if I’m any more objective by now than an alcoholic whose bitter swill has grown sweeter with inebriation. I can’t help but smirk as I tell myself the outcome of a bitter poison is the same as a sweet one — that the only difference is the courtesy of a warning.

An electric pain echoes between my left middle finger and elbow. The bloodless knuckles of my left hand wish to inform me that they’ve noticed they’re the only members of our mutual congregation who are doing any struggling. My mouth opens in instinctive response to the mental image of my left hand turning the wheel of a giant faucet, which proffers a drop but promises a torrent.

Remember the Milk is web-based task management app.

It’s been a month since I made Remember The Milk (RTM) part of my daily life. At this point, I’d go through massive withdrawals if I had to “Forget The Milk”.

Tips:

• It’s not very obvious that you can edit multiple tasks at the same time by pressing ‘m‘. This is really useful, because I often find myself wanting to tag or schedule several related tasks to reduce repetitive keystrokes and mouse gestures.
• There is a huge list of advanced search options. You can convert any set of search results into a dynamic Smart List. For example, if you search for “dueBefore:tomorrow” you can create a list which will always show the current and overdue tasks for today. Just click the “Save” tab to the right of the results. This gives you a list you can work on until it’s empty, instead of the default lists which will always have future tasks at the bottom. It’s far more motivating to work toward an empty “to do” list!
• Make your lists “Getting Things Done” contexts like @Errands, @Home, @Office and @Study.
• Your lists sort on priority by default. If you change the sorting drop-down to due date it will still sort each date by priority. This makes it easy to spot the occasional high priority task that’s overdue, which you generally want to handle before today’s tasks.
• If you’re like me, it’s a hassle to try to find a specific browser tab when you have 100 tabs open across 15 Firefox windows. Try firing up RTM in a separate browser (IE, Opera, Safari). This makes it a lot easier to jump around the desktop taskbar throughout the day while being productive.

Surprises:

• I originally looked at RTM for the Twitter integration, but I find myself adding tasks through their web interface more often than I use the IM->Twitter->RTM functionality.
• We set up our entire team on RTM so we can share tasks, but with RTM is always reminding me about the next productive thing I should be doing I rarely find myself dwelling on what other people are doing.

Likes:

• Reoccurring tasks are my favorite feature. These help ensure I’m making constant progress on our business objectives (“reply to forum posts every weekday”, “reply to blog comments every weekday”, “assign project tasks every Monday”, “audit the backups every Sunday”), as well as the mundane household things I often overlook (“drag trash cans to curb every Thursday”, “make credit card payments every Friday”).
• The iPhone interface is very convenient, especially if you have context lists like @Errands.
• The flexibility on date entry is fantastic (e.g., “every other Thursday at 5pm”).
• Being able to send a single task to multiple contacts (without having to duplicate it) is a big time-saver.
• $25/yr for the Pro features is quite the bargain.

Peeves/Wishlist:

• It’s a little annoying that the current task remains checked after I save an edit. This forces me to habitually press ‘n‘ (select none) when maintaining my lists.
• I wish I could make my to-do & completed lists public so my contacts could see what I’m working on.
• It would be amazing if my contacts could be notified (by e-mail, Twitter) when I finish a particular task that they’re waiting on. That would be easy to pitch as the killer Pro feature.

If you aren’t using RTM yet, check it out!

Related reading:

• Lifehacker readers vote for Remember The Milk as the best web-based task manager.
• Remember The Milk now integrates with Gmail!

After my post “JIRA Is More Annoying Than Having to Eat Three Times A Day” was published yesterday, Jon Silvers from Atlassian (developers of JIRA) stopped by and left a friendly comment.

I’m incredibly impressed that my tongue-in-cheek critique came to his attention so quickly.

Hey Jon,

First, thanks for commenting! I’m glad you took my ranting in good spirits and left a gracious comment. I must not have put my karma into overdraft protection.

“Hm, there are lot of people who want to eat three times per day, even some that would be happy with one meal.”

Ouch! At the risk of sounding insensitive, I’m sure they also find the daily existential requirement of eating — and the neuroendocrinological punishments for not eating — profoundly annoying too. At least breathing is automatic, or we’d get absolutely nothing else done. I certainly can’t argue against the fact that we’re incredibly lucky in our selection and availability of food.

“My other first thought after reading this is whether you’re using filters to find only the issues relevant to you? [...] It’s not consumer software, it was never meant to be.”

Yeah, the customer-facing bit is really the key to our issues. We’re directing end-users to JIRA to submit their own feature requests and bug reports. For many of the reasons that JIRA is great for developers (e.g., specificity), it’s conversely daunting for our average end-user.

It would be great if we could really take a democratic community pulse on various feature requests to help us build each release roadmap. The voting feature does exist, but our experience has shown that only the most enthusiastic users will go through the trouble of logging in, reading all the open requests and voting on each task’s profile. Unfortunately, the demands on most people’s time necessitates community polling features that are more socially “Digg-like”.

As I mentioned in my post earlier, I did get the impression that a non-developer user community wasn’t intended to be directly served by JIRA’s interface; however, I’m sure we’re not alone in sending end-users to JIRA anyway. There isn’t a good alternative, beyond fielding every request personally in real-time, or transcribing requests from piles of e-mail. JIRA at least ensures busy developers won’t unintentionally ignore feedback.

“We are working interface improvements, with the knowledge that (A) lots of people really like JIRA as it is today and don’t want many changes and (B) others like you want to see change.”

We’re in both camps. As techie developers, we liked JIRA enough to buy it. As community-driven software designers, we feel JIRA needs an additional community-focused interface that streamlines the feedback process and allows user democracy to contribute to project decision-making.

I’d like to see distributed feedback from the community helping to elevate the great feature requests and showstopping bugs above the overwhelming majority of trivial or self-indulgent requests. That would save us a lot of time as developers, and it would display that we’re always listening (which encourages more feedback, and the cycle continues).

Here’s one of the features I’d headline if I was going to create a JIRA alternative:

Even when we aren’t expecting users to directly vote on tasks or add themselves as watchers, we need the ability to create a private waiting list per task. That list would allow us to add links to helpdesk tickets, forum posts or attach contact e-mail addresses. Once we’ve finished a given task, that waiting list tells us exactly who to ping. There are ways to currently hack this together using private comments on tasks, but the feature really should require that we’re notifying the waiting list before the task disappears.

“You might also want to discuss your pain points on our forums [...] or if you can stomach (pun intended) another JIRA, you can log issues and feature requests…”

Haha! I’ll do that. It’s certainly more efficient for you guys than implanting tracking devices in rogue bloggers (or, you know, following everyone’s RSS).

It’s great to see that you guys are so on top of feedback.

Photo by bocavermelha

Up until I snapped a few minutes ago, I wasn’t sure anything could be more annoying than having to eat every day. After all, I’ve been told by close friends that I’d be a happier entity if I was simply a brain in a jar, left entirely to its own thoughts. I don’t disagree.

Tonight started out normally enough:

• I fired up JIRA for the thousandth time.
• I dug through the ever-shifting, free-for-all, trivial-showstopper, dupe-a-thon of a roadmap for the thousandth time.
• I wracked my brain trying to sort out the new bugs and wishlist items from ‘Unassigned‘ purgatory, which contains over a hundred tasks that aren’t either outright reject-worthy or important enough to schedule.

Except tonight, something cried out in my mind and asked Why are you reading every single thing AGAIN?

It’s pretty embarrassing when you don’t have a good answer for your own internal teleprompter. It must be something like catching yourself with your pants down. There really is no explanation.

I don’t think it’s entirely JIRA’s fault — but I do think I’ve realized we aren’t their target audience. We’d rather just play bouncer at the door of Club Development and decide which tasks are on the guest list, are too damn sexy to turn away, or have a $100 bill cleverly folded into their handshake. Instead, we have tasks sneaking in the side door, cloning themselves, and all simultaneously proclaiming themselves the most interesting thing in the room.

There’s no reason that a user of our software, clutching a precious scrap of feedback, should arrive at Fort JIRA and be put through the Mensa screening program before they can share. We should be rolling out the red carpet and carrying them to the suggestion box in a golden litter.

Perhaps JIRA wasn’t meant to be customer-facing – and that would explain quite a lot. But if I was going to adopt something for my own neurotic use I’d just keep writing out my ideas in magic marker on rolls of toilet paper (or as I like to call them, perforated Post-Its).

Simply stated, we need something that:

• Doesn’t require a customer login of any kind (but may test for humanness).
• Doesn’t feel the need to ask the customer for more than a block of textual feedback.
• Will bother looking for possible duplication when submitting bugs or ideas.
• Allows our developers to quickly tag, categorize, assign and prioritize suggestions on acceptance without requiring us to open each task’s freaking FaceBook profile.
• Lets us simply pile accepted tasks into “Doing now”, “Will do later”, “Probably will never do, but we don’t have the brass pendulums to say so”.
• Provides simple RSS for everything (e.g., new submissions, current assignments).

Maybe I’ll write it. (Then someone can rant about all the things it can’t do that JIRA can.)

Can anyone save me from the compulsive desire to write things from scratch? Let me know in the comments.

Photo by Grazie, Davvero

Robert Scoble recently stated why enterprise software isn’t sexy enough to cover on mainstream technology blogs.

He offers two arguments:

• The majority of tech blog readers will never be in the position to buy enterprise software.
• Stories about business software, due to a disconnect with their readership, don’t produce meaningful traffic for the blog’s advertisers.

He then asks what can be done to make business software sexy enough to talk about.

Here’s my take contribution to the discussion:

For the bloggers:

If a large software company is giving day-to-day end-users the cold shoulder to schmooze with the market’s decision makers, then they aren’t owed any organic word-of-mouth.

As Scoble points out, anecdotally (but my experience agrees), most workers on a company’s front lines will probably trend toward hating their current business software when asked. In fairness, I also doubt the majority of those workers are offering management a request for any specific alternatives.

This is one area where technology bloggers could be doing a valuable public service, by informing technology workers about the good ideas coming out of the business software market. Make people say “That is much better than the crap I have to use every day!”.

Even if these tech workers are disempowered, and feel their petitions to management are futile, the situation will never improve if the only discussion going on is paid for with multi-million dollar advertising budgets.

For the enterprise software developers:

Assuming for the moment that you want more organic word-of-mouth (and who doesn’t):

• Hire and empower enthusiastic developers who bring fresh perspectives to your problem domain. Look for developers who have first-hand experience as users of software like yours. These people are going to put more thought into the problem you’re trying to solve for people. If time is money, then efficiency is time. Time and money are sexy. 12 keystrokes for common functionality is not.

• Listen to your end-users. These are the people who have to use your application every day. You might think it’s more important to appease the people making the current buying decisions, but today’s helpdesk worker may very well be tomorrow’s influential startup founder. Technology enthusiasts like this attract a large following and they love to talk about what they’re discovering or using. Don’t outsource your suggestion box – let your actual developers connect with the end-users through online communities and feedback portals. Two-way communication is sexy. Megaphones, press releases and moats are not.

• Make an effort to adopt current technology. A lot of technology bloggers, developers and consumers would love to talk about a behemoth like you using some of the same tools that they are (maybe even some tools they wrote!). This doesn’t mean you have to offer an iPhone interface or rewrite everything in Ruby. There are plenty of opportunities for a big tech player like you to contribute to communal libraries which meet 90% of your needs already. Open source libraries and tools are sexy. Golf course nepotism is not.

• Be approachable for technology enthusiasts. Look at Sun Microsystems’ Startup Essentials and Amazon’s EC2/S3 web services. Those strategies build a relationship with non-captive users and let them figure out what you’re all about. Those people broadcast over blog, IM, text or a good old-fashioned chat over drinks. I trust what my peers tell me about you a lot more than I trust an advertising testimonial from the CEO of Megacorporation, Inc. Reaching out with downloadable demos and startup friendly options is sexy. Hiding your entry-level pricing and product demos is not.

You might want to hurry,  business software users are trying new things too.

Photo by Balakov

I’ve been programming for about 16 years now.

I almost called this my “Most Important Programming Lessons”, but I consider writing software to involve far more than a mastery over programming arcana.

When I first discovered source code, I didn’t pick up a manual and start reading about data structures and flow control. That was a lucky decision for the current me, because the former me would probably have been overwhelmed and lost interest.

Instead, I kept myself entertained by making little changes to programs that I already knew worked. I’d do fun things, like surprising the gorilla in the QBasic game ‘Gorillas‘ by modifying his thrown bananas to explode like atomic weapons. The poor guy never saw it coming.

I was writing code for me.

Anytime I showed my latest tweaks to somebody they would laugh in appreciation — but then they would always come up with another idea to push things further. What if the bananas fragmented on their descent like a MIRV missile? What if the bananas became the hero and they threw gorillas? Ha! I was hooked.

I was dealing with feedback from people who became truly inspired only after seeing something working already.

Eventually, I figured out enough through my tinkering that I could face a blank screen and enter my first instructions to make the computer do something. Paint the screen red. Draw a box. Beep!

I would only make a couple small improvements before compulsively running the program again. Did I predict how things would behave, or was I about to be rewarded with something completely unexpected (and often hilarious)?

I was practicing iterative development.

As the years of experience piled on, and I worked through various programming gigs, I started to get overly-confident in my ability to think like the computer. I wrote code for longer stretches, at times making changes so vast that it was impossible to actually run the program for several days. I also started to preemptively add new features, and I delayed for longer periods between demonstrating the new changes to actual users. “It will be finished when my task list is finished!” I thought, naively.

My growing confidence in programming was undermining my ability to collaborate with non-programmers. I was also looking at projects as a checklist of disparate tasks, instead of a cohesive experience for the user.

One day, probably after completing yet another soulless project — with my team breathing a collective sigh of relief, as if being spared from an execution at 30 seconds before midnight — it finally dawned on me that things shouldn’t be this way. Things didn’t used to be this way.

I made a short list of things that detracted from the fun I had when starting out:

• We were writing projects that we didn’t need, and wouldn’t use, ourselves.
• Management, alone, was deciding the tools we used to solved our problems, usually because of executives who bought into vendor marketing at face value.
• Our project managers weren’t programmers, and they weren’t end-users, so they couldn’t effectively communicate with either side. Their project plans revolved around the least important party — the middleman.
• Our talents were being rented out at five times our compensation.
• We had no stake, or risk, in the success or failure of our work.

Shortly after this epiphany I quit my job as a complacent programmer. I co-founded a new software company where we established an ethos of:

• Writing software that we would use as much as our end-users.
• Talking directly with our end-users instead of using middlemen.
• Sharing ideas and changes as early as possible.
• Emphasizing that sales were votes of confidence in what we’re doing going forward, opposed to a payment that merely offset our past work.

Dozens of projects, half a dozen programming languages, and tens of thousands of hours of experience later, and I it turns out I learned my most important software writing lessons in those first tinkering days with QBasic.

Did you practice any of your favorite software development lessons well before you realized what you were doing? I’d love to hear about it in the comments!

Related reading:
http://www.extremeprogramming.org/
http://c2.com/cgi/wiki?MakeItWorkMakeItRightMakeItFast

photo by Jeremy Johnstone

Burnout.

It starts with the feeling you can overcome anything.
It’s reinforced when you overcome a swell of adversity.
It languishes when you thirst for more mountains to climb.
It roars into revival when your enthusiasm brings you to the truly insurmountable.
It laughs when you try.
It grows when you struggle.
It lays roots when you capitulate.
It wins when you’re left with want for nothing.

So what’s the trick to surviving the curse of having great potential and the stubborn perseverance to succeed at all costs?

Having an anchor.
Having a necessary distraction.
Having something that lends purpose to your tireless effort.
Having a goal that means more to you than a dream you plucked out of a hat.

Not leaving yourself enough rope to make a noose with.

The last card in the deck of virtues that you want to be left holding at the end of the game is the ability to dig in and tough out anything. Because you will use it. Repeatedly. Just because you can.

Boundless enthusiasm is best exercised in small passionate bursts.
It’s best if you embrace the spirit of “boundless” without looking for boundaries.