Arduino Uno by Snootlab
A few months ago, my local maker-space (091 labs) presented a few informal tutorials on Arduino. Having seen it mentioned online, I decided to bite the bullet and drop by to learn more. Shortly later I purchased the Experimenter’s Guide for Arduino, which was used during the tutorials. Being further interested in Arduino and it’s capabilities, I subsequently bought the Arduino Cookbook
Moleskine and Pen
George Bernard Shaw is quoted as saying, “The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man.” While we all appreciate progress, I sometimes have to wonder at the way people look at the world.
INBOX 0: Tarditas et procrastinatio odiosa est
I’ve recently become aware of Getting Things Done, and have been attempting to practice it for the last six weeks. In many ways, it is very similar to what I had been doing previously. You could call my method a lightweight GTD, and it’s based on the FART mnemonic.
For any item that crosses my desk, be it email, IM, memos, or stickies, I follow the same basic triage process. Four directives (File, Act, Redirect or Trash) are applied based on a few simple considerations. These are as follows:
If so, file it somewhere easily searchable such as a mail folder, content management system, Wiki, etc. Remove the item from your In-box to the file location. Continue to consider the other questions.
If so, add a to-do to your to-do list. Prioritise and schedule work on the action using your to-do list. Remove the item from your In-box by Filing, Redirection, or Trashing.
If not, redirect or delegate it to someone else. You may, if you feel you need to, add a reminder to your to-do list to follow up with the delegate.
By now, you’ve filed the item if necessary, decided to act on it, or delegated it. What other possible action can you now take? You have extracted all value from the item, so the only other option is to remove it from your In-box. If you have not done so already, or filed the item to a folder, move the item to the trash. You are now done with processing your incoming items. All that remains is to tackle your to-do list.
Repeat as necessary, and you will soon find that heap of email shrinking. In-box 0 is not an impossible goal. All you need to do, is think outside the In-box!
Project Management Porn
Anecdotally, I had always known that Software Engineers are terrible at estimation. I had never realised exactly how bad we are.
Some rules of thumb which seem to pop up now and again, is to take your engineers best estimates, and double them. Then you’re actually in the ball park.
Continue reading
Tag Cloud
It saddens me sometimes to see videos like this. While the rest of us chuckle, we fail to learn the lesson, that users don’t share our world view of software.
As a Software Engineer, I am too well aware of our industries penchant for technical terms. Yet the fact remains that you can use the internet without knowing what a “browser” is, just as well as you can drive a car without knowing what a “limited slip differential” is.
Innovation in Corporate America
As I mentioned in Between a Rock and a Hard Place, our team is currently on the horns of a dilemma. I likened our situation to racing on a flat tyre. Do you stop and fix, taking the hit of lost time, or do you make a best effort to keep pace, almost blindly disregarding the situation.
I’ve just finished reading Sway (Brafman & Brafman, 2008). It offers some additional insights into our situation. For example, all my engineering training has been around technology. How computers work, how software works, how to create good software, how software design works, how the software process works, etc. As far as I remember, no time was given to group dynamics. Since most non-trivial software requires a team to collaborate, one would think that taking the group into account would factor into software design and engineering.
Continue reading
BBC News reports that a recently published Microsoft study found that more than 97% of email sent is spam. Seeing this, I can’t help but feel that email is becoming a victim of it’s own success. With a signal to noise ratio like this, one as to wonder how long it can be before email becomes ignored as a mainstream communications channel?
InstallComplete
TG Daily reports that Mozilla have found that 50,000 people fail to install Firefox every day. On one hand, I find this surprising, but on another, not so much.
We’re going dark this week as part of the Blackout Ireland protest. This is a protest against a recent court settlement where Eircom (a major Irish ISP) has agreed to start disconnecting Internet users based on unsubstantiated accusations from the Irish Recorded Music Association (and its members).
While we acknowledge IRMAs right to defend its copyrights, we are agrieved at the manner in which it is doing it. Accusing people of infringing copyright and disconnecting them from the Internet without giving them the right to reply, or proper judicial oversight is wrong. This sets a dangerous precedent for freedom of speech online, and moves Ireland one step closer to Internet censorship.
Fall-2006
Since I realised this, life has become somewhat easier. Being a Software Engineer means that I often have to communicate with people with non-software backgrounds, such as Clients, Management or Marketing. A difficulty we have in communication, are the multi-letter acronyms (MLAs) and other jargon which is prevalent in software, and other technical fields I imagine.
When it comes to documentation, the initial reaction of a reader who doesn’t understand what you’ve written, is to claim that insufficient information was present (whether this is true or not). The typical responce from the Engineer is to provide even more MLA and jargon loaded text. Essentially providing a larger maze of documentation for the reader to get lost in, resulting in a request for more documentation, and the cycle goes on …
The solution to this conundrum is not more documentation, but more consice and succinct documentation. Avoid MLAs and jargon where possible. Where this is not possible do your best to explain it simply. Know your audience, and speak in terms they can understand. Do your best to keep it short and to the point.
Finally if all else fails. Suggest a GIYF.
