RubyRags, a Littlelines project
We’re really excited to announce today an exciting new initiative for RubyRags (a community-spirit-building project selling Ruby and Rails themed apparel to Rubyists across the globe).
We at Norbauer Inc created RubyRags a few years ago and it grew quite popular in that time, but our consulting work prevented us from giving the project the proper attention. As of today, however, our pals the brothers Matt and Josh Sears over at Littlelines are taking over the RubyRags reigns, and they have some truly awesome plans to improve the operation and give it the attention it truly deserves. We believe they’re the perfect fit for the project: not only are they huge supporters of the Ruby and Rails communities, but they also have a keen design sensibility and an enthusiasm for e-commerce.
We can only share a few of the new things in store for RubyRags with you publicly now. But, suffice it to say, Littlelines plans to restock all the popular designs that have run out of stock, and more importantly, they plan to start releasing new designs at a regular interval, similar to how PeepCode releases screencasts. RubyRags hasn’t introduced a design in years, so this is a particularly exciting development, and I’m really eager to see what they come up with (especially since Josh is an illustrator himself).
Join the RubyRags mailing list for to stay in touch with what RubyRags is up to in the coming months.
Congratulations to Littlelines, and to all of us who will get to benefit from what they have planned!
Ryan Norbauer's commonplace book
There are times when I have bits of text and other effluvia worth sharing that are somewhat extraneous to the world of web development and business and thus not quite appropriate for this space.
I’ve started a separate little notebook on the web for that purpose. For those of you who have enjoyed my writing in this space, perhaps you’ll enjoy what I’ll be collecting over there too. Or perhaps not. Maybe I won’t either. It’s an experiment. We’ll see how it goes.
Either way, I encourage you to read the introduction to my new Commonplace Book and decide for yourself.
The Psychology of OmniFocus: How to Wrap your Head Around the Finest (and Most Perplexing) GTD App on the Market
Though I have been hard-core enthusiast and sometime black belt of GTD since around the age of 20 (i.e., nearly a decade), I’ll admit to having had a certain initial reluctance and skepticism about OmniFocus. Perhaps this was due to the seeming eternity the notional app spent as vaporware, but I think it was mainly my bafflement at first opening the program shortly after its beta release. In its tiny default font and weird spacing, it presented the user with an empty list and almost no guidance on what the program does or how to use its amazingly complicated array of options for every conceivable combination and permutation of projects, lists, children, parents, siblings, start dates, dependencies, etc. I futzed with for a few minutes, realized I didn’t have a full week to spend learning a piece of software that seemed to make a simple task more complex and didn’t allow me to sync my data across computers, and I gave up.
As syncing and other improvements like increased clarity of features and flexibility of configuration options and the ability to customize the appearance of lists came along, OmniFocus was already dead to me. It wasn’t until much later when a chance frustration with the weight and drudgery of my own makeshift pen-and-paper GTD implementation drove me to give it another try that I learned precisely how amazing an implementation of David Allen’s system the folks at OmniGroup had ultimately come up with. It renders elegant and easy elements of the GTD workflow that were previously either cumbersome or completely impossible to do properly with a paper-based system (or, worse, a system based on a hack of an existing piece of software built for another purpose).
I will add, however, that it wasn’t until spending a few hours slogging through the manual that I finally “got” this about OmniFocus, and frankly I can’t imagine anyone else just downloading the software, playing around with it, and making it their primary productivity tool spontaneously. The learning curve for OmniFocus is honestly far steeper than with any other piece of desktop software I have ever used. What I have since learned, however, is that the payoff is very much worth the effort.
Read MoreDesign worth caring about.
Design should always be about the humans who will be dealing with the designed object—whether it be a building, a website, or a piece of furniture.
Interview on The Official Ruby on Rails podcast
If you’re interested in hearing me chat a bit about Rails consulting, social networks, and whatnot, give a listen.
Interview @ Slash7
My infinitely awesome friend and colleague Amy Hoy just published a fun conversation I had with her a while back. It’s pretty airy-fairy and theoretical, but that’s what makes most good conversations fun.
Mention in Wired piece on 37signals
I had a nice time chatting with Andrew Park of Wired recently about some of the subjects on which I have so frequently opined in this and other venues: simplicity in software, programmer happiness, and the role 37signals has played in promulgating those values in the tech world.
Park cited me as a source in the resulting article; (and graciously made a salutary reference to Lovetastic and my consulting firm.) It’s an interesting article, and I’m glad to see more journalists paying attention to the fact that Rails and 37signals applications are important as much for having shifted the contemporary discourse about software as they are for the technologies in question themselves. But I think if the article had any weakness, it was that it didn’t very thoroughly discuss something to which it only alluded in its closing sentence: “’I’m not designing software for other people,’ Hansson says. ’I’m designing it for me.’” Not enough attention has been paid to the growing movement in the software development community that suggests that programmer happiness is the most important factor in making quality software—the argument that code is meant to be read by humans first and computers only secondarily—that in order to write software that addresses real human needs we need to approach the problem of software development from a more human perspective. These “emo programmers” (if I may borrow Kathy Sierra’s coinage, which was originally intended as a joke) recognize that the most costly aspect of software today is the labor involved in making it. Performance is cheap. On the other hand, creating, customizing, and maintaining huge (and hugely complex) bases of inscrutable software code is very expensive. There is increasing sentiment in the software world that we should be happy to take performance hits if it means the process of software development can me made more sustainable, pleasant, and simple. That’s what Rails does. And in this it embodies a sweeping philosophy about the manner in which software development should proceed, which stands firmly in opposition to the prevailing view in much of the Fortune 500 world. I’d like to see us take up “emo programming” as a badge of pride to describe this nascent philosophy. Original terms of dismissiveness like “suffragette” and “tory” have subsequently been taken up as banners around which to rally movements, so there is no reason we shouldn’t do the same. Hopefully this article is an early sign that more people are paying attention to this movement and taking it seriously for what it is: an entirely new way of thinking about the how and whys of software development, and about the fundamental relationship between humans and their computers.Death and Underachievement: A Guide to Happiness in Work
The trite wisdom of contemporary folklore instructs us that the arrival of the New Year is a time to reflect on the achievements of the preceding 365 days and to bear down and “resolve” to achieve more in those to come. Over time, we learn what a hydra-headed beast this is: no matter how many projects or actions we may whack off our ineluctable lists, it seems that yet more (often increasingly ambitious) commitments spring up in their place. With each new year come self-recriminations for our failure to meet the unlikely goals we’ve set for ourselves—lose weight, read through those piles of books and RSS feeds, start picking up our socks, and a stultifying brainstorm of new projects we’d like to take on.
This New Year as I contemplate my resolutions, it’s the underlying concepts of achievement and productivity that are on my mind, and by extension the still grander issues of purpose and meaning in work. I invite you then, patient reader, on a desultory First Night journey with me as I take our mutual favorite hobby—the idle navel-gazing contemplation of productivity—to its most absurd yet logical conclusion: to ask whether eradicating the need for achievement itself might not be the key to happiness in work.
The (more or less) paperless life
I know, I’ve been nerding out writing for 43folders a lot lately and promise to write a cranky post here at NRS soon. In the mean time, though, here is my latest how-to over at the folders.
It seems that many of us otherwise computer-oriented geeks have a surprising and earth-unfriendly confession to make: we love paper. Notwithstanding the entirely digital nature of my own trade, for example, I’ll freely admit that there is really nothing quite like the smooth glide of a mechanical pencil over a big sheet of crisp, white office paper to facilitate good writing and thinking.
I can’t plan out a new piece of softwareâ€â€or write an essay for that matterâ€â€without first messily scribbling my ideas out as mind-maps or rough user-interface sketches onto paper. My brainstorms are too messy and flow too quickly for the computer to be able to accommodate my chaos, yet that early disorder is essential to crafting the order and structure that will follow.
And yet I used to have serious reservations about this tendency to spoodge my thought process onto tree carcasses. It wasn’t until I finally learned how to get rid of paper, that I was able properly to embrace its use in my work.
new 43folders post
Check out my latest blog post over at 43folders. Nothing big, just an intriguing (and totally nerdy) serendipitous discovery about the history of GTD.
