When our team makes changes to Astrid, we have to supply a “commit message” – a short description of what we’ve done. As I was looking through our old messages today, I noticed that a lot of these messages were along the lines of “Fix some unit tests”, “Typo!”, or “More polish” – which makes sense, as many of these changes are only a line or two.

Large walls of text such as these are just dying to be visualized, so I threw our commit messages into an online tag cloud generator. It’s funny that all three of us use different words – “fix”, “fixed”, and “fixing”, though note that similar words are grouped into the most common word.

Astrid.com server:

Astrid.com for Android:

Astrid.com for iPhone:

It’s easy to generate one yourself! If you use git, you can output a file with only commit messages:

$ git log --pretty=format:%s > messages.txt

You can then send that file to a service like tagcrowd.com

Finally, some of our notable commit messages:

• MIGRATION FINALLY WORKS
• dsjkfhdsfhdjakgfdk;lafj da;f jdslkfjdsa l;fdsa
• russian is really long
• deuling windows
• over 9000
• well that was a mess
• cat of the day
• Add some rescuage if some is needed
• You’re no child of mine! You’re deleted!

The Bridges Transition Model

I’ve been reading a fantastic book called Transitions, by William Bridges. As I’ve been going, I made a list of all of the transitions in my life in the past year:

• Became a vegetarian
• Ended a relationship
• Moved twice
• Gained and lost three roommates
• Entered my “late twenties”
• Changed from renting to being a landlord at work
• Went to seven different churches
• Passed through mild depression
• Lived at home for the first time in ten years
• Became more proactive with my family
• Started thinking about the next five years
• Acquired a pet

Looking over that list, I’m starting to realize just how turbulent things have been recently. Transitions suggests that while there isn’t a universal life development schedule, people tend to go through a shift around age 30 as what they were doing before seems “not quite right”. That sounds pretty accurate, given what I know about myself and my peers.

Each transition begins with an ending (see the diagram). Endings are often sad, even when transitions are good, like getting married or moving into a new home. Endings can also trigger emotions felt during previous (possibly unresolved) endings, which can make them seem even scarier than they ought to be. The book, however, stresses that endings should be processed before new beginnings, which I guess makes sense.

From there, the neutral zone, which sounds bad, is actually awesome. Once you break from your old ways and worldview, there is an opportunity to re-see the world and life from a different perspective. Things you used to do automatically can be re-imagined because you’ve branched away from the familiar path. When I moved this past year, I realized that I didn’t want to own furniture anymore – even things I’d gotten attached to over the years. The move, painful as it was, gave me an opportunity to imagine a life without a lot of furniture, which is somehow really appealing to me.

I’m still working through the book (and my transitions), but without it, I don’t think I would have sat down and thought about the things that have happened and what they mean for my life. If you feel like everything is crazy, it just might be because there’s a lot that’s changing in your life. If that’s the case, I’d highly recommend picking up Transitions and giving it a read.

You might know this blog as a blog about startups, or engineering, or productivity. All of this is true (and hopefully more of those blog posts coming soon) – but this blog is also part of the “Internet”, which as you may know, exists to deliver pictures of cats. Allow me to introduce my furry sidekick, Gandalf (the Gray).

Gandalf is a handsome critter, posing for the camera when he feels like it.

You’re cooking? Don’t forget me!

You don’t mind if I use this as a couch…

Brr… it’s cold tonight

The most interesting cat in the world

He also likes to play – with toys, yarn, and people.

Home-made cat toy, courtesy of Ellen

Furry mice also work

Ellen & a ball of yarn

My favorite toy… is DA BIRD

Read more…

Ah, the rarified air of the software architect. There is no source control up here, no text editors, or servers, or pagers, or unit tests. Mostly what’s up here is blocks – lots and lots of blocks, with lines running to and fro.

What architects do with blocks is move them around furiously – a process that others might call “making decisions”. For example, how does this block talk to this other block? How can I organize my blocks? Should I make new blocks, or try to increase the abilities of my existing blocks?

Central to all of this is the ability to quickly and accurately visualize the consequences of decisions – which is why the primary enemy of architectural decision-making seems to be overload. When there are too many parts, when changing something has too many implications, or when there are difficult tradeoffs to be managed, it’s possible to lose the ability to make architectural decisions with confidence.

In particular, when systems are poorly abstracted, we tend to pay attention to the details (because we have to), leading to increased cognitive complexity. This manifests itself in slower and more difficult decisions, as things just don’t “feel right” with the system.

Here’s this crazy thing – the way you simplify an architecture is to add more things… but better things. Add layers with well-defined interfaces. Make rules. Group small things into bigger things. When at the point of overwhelm, instead of trying to solve the problem at hand, it may be worthwhile to step back and work on your mental model.

While sometimes you can get rid of things, in my experience, a lot of project requirements are handed down from “on high”. At best, you can try to make a case for getting rid of old, crufty things – which is why I’m always asking my cofounder if we can kill this feature or that. (I’m sorry, Astrid users, it’s true)

At the end of the day, as an architect, your job is to make decisions and produce blueprints that others (or yourself) can work with. Make better decisions by creating better abstractions – zoom in when you need to, but always keep the big picture in mind.

Need a hand? Some patterns that help simplify things include MVC, dependency injection or service locator pattern, and facade pattern. Design patterns, good times.

For the past several weeks, I’ve been experimenting with theming days. I first learned about the practice while following the Seattle Seahawks and hearing about days like “Competition Wednesday”, “Review Saturday”, and “No Repeat Friday” (where players strive to make sure they don’t have to practice anything twice – read more about the practices). Longtime readers know that I’ve been a Pete Carroll fan for a while, and this has been one of the most practical things I’ve learned from Coach Pete.

As I’ve brought the idea of themed days into my life, I can name several reasons why I’ve come to love them:

• Focus: let’s face it – there’s more than one thing that’s important in life. Whether it’s family, work, chores, hobbies, or learning, most everyone has a few things going on simultaneously. Having themed days makes sure that you spend at least 14% of your time focused on the areas that you want to get better in.
• Defining Success: what makes a day successful? For me, it’s when I get a lot done. Having themed days, though, lets me derive joy from improving on the other aspects of my life, including writing, relationships, and managing my team.
• Easy to Remember: everyone knows that they’re supposed to balance work, life, fitness, spirituality, and all of that good stuff, but it’s hard to follow through. In contrast, it’s so easy to remember to make themed days happen. If habits need regularity to be formed, and they probably do, themed days provide a weekly rhythm that allows change to occur.

Not convinced yet? Let me share about each of the days that I’ve instituted, and why I appreciate each of them.
Read more…

Rails Single Table Inheritance is a powerful concept where a single database table can contain various subclasses of a parent class, distinguished by a type column. For example, you can have a Cat and Dog model descend from Animal, each having their own methods or inheriting from the parent. In the database, the type field will be either “Cat” or “Dog”, and when you use query methods such as Animal#where, the models that are returned will be instances of the appropriate subclass.

STI allows your code to be much cleaner, removes those nasty case statements (see below), and gives you logical groupings for related functionality. As our code base has grown, and functionality is repurposed or expanded, I have since found myself refactoring classes to split them into subclasses as appropriate.

For example, Astrid used to only support premium accounts via Recurly. When we added the ability to perform in-app purchasing through various app stores, we ended up adding methods like “verify_android_token” and “verify_apple_token” to the PremiumAccount class. Even worse, when we had to write common functionality like a cancel method, it would look something like this:
Read more…