“There’re all kinds of people in this world. But they break down into two main groups, one big and one smaller. There’s the people who get moved out of the way or into line, and then there’s the people who do the moving. It’s safer and a lot more comfortable to go where you’re pushed. You con’t take any of the responsibility, and if you do what you’re told , every once in a while you get thrown a fish. Being a mover isn’t safe, because you may be headed for a hole, and it isn’t comfortable because you do a lot of jostling back and forth, and what’s more, it’s up to you to find your own fish. But it’s a hell of a lot of fun.”
Algis Burdys / Rogue Moon
One of my favourite parts of telling people my side projects is watching their face light up when they really get it. If you can do it in the first five seconds, you’ve figured out a way to tell the story.
I don’t know about you, but I’m not a natural storyteller. I have to practice and hone a story until I have a good way to tell it.
So you throw the explanation against one person. Then another. Another. You note down when they start to really understand what you’re talking about. More often than not, I bury the lead so hard that the first few people I talk to are only listening out of politeness.
It’s not just about getting the story down smooth. You have to mix it up and see if you can grab attention earlier. You have to find out the hook and move it up front.
Eventually you have a real pitch. You never really stop fine tuning it, but you’ve got something worth telling.
Last night I was at the Victoria Startup Meetup. There was a panel discussion about growing your company. One of the presenters pointed out that the most important thing to help educate customers was to introduce them to specific examples, right out of the gate.
My partner was an English major in University. He’s done plenty of analysis of specific pieces of work. Whenever we talk about them, he gets frustrated, because I tend to look at specific examples and try to extrapolate the general concept.
Generalizations help experts solve problems.
My first instinct in writing marketing copy is to go general. I know all the use cases, and I’ll try to write something that fits them all. Instead, to get good marketing copy, I try to fight the urge to generalize and focus on the specifics.
Specifics help people understand.
This popped up in my feed today: Pixate.
It’s a cross between a motion design tool and an interaction design tool. You should check out the video. It looks excellent, and I can’t wait to give it a try.
We desperately need as many good motion design tools as we can get. The amount of designers I deal with who still think in terms of static screens is staggering.
Sometimes I worry about the level of completion that I’m willing to take before shipping.
On one hand, clients tell me that they love the sense of taste and little details that I bring to a project, but on the other hand I’m always convinced that I’m shipping too early. That’s not just programmer paranoia either. We’ve lost clients before by sending a beta that didn’t measure up. I’m not proud of that, but it’s led us to better ways of testing and of communicating, so I’m not torn up about it either.
Once, six or seven years ago, I had a customer berate me for shipping beta quality software. It was on the release of a 2.0, and I had a 2.0.1 out the next day for him, but I still feel disappointed in myself for letting that get by me. Every other email I got on that release raved about the new features, but the one I really remember was the humiliating one.
Developers are great at ensuring code quality, but often we fall down on product quality. Beta groups, integration testing, PM feedback, all that can only get you so far. Eventually someone tries something you didn’t see, and now you’ve lost a customer.
I’m sure if I got a better business person in here, we’d talk about the cost tradeoff of quality control vs. keeping a customer. But that doesn’t sit well with me. I want to make amazing software, and too often I have to settle on good enough.
How do you measure that software is complete? I feel like we need a role in the organization that’s just ‘software critic’. Someone who doesn’t give a damn about what tradeoffs had to be made and where the budget was set. If we can frustrate that person, then maybe it’s ready to ship.
How do you measure that software is complete?
When you’re a developer, you think of software in terms of features. The app does this, that, and the other thing. It’s pretty easy to talk about what’s in the app, you just use enough bullet points.
Where I run into trouble is writing marketing copy. It’s not just about listing features. Instead it’s about creating a compelling narrative about why my product will make your life so much better that you’ll pay for it.
You have to bring an incredibly different sentiment when writing marketing materials. I wish I was better at it.
Our goal was to finish cleaning the old apartment today. Then tomorrow we could just show up, hand over the keys, and go find brunch.
Of course that didn’t happen. There’s still one more load of stuff to bring over and a couple floors to mop. It’s not much, but it’s the difference between ‘incomplete’ and ‘done’. Luckily, by which I mean intentionally, we set a deadline before the real deadline. It forced us to make better plans, and more importantly, it lets us have a bit of buffer for when plans inevitably fall through.
I’ve worked on lots of things that came in on schedule. I don’t think I’ve ever worked on a project that didn’t use buffer time. Work expand to fill the time available – plus a bit longer while you put the finishing touches down. I think it’s critical to include some extra time in every project.
This morning I picked up a UHaul van for our move to the new apartment. It’s college-moving weekend, so we had a narrow window to use the loading dock. That meant that everything else had to go right. We had plenty of helpers lined up, we had the loading zone at the old apartment booked all morning, and everything was ready to go.
When I got to the UHaul place at 7:05, the manager was already on the phone with someone. He was explaining that they needed to return their truck *now*. Someone had it booked in a couple hours, and the previous booking had failed to return it the night before. I couldn’t hear the other end of the conversation, but it seemed like the person was befuddled that they couldn’t just hang onto the truck until they were done.
The manager explained that they were ruining someone else’s move, and asked when they’d have the truck in. The look on his face said he wasn’t happy with the answer.
He helped me afterwards, but his mind was somewhere else. He was going to have to call the people who booked that truck today and explain that they didn’t have one for them.
I wonder how many times a year he has to make that call.
I ran into an interesting problem today while trying to write some unit tests for an SDK we’re helping to build at work. It involved instantiating a third-party library, then running a few tests to be sure that our delegate code was being called as expected.
The problem is that the third party library contained code to instantiate a UIWebView. At first I was puzzled. That couldn’t be causing a crash. I ended up stripping out the actual test and just putting in a line like this:
UIWebView *wv = [[UIWebView alloc] init];
And an exception was thrown.
After Googling around for a while, I came across a Stack Overflow post discussing the behaviour. It looks like when you’re trying to test UIWebView in a static library, it needs an app target set to run. I created an empty app, set it as the target, and boom, we had a working unit test.
It’s the things like this that make me realize that I’ll never be done learning.