As consultants, something that’s important to both Aaron and myself is getting paid. We enjoy what we do, but job satisfaction doesn’t pay the bills or fund our vices. Obviously, to get paid we need to invoice clients.
Anyone who knows how Aaron and I operate understand that we do quite a bit of our work in the cloud. For the longest time that included using a Web-based, for-pay invoicing application called Blinksale.
Even though we like using Web-based tools, Aaron and I also prefer to have as much of our data in our won hands. On top of that, we’re enthusiastic users of free and Open Source software (FOSS). It not only cuts our costs, but also gives us more flexibility.
Recently, we were looking around for a FOSS invoicing solution. We found a few, and decided to go with one called BambooInvoice.
As you know, Aaron and I are posting fairly regularly on Twitter. And we’ve been noticing a number of blog posts about how Twitter can make you a better writer. Even a better tech writer.
It’s an interesting idea, and I have to agree with it to a point. When microblogging, you have 140 characters (including spaces and punctuation) in which to make your point. And you need to pack as much information as you can into that small space.
Over the last several weeks, part of my evening ritual (if you want to call it that) has involved re-reading a few of the books on my bookshelves. Everything from Harlan Ellison‘s essays to I.F. Stone‘s musings on the trial of Socrates, from a couple of novels by James Salter to issues of Transmetropolitan.
Recently, I was going through my copy of Crowdsourcing. If you’ve been following this phenomenon for a while, the book contains nothing new or groundbreaking. But, I have to admit, the last chapter got my attention. Especially the the section “Keep It Simple and Break It Down”:
When it comes to crowdsourcing, any task worth doing is worth dividing up into its smallest possible components.
That definitely has application in the wacky world of technical communication.
That can be a tough question. But it can also have more than one branch. But it’s definitely a question that technical communicators need to ask when documenting any piece of software or hardware.
One of those branches is knowledge of the underlying platform. I’m not talking about being familiar with, say, Win32 or Linux internals or hardware addressing. But does the person using an application or device know how to:
- Install supplementary software (for example, Adobe AIR) or hardware (for example, a memory card)
- Navigate around an operating system or device
- Perform basic operations and carry out basic tasks