Sketched Book: Just F*cking Ship – Amy Hoy, Alex Hillman

Amy Hoy and Alex Hillman wrote, published, and launched Just Fucking Ship in 24 hours, using a Trello board and an outline to quickly whip up this short reminder to stop procrastinating and get something out the door. They’re halfway through editing it and will post updates through Gumroad, so if you buy the book, you can watch it evolve.

I’ve sketched the key points of the book below to make it easier to remember and share. Click on the image to view or download a high-resolution version that you can print or reuse.

2014-12-12 Sketched Book - Just Fucking Ship - Amy Hoy and Alex Hillman

The principle I’m focusing on is #7: Start with atoms. I’m comfortable with making small pieces now: an outline, a blog post, a sketch. I’m working on getting better at assembling those pieces into molecules, and eventually I’ll be able to turn those molecules into rocketships. Eventually. But in the meantime, I can push more things out there.

I’ve been sorting out my EPUB/MOBI workflow by putting stuff up on Gumroad, like the Emacs Chat transcript collection. (Incomplete, but that’s what updates are for.) This will help me Ship More Stuff.

Today I noticed an opportunity for wordplay. The domain was available, so I jumped on it. Shipped.

Ship. Get your stuff out there, incomplete and in progress, because you’ll learn more from the feedback than you will from stewing on it by yourself. And if it flops? Don’t worry. You’ll do another one, and another one, and another one, and you’ll learn.

Want the e-book? You can buy it at Just Fucking Ship (Amy Hoy, Alex Hillman; 2004). You’ll get a PDF and updates. (Amusingly, no physical shipping involved.)

Like this sketch? Check out sketchedbooks.com for more. For your convenience, this post can be found at sketchedbooks.com/jfs. Feel free to share – it’s under the Creative Commons Attribution License, like the rest of my blog.

(Incidentally, I’ve quoted Amy Hoy before – see my post on Learning slack for another reflection on writing, productivity, and motivation.)

Building a better time machine

I’ve written before about how a blog is like a time machine, reflecting on my growth as a speaker or looking back over the past decade. It’s wonderful having all these notes. I often find myself referring to things from years ago – many of the technical posts are still useful, surprisingly – and then I bump into other memories nearby.

What can I do now to build a better time machine for me to use in another ten years or more? How can I tweak what I’m sharing and how I’m sharing it so that I can make the most of it? Let me think about how this has worked in the past, so that I can build on what’s been working well.

People like the tech posts, the workflow posts, the reflection posts where they recognize something they’ve been thinking about themselves. So those are all good. I also like point-in-time descriptions to help me remember what it was like. Maybe I’ll take those process journal entries and copy them in periodically so that they’re available somewhere.

I wonder: what other people have learned about writing for their futures? Here’s a snippet from Louise DeSalvo’s The Art of Slow Writing (2014):

p98. In her essay “On Keeping a Notebook”, [Joan] Didion describes what her notebook isn’t. It isn’t “an accurate factual record” because our recollection of an event might be vastly different from someone else’.s It isn’t to “dutifully record a day’s events” because that task inevitably becomes boring, and such a record conveys little or no meaning. Nor should we necessarily expect that we might one day open our notebooks and find “a forgotten account” of an event we can pluck for our work.

Instead, Didion believes that the notebook’s value lies in its record of “How it felt to be me” at a particular time. This, she says, is the notebook’s truth. Although we might imagine using it to fix our impressions of others, instead, “Remember what it was to be me: that is always the point” of the notebook. Part of a writer’s education is “to keep on noding terms with the people we used to be, whether we find them attractive company or not.” Reading our notebooks helps us to keep in touch with those past selves, and a record of “How it felt to be me” can be extraordinarily useful in writing memoir, creating fictional characacters, or writing poetry.

p100. Didion remarks on the fact that we change over time but that we forget the people we were: “I have already lost touch with a couple of people I used to be,” she says. Without a notebook record, these selves are lost to us. For a writer, “keeping in touch” with our past selves is helpful. … As Didion reminds us, “We forget all too soon the things we thought we could never forget.”

So, maybe the occasional snapshot of “How it felt to be me,” a way to remember that there are selves to remember. Otherwise the time blurs.

From that essay of Joan Didion:

Keepers of private notebooks are a different breed altogether, lonely and resistant rearrangers of things, anxious malcontents, children afflicted apparently at birth with some presentiment of loss.

I think that might be part of it, a little bit of that worry (not a lot, but it’s there, lurking in the background) that I might forget (no, will!) large chunks of my life, because even last month is a little fuzzy without notes and last year gets condensed into a few highlights. But no, that isn’t quite it either, since I don’t really hang on to the memories tightly even with my notes and my archive; I don’t reread, I don’t memorize.

Ah. I think this is it: my blog lets my past selves connect with other people who are looking for this stuff here and now (or in the future, as the case may be). So even if I am a different self–focused on other projects, learning about other interests–those past selves are there to nod at other people and share a little of what we’ve learned along the way. Mostly I leave things as snippets and blog posts, but on occasion, I consolidate things into summaries and documents – a clearer guide, a past self updated with a little present knowledge.

Hmm…

Where am I in terms of design?

I’m working on learning more about design. I don’t think about it all the time, but sometimes I check out design blogs like Little Big Details and CSS Tricks. I’m getting the hang of sketching several variants instead of jumping straight into the first idea I have, and sometimes I even show those wireframes to other people before coding it up.

Someone asked me where I’d rate myself on a scale of 1 to 10. It’s hard to do that without thinking about what 1 and 10 are and what’s in the middle. Besides, I know that the scale will keep shifting anyway. I’ll never ever get to 10, and this is good. There’s always more to learn.

Anyway, here’s what I came up with. Which, on reflection, might be overstating it. Sometimes I feel like I’m still throwing everything in including the kitchen sink. But at least this gives me a map, a You Are Here, and more usefully, a sense of what the next step on the path might be.

2014-11-29 Where am I in terms of design

There are at least three components to this, I think. TECHNICAL SKILLS–the CSS and Javascript, the code and the fiddly bits–that’s actually the smallest part, and probably the easiest. I’m not too worried about that. I can learn it when I need to, following the tutorials that other people have written. For the few things that aren’t covered by Javascript polyfills and StackOverflow answers, I can use trial-and-error to bodge my way through (at least until I understand things better).

DESIGN SENSE–now that’s tough. I can read all the usability books I want. I can study the key principles of visual hierarchy or grouping. I can take a master’s degree in human-computer interaction. (Wait, I did!) I know I’m supposed to keep the end users in mind, either by talking to people directly or by keeping personas in front of me. I know I’m supposed to keep things simple and discoverable, with affordances that encourage you to use things in the right way.

I can mostly find my way down well-worn roads. (Want a real-time status update visualization? A mosaic of news items on the front page? A multiple choice survey? Gotcha.) I am often asked to come up with something new, though. Sometimes it’s just new to the group, so we figure out what people want after a little back-and-forth. Sometimes it’s new to me, and I have to do some research. Sometimes, I suspect, I’m trying to come up with something a little new to everyone. Or at least it requires a lot more translation to find something familiar to draw on.

But there’s still so much more to learn before I can confidently sift through conflicting feedback, before I can guide people from vague ideas to that flash of recognition: “Ah, yes, this is what I wanted.”

I don’t know if it’s just a matter of experience. I’ve worked with designers on web projects and I’ve disagreed with them. (Gradients? Really? And you want that to do what?) I’ve also worked with designers I got along really well with, especially the ones who weren’t coming from a print background and who knew the difference between what looked flashy and what was easier to do on the Web.

So. Design sense. This is the part that intrigues me the most. I’m working on developing opinions. It’s not just about memorizing a bunch of principles or applying the latest fads (from skeumorphic to flat, from static to parallax, etc.). I think it involves being able to see, understand, and recommend. Browsing through design blogs doesn’t really help me with this. I have to slow down and think about why something works, why it doesn’t, what other variants I might try, why I like something or another. And then, beyond opinion, there’s also measurement: revealed preferences often go against what we think we want.

This is where WORKFLOW comes in. I’ve been working on resisting the temptation to jump in and start coding things right away. Instead, wireframing possible designs means I can play around with how something looks and behaves, changing it with less friction. (It also means I can turn ideas over to team members in case they want to use that for development practice.) Getting the hang of wireframing will also help me try different variations while being less invested in them.

Research can help me quickly find different types of the same idea, so I can broaden my horizons. For example, looking at a few support communities (Adobe, Apple, and Skype) gave me a better sense of what I liked about each of them and why.

My main challenges for design and workflow are:

  • How can I apply what I’m learning within the constraints that I have? For example, it’s one thing to know that testing is good. It’s another to think about how I might do A/B testing without proper analytics and without hundreds of thousands of views.
  • In the absence of stronger metrics, how can I work with conflicting feedback? Can I get better at generating different variants to help people find something they agree on? Can I get faster at working with low-fidelity prototypes or in-browser code?
  • How can I recognize familiar aspects in new ideas, and get better at cobbling together well-tested ideas from different places? Hmm. Come to think of it, it’s a little like those Master Builders in the LEGO Movie, isn’t it? There’s something about that ability to look at something and say, “Oh, that looks unfamiliar, but it’s really like A and B and C.” I do this kind of connecting-the-dots outside design. I can learn how to do it here too. (Analogies are another way to practise this. =) )

I’ll probably be able to get the hang of the tech along the way, so I’m not worried about it.

I think this will help me learn the kind of design I want. I’m not really interested in the kind of design that involves following fairly well-sorted out paths making snazzy websites for other people, like WordPress theme customization or development or things like that. I can pick that up if I need to, probably.

I’m more curious about getting better at designing new(ish) things, the kind where I can’t just pick a few sites for design inspiration, the kind where I’m making something I haven’t seen before and I have to decide what to show and how it behaves.

Oh! Here is another version of that sketch, in case you want to fill it in yourself. =)

2014-11-29 Where am I in terms of design - blank

Emacs: M-y as helm-show-kill-ring

After realizing that I barely scratched the surface of Helm’s awesomeness (really, I basically use it as an ido-vertical-mode), I made a concerted effort to explore more of the interesting things in the Helm toolkit. helm-show-kill-ring is one such thing. I’ve bound it to M-y, which I had previously configured to be browse-kill-ring, but helm-show-kill-ring is much cooler because it makes it easy to dynamically filter your kill ring. Also, Kcode>M-y works better for me than C-y does because I know when I want the last thing I killed, but going beyond that is a little annoying.

That said, browse-kill-ring does make it easy to edit a kill ring entry. Maybe I should learn how to modify Helm’s behaviour so that I can add an edit action. There’s already a delete action. Besides, I haven’t used that feature in browse-kill-ring yet, so I can probably get by even without it.

ido fans: you can use helm-show-kill-ring without activating helm-mode, if you want.

On a related note, I like how rebinding M-x (execute-extended-comand) to helm-M-x shows me keybindings as I search for commands. You do have to get used to the quirk of typing C-u and other prefixes after M-x instead of before, but I haven’t had a problem with this yet. This is mostly because I haven’t dug into just how many commands do awesome things when given a prefix argument. I know about using C-u C-c C-w (org-refile) to jump to places instead of refiling notes, but that’s about it. I haven’t gone anywhere close to C-u C-u. Does anyone have a favourite command they use that does really smart things when given that prefix? =)

This Helm intro has animated GIFs and a few other useful commands. Check it out!

Sketchnote Army Interview: Sacha Chua

Mauro Toselli sent me a few questions for the Sketchnote Army blog, which has been running a series on featured sketchnoters. Naturally, I decided to sketch my answers. ;)

2014-12-04 Sketchnote Army Interview - Sacha Chua

2014-12-04 Sketchnote Army Interview – Sacha Chua

If you’re curious, you can check out some of these relevant blog posts:

Emacs configuration and use-package

Watching the second Experimental Emacs Hangout nudged me to improve how I use use-package in my Emacs configuration.

I had been using use-package‘s :init and :config keywords as a more readable and less-error-prone versions of eval-after-load. (Well, technically, :init happens before it’s loaded, and :config is evaluated after it fully loads.) I also used :bind for global keybindings.

I didn’t know about :ensure and :diminish. Adding :ensure let me get rid of my custom sacha/package-install function, and :diminish let me remove a few lines related to my modeline.

One of the benefits of sharing my configuration is that other people pick up ideas, and then I pick up more ideas from their ideas. I get an excuse to revisit packages that may have added features since the last time I checked them out. I learn from other people’s combinations and customizations.

There’s so much to learn about Emacs, even just in terms of the packages that I’ve already configured. Sometimes I start with just the basics and settle into a routine, forgetting that there are even more things I can do. Sometimes people make incompatible changes, and I have to figure out how to adapt. Sometimes packages become unmaintained, and eventually replacements emerge. Always, always, people write more code, add more features, extend Emacs to do more things. It’s never just about what new things I can do. It’s also about this community of people who tickle their brains by building cool stuff, who follow “What if?” to interesting places.

Anyway. :ensure and :diminish, and a few improvements to my config. (Also because I just switched to the 64-bit binary for Emacs 24.4, how exciting…)

Hat-tip to @gozes for nudging me to write about this – back in April!