Better Communication: Annotating your screenshots

Written by on

We spend a lot of time talking about communication. And I mean, A LOT.

Here's why: Not a single person on our team works together, physically, in the same office.

We have a virtual office. When you combine HipChat and Basecamp, throw in some Google Hangouts, sprinkle some Skype, and tie it all together with text messages, emails, and telephones, what do you get? Our virtual office.

This is part one of a series of posts on how we communicate better everyday. We spend a lot of time looking back, deciding what's working and what isn't. Everyone chimes in. It's so crazy we even talk about how to use HipChat. It's all for a good cause though: the quest for better communication.

Communicating around a project is hard. Like I mentioned above, we're a remote team. Our clients are remote as well. We're hardly ever in the same office with them. Over the course of a few years, we've realized this:

Words alone usually suck

We use words a lot. However, oftentimes we're talking about something we're building. We're talking about a particular user experience or front-end, what the client is ultimately paying us for.

They don't care much about the backend. They trust our judgement - that's what they've hired us for. However, they do care about what they see, feel, and touch. Seeing tangible things makes them happy. It makes us happy too.

This is how we make it work. And, this is what you should be doing if your clients can't see you every day. 37signals mentions this in their latest book, Remote: Office Not Required.

Show them work often. This is the best way to chip away at a client's natural situational anxiety. Look, they're paying you big bucks for your work, and it's totally natural for them to begin feeling anxious the moment they send you the deposit. Show them what they're paying for. When they see the results of your efforts, they'll feel a lot better about the relationship.

Here's what we're trying to do about it

In an effort to get better at showing our work, we've started to annotate screenshots. Here's an example.

Selection_385.png

Take a screenshot. If you're using a tool with the capability, you can annotate, highlight certain parts of the shot, and point to things you're seeing. This gives you a reference point for things you want to discuss.

Nothing is more frustrating than having a conversation about something you can't see. Sometimes, it works, but most of the time you need a visual aid. Remember Speech 101?

Don't worry about being perfect. You aren't sharing your screenshot with millions of people. It just needs to be good enough. Does it help you solve the problem you're pointing out? If it does, you're doing a good job.

When you need something more than a screenshot, screen recordings give you added benefit. If you're using OS X, you can easily use Quicktime to start a screen recording (they're using screenshots with annotations, too!). You can even use your voice to annotate what you're seeing along the way.

We've found screenshots with annotations to be a successful experiment. I hope you try it out if you haven't already.

Looking for the tools to download so you can get started annotating your screenshots, here you go:

Podcast Episode 17: That moment is given to you by the lack of gravity

Written by on

Late last year, I decided I wanted to talk with someone who had gone though what might be the most unique human experience possible, someone who has been into outer space.

Fast forward to today where I was able to interview Astronaut Clayton Anderson, thanks to Source Sleuth - a service that finds experts for people telling stories.

Clayton and I talked about what it felt like to ride a rocket ship into outer space, the 15 year path he took to get there (including 14 years worth of rejection letters), the 5 months he spent on the international space station, how this perspective shapes ones worldview and what he's doing now as an author and public speaker.

I'm very grateful for the time Clayton gave to speak with me, and inspired by hearing his story of determination.

You can keep up with Clayton by following him on twitter at @astro_clay, checking out his facebook page at http://facebook.com/astroclay, and visiting his website at http://astroclay.com.

Listen to the show below, or subscribe to our podcast in iTunes.

The right way to think about TDD

Written by on

I've been noticing quite a few posts in the developer community about ways to write better code. In particular, the Code Climate blog has been inspiring. A few days ago, Justin Searls inspired me further with his outstanding post about teaching TDD.

The reason Justin's post resonated with me so much was its relevancy. Just a few days earlier, I had exchanged comments with Bryan from Code Climate about the same thing.

Last week, Bruno (an engineer on our team) and I were talking about the community and the themes you extract from paying attention to the conversation within it. If you're a bystander, you'd probably notice the following rather easily:

If you're not following TDD, you're doing it wrong.

People preach TDD as gospel. It's overwhelming at times.

It's so overwhelming that you can wrongly interpret it. A beginner might think they have to do it all the time to learn programming. Nothing could be further from the truth. When you're first starting out, you're just trying to get things to work. Why should we encourage people to stumble through something that doesn't really help them do that?

The same thing is true for senior developers. If you don't practice TDD, you somehow have a letter tattooed on your chest that labels your code as buggy and awful.

What is our goal as software developers? I hope it's not to have the best test suite. You don't get a special medal for that, and it certainly doesn't imply you've designed and maintained a great code base. If I had a choice between a test suite with 100% coverage or a well-designed code base, I'd choose the latter every time. I can quickly write some high level tests to help me make future changes, but it would take me at least a month to undo years of bad design.

This certainly doesn't mean I don't see the value in testing. I'm simply trying to jump on the bandwagon with these guys - testing needs to be in a different part of the conversation, not at the forefront.

That being said, I've noticed a subset of the community changing the topic of the conversation. No longer is it TDD first. Instead, it's design first. It's writing the code you wish you had. If you design first, nice tests usually follow if you know what you're doing. If you're having trouble writing tests (using too many factories, slow running tests), it's an indication you have poor design.

TDD alone won't save you from violations of the single responsibility principle. It won't save you from poor design choices, and it certainly won't save you from costly refactors. With a little work, I can achieve 100% test coverage and end up with a code base that's messy and not maintainable.

It's bandwagon time. TDD isn't the only way. Don't follow TDD blindly.

Our goal should be writing amazing code. You should feel good about it. Things like the single responsibility principle, the open closed principle, and law of demeter are what you should be studying and applying to your work.

If you're writing code that follows these principles, it's mostly simple. Your classes are responsible for one thing. Your churn is low (your classes don't change often). You don't care much about the rest of the domain (your classes care about themselves). Most of your classes are easy to understand and you can re-use them with ease (they're loosely coupled).

Simply following TDD doesn't give you the beauty of great design. It puts a band-aid on the issue.

Here's how we've been operating as a team.

We don't always write tests first because you don't know what you don't know. The goal is to get nicely written, working code and NOT perfect tests and a badge that says you followed TDD.

We do think about testing as we're designing. If we're creating a new class, a spec file is sure to follow.

We focus on great naming and try to use namespacing. Being able to come up with a good name is a sign you've broken down the problem enough. For example, if we wanted to create a class to notify us about comments on this blog, we'd use "Blog::CommentNotifiers::Email" which would notify us by email. It's simple and it will end up doing one thing: sending an email when a new comment is posted on the blog. Using a callback on the "Comment" model would be a poor design decision and require you to opt-out of the behavior whenever you don't need it.

We focus on unit tests. If we have to stub out all kinds of classes and methods (more than 10 or so), we treat it as a code smell and think about refactoring.

We've learned a lot in the past year about writing better code. When we have to write new code, we write code we wish we had. We don't look for the quickest way to fix the problem (although there are always exceptions). We focus on very clear class names and private methods that read in plain-English. We try to avoid obscure method names. We focus on low-level implementation details last - once we have the design complete.

I highly, highly recommended the following resources to assist you in writing better code:

Bootstrapping is thinking long, not small

Written by on

Adrian Holovaty, the founder of Everyblock and one of the creators of Django, put up the notes for a talk he gave about how Chicago needs to stop playing by Silicon Valley's rules.

His points are extraordinarily well articulated and he outlines the case for why the Chicago tech community should brand itself as the city for bootstrappers. 

I wanted to just stand up an shout out loud 'THANK YOU THANK YOU THANK YOU' as I read his write up.

I loved just about everything he wrote and a lot of it reminded me of the commentary I had on past hack job press coverage of the Chicago tech scene.

But there's one particularly disturbing thing I noticed happening in conversations after his talk - which is that some people equate bootstrapping to 'thinking small'.

And in fact - bootstrappers often seem to give in and accept the meme that bootstrapping equates to thinking small.

 

But this is wrong.

Bootstrappers don't think small, we think long. 

This is an important distinction because thinking small implies that you've set limits on your growth and the impact you want to have. I know a lot of bootstrappers, but I know of none who want fewer customers or who care any less about wanting to make their dent in the world.

What we do care about however is how we get those customers, who we have to partner with on our way to acquiring these customers and what kind of day to day existence we have as we build our companies.

This is thinking long, it's not thinking small.

When you start having a time horizon for success that spans 15 or 20 years, you look at the world and the opportunities it presents differently.

You know that in order to be strong you need deep roots, which are unsexy and usually go unnoticed and unappreciated until they finally take hold when suddenly everyone recognizes your 10 year overnight success.

It's silly to accept the notion that bootstrapping is thinking small, especially when the very people who claim that it is are building their products with a framework created by bootstrappers (Rails or Django, take your pick) and committing their code into a central repository created by bootstrappers (GitHub).

Bootstrapping definitely isn't easy, it certainly doesn't hockey-stick and it probably won't save an otherwise worthless portfolio of investment assets.

But to call it small is to misunderstand the very mindset of the bootstrapper.

We think long, not small.

Episode 16: The delusion is that you need a hockey stick to succeed

Written by on

I was joined by Kevin Finn of Molehill in our latest podcast episode, where we talked at length about how they built their time tracking tool Tick - which also happens to be one of my favorite SaaS products - and their podcasting app Buzzsprout.

I was particularly happy to talk with Kevin because Tick is something I look at and think to myself - this piece of software makes my business better.

Kevin shares some of his insights about making useful products, marketing and the things that make us happy.

Listen below or subscribe to the podcast in iTunes.