Category Archives: productivity

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.)

Figuring out how my temporary sleep schedule interacts with programming, writing, and drawing

I was thinking about how I can use these snippets of time to improve in programming, writing, and drawing. I realized that although I can easily imagine how other people can write or draw using fragmented time (writers scribbling in notebooks on top of washing machines, artists doodling on the subway), programming seems a lot less tractable. It doesn’t feel like you can break it up and squeeze it into different parts of your day as much.

It is generally accepted that context switching is evil when it comes to programming. So I’ve been carrying around this idea that Real Programmers are people who can pull all-nighters hacking on tough problems, holding elaborate structures in their heads. Your standard hero programmer stereotype, with the pinnacle being someone either building complex, cool stuff, possibly maintaining large and useful open source software.

Hence this little mental disconnect. I’m pretty certain I can get there someday if I really want to, but probably not if I extrapolate from current circumstances. Even maintaining a tiny piece of software sounds like more commitment than I want at the moment. (Heck, I might go a few weeks without responding to e-mail.)

Fortunately, I spent my first few working years in a corporate environment, where mentors showed me that it’s totally possible to be an Awesome Geek while still working a roughly 9-to-5 job, having families and hobbies, and getting plenty of sleep. Thank goodness. So I have this alternate model in my head, not of a Hero Programmer, but rather of solid contributors who keep making gradual progress, help teams of people become more productive, and who enjoy solving interesting challenges and expanding their skills.

So let’s say that I want to play with my assumption that programming is the sort of thing that’s hard to squeeze into the nooks and crannies of one’s day, at least not the way writing and drawing can. I know that I can go through technical documentation and design resources even if my mind isn’t completely awake, and I can still pick up useful things.

What is it about writing and drawing that make them suitable even in small doses, and how can I tweak programming? Writers can think about stuff during other activities. I can reflect on ideas while walking or cooking, for example. When I program, I still need more of that back-and-forth with a computer and an Internet connection, but maybe I’ll need less of that as I develop more experience. I can set pen to paper during any spare moment, sketching a quick line and seeing where it takes me from there. I might not be able to do that with implementation, but I can use that same playfulness to explore design. Behavior-driven development makes it easier to break projects down into tiny, clear steps, and have a way of verifying progress (without too much backsliding!). Getting deeper into frameworks and tools will help me do more with less effort when I do sit down at a computer.

Okay. I can do this. Worst-case scenario, I just move slowly until I get past this particular phase. I’ve seen role models who’ve pulled that off well, so that’s totally cool. Best-case scenario, I figure out how to hack around some of my current cognitive limitations, and maybe that might help other people who find themselves in the same situation too.

This could work.

Figuring out how to deal with sub-optimal times

There are days when I’m at the top of my game. It’s easy to think, learn, write, draw, code, be present. Somehow, time stretches to accommodate the different things I want to do. Those are good days. I have them frequently enough so that my optimistic brain considers this the default, although there are also Really Good days when things totally rock.

Then there are times when I feel fuzzy or blah or frazzled or stressed. I guess you could call them sub-optimal, although sub-optimal is a funny word because there’s so much space below “optimal” that you’d spend practically all of your time in sub-optimal zone. Anyway.

I was thinking about the different variants of fuzziness, frazzledness, and such things. When you’re feeling out of it, sometimes you don’t have the ability (or inclination) to pin down exactly why you feel out of it and what you can do about that – either to help you recharge, or to at least mitigate the downsides of being down. It makes sense to come up with some ways to recognize and work around your brain state.

2014-09-04 Suboptimal Sacha

2014-09-04 Suboptimal Sacha

Here’s a quick list of sub-optimal states I sometimes find myself in:

  • Sleepy: Pretty straightforward. Tends to happen if I get less than 8 hours of sleep (probably even anything less than 8.3), or if my sleep is messed up by interruptions, buzzing brains, etc. Manifests itself as slowness, tiredness, yawns. The fix is easy: take it easy, nap, or go to sleep earlier.
  • Sick: The occasional cold makes me feel all blah and fuzzy. Hard to think creatively during these times. Good time to sleep or play video games.
  • Stretched: This happens when I’m trying to pay attention to too many projects or open loops. I feel a little frazzled around the edges. I can generally deal with this by writing down all the tasks into Org Mode and scheduling them appropriately, but sometimes I still get stressed around calendar events or multiple places to check.
  • Buzzy: When my mind skitters to and fro, usually because it’s been overstimulated by computers or video games. Hard to focus. Can be addressed by walks or sleeping. Can be minimized by not using computers late at night, and not trying to multitask important things during meetings.
  • Fuzzy: Hard to focus, but in a different way from buzziness. When I feel fuzzy, my thoughts feel slow and it’s hard to grab onto something. It’s a good time to do straightforward tasks that don’t require much thinking, like accounting. I can also break down creative tasks into smaller less-creative pieces, so I can still get small chunks of writing or drawing done even when my brain is tired.
  • Speeding: Sometimes I overlook details or things I need to do. When we catch that, it’s a good time to slow down and ask people to doublecheck my work. Related to buzziness and feeling stretched. Checklists, processes, and automation help a lot.
  • Absent-minded: Sometimes I’ll blank out when it comes to where I’ve put something or what I was about to do because I wasn’t paying enough attention. Related to fuzziness. Habits, reminders, and lists help; also, W- helps me remember or find things.
  • Anxious: Generally around being late, messing up, or forgetting important things. When I’m awake and reasonable, I know that the world tends to keep on going and that people adjust, but early meetings still disproportionately interfere with sleep. I can calm down my lizard brain when I’m awake enough to do it. Sleeping is easier with backup alarms and wake-up reminders.
  • Annoyed/frustrated: When things are more limited than I hoped they’d be, or I have to figure out complicated workarounds. Can handle this by dissociating emotion from dealing with things like Internet Explorer. Also, taking plenty of notes helps, since I can avoid having to re-solve the problem in the future. If I can share my notes, all the better.
  • Embarrassed: Sometimes I mess up, and sometimes programming/automation helps me mess up on a grand scale. Whoops. Somewhat mitigated if I focus on moving forward and fixing multiple gaps. Having team members provide air cover helps a lot too.

I’d been feeling a little bit stretched lately. When I recognized that, I made lots of lists of ongoing tasks and open loops. That helped a lot. =) I feel a little bit fuzzy in the evenings, but certain kinds of drawing and writing actually help with that instead of making it worse. Hmm…

Don’t worry about your tools in the beginning: Avoiding premature optimization

“What tools should I buy?” “What platform do I start with?” “What’s the best option out there?” Geeks have a special case of analysis paralysis at the beginning of things. We try to optimize that first step, and instead end up never getting started.

Here’s what I’m learning: In the beginning, you’re unlikely to be able to appreciate the sophisticated differences between tools. Don’t bother spending hours or days or weeks picking the perfect tool for you. Sure, you can do a little bit of research, but then pick one and learn with that first. If you run into the limits, that’s when you can think about upgrading.

Start with something simple and inexpensive (or even free). If you wear it out or if you run into things you just can’t do with it and that are worth the additional expense, then decide if you want to get something better. I do this with:

  • Food: We start with inexpensive ingredients and work our way up as necessary.
  • Shoes: Upgraded from cheap to medium.
  • Bicycles: Still on the first bicycle I bought in Canada, since it was enough for me.
  • Ukeleles: Glad I just bought the basic one, since it turns out it’s not quite my thing.
  • Knives: Okay, we splurged on this one and started with good knives, since I piggybacked off W-‘s experience and recommendations.
  • Drawing: I tried the Nintendo DS before upgrading to a tablet and then to a tablet PC. For paper, I tried ordinary sketchbooks that cost $4.99 on sale, and have been happy with them so far – although I might downgrade to just having a binder of loose sheets.

Don’t worry about what the “best” is until you figure out what your actual needs are.

There are situations in which the cheapest or the simplest might not be the best place to start. You can easily get frustrated if something is not well-designed, and some inferior tools like dull kitchen knives are dangerous. That’s a sign that you’ve run into your choice’s limits and can therefore upgrade without worry. Yes, it might waste a little money and time, but you’ll probably waste even more time if you procrastinate choosing (more research! more!) and waste more money if you always buy things that have more capacity than you ultimately need. You can tweak how you make that initial decision–maybe always consider the second-from-the-bottom or something like that–but the important part is getting out there and learning.

Realistic expectations, ruthless elimination, and rapid exploration

“You’re pretty organized, right? Do you have a system for productivity that I could use?” someone said to me. She sounded frustrated by her lack of progress on some long-standing projects. I shrugged, unsure how to help.

I don’t consider myself super-productive. I am, however, less stressed than many people seem to be. I’ve been learning to keep realistic expectations, get rid of less-important tasks, and work in quick, small, useful chunks.

Realistic expectations: We tend to overestimate how much we can do, particularly if we’re looking a week or two ahead. Even if last week was derailed by interruptions, we hope next week will be a smooth ride. I’m guilty of this myself. I compensate by expecting little of myself – just one to three important tasks each day, moving forward a little bit at a time. If I find myself with spare time and motivation, I check my other tasks for something to work on. It’s okay if I end up procrastinating something. That usually means I spent the time on something I valued more.

Ruthless elimination: “But how do I motivate myself?” This is another thing that people often struggle with. I use different strategies depending on what I need. For example, I’m currently working on a project with a high risk of failure and a fair bit of work. For me, it helps to amplify the perceived benefits, downplay the small pieces of work that I need to do (it’s just a small task), and downplay the risks (failure isn’t all that bad). On some other projects, I might decide that my lack of motivation is a clue that I should just wrap up the project, get rid of specific tasks, delegate work, or transform those tasks into things I might enjoy more.

Rapid exploration: After I adjust for realistic expectations and get rid of tasks through ruthless elimination, I think of tiny tasks that will help me move towards my goals. That way, I can explore and get feedback faster. Then I try to get as much value as I can from those steps, usually ending up with blog post ideas and lessons learned in addition to the thing itself. This also means that I can squeeze work into 15- to 2-hour chunks instead of waiting for a 4-hour span of uninterrupted, energetic time.

There are a bunch of other things that help me out (keeping outlines of projects and tasks in Org Mode, documenting as much as I can, knowing my tools well), but those three behaviours above seem to be different from the way many people around me work. Hope that helps!

Three productivity tools

Kosio Angelov asked: “If you could use only three productivity tools for the rest of your life, which three would you choose?”

2014-05-14 Which three productivity tools would I use if I could use only those for the rest of my life #emacs #productivity

2014-05-14 Which three productivity tools would I use if I could use only those for the rest of my life #emacs #productivity

I’m totally cheating with my answers. I can’t imagine using only three tools. What counts as a tool, anyway? Is the Internet a tool? What about the scientific method? Are we talking about apps, applications, platforms, systems, frameworks? =) Anyway, these are the answers that came to mind. They’re not your usual suspects, but I’ll explain why I like them a lot.

Emacs: This arcane text editor from the 1970s is capable of far more than most people think it can. It’s not an application, it’s a platform. I use it to code, write, plan, connect, automate, calculate, and so on. People get intimidated by its learning curve, but for me, it’s well worth it. I’ve been learning and blogging about it for more than ten years. Based on what I’ve seen, I could probably keep going for decades. I love the way you can dig into how things work, tinker with the code to make it fit what you want, and combine different packages. Great user community, too.

I’m not sure what to say to productivity newbies considering Emacs. It takes a certain kind of person, I think. If you’re someone who likes constantly learning and tweaking, you’re good at learning from what other people have written, and you’re not afraid to do a little worse in order to do even better in the future, this might be for you. You don’t have to be a programming geek, although it helps.

Linux: Again, I’m cheating by including an entire operating system, and probably I mean all the little tools I’ve gotten used to rather than the operating system itself. But I love being able to use utilities like grep and find (thanks, GNU!), stitching programs together, scripting things, installing other tools… People have suggested that I look into Mac OS X, but it gets a little on my nerves. I like Linux more. There are some programs I want to run on Windows, though, so I end up using Linux in a virtual machine so that I can do my development in a proper environment.

Ruby:  I use Ruby for little automated scripts as well as special-purpose web-based tools like QuantifiedAwesome.com, which helps me track my time. It feels like the way my mind works. I used to use Perl for scripting and I’m learning Python, but Ruby has the least friction for me. This may change as I get deeper into other languages, but in the meantime, Ruby is a good language for the kinds of things I want to do.

—-

All of these tools take effort to learn. They’re not like, say, Boomerang for Gmail or ScheduleOnce, which are easy to pick up and have clear benefits. My favourite tools require imagination, but they open up infinite possibilities. I’m not locked into one way of doing things. I still have limits, but they’re the limits of my own ideas and skills. I think that’s what I like about these tools. They have depth. Whenever I reach for some new capability, I almost always find it.

So, if you’re a newbie and this sounds intriguing, how do you get from point A to point B?

I think I got here by being interested in learning, being unafraid of tinkering, and having the space to do both. When you’re learning a complex thing, you might feel frustrated and intimidated by it. Good games design that learning experience so that people enjoy small wins as they develop their skills, but not all topics are like that. Sometimes you have to enjoy the learning for its own sake.

… which is an odd message to share with people who are looking for productivity hacks, maybe, but it’s something I’ve been thinking about lately. There’s a cost to picking general-purpose tools that are perhaps not the best at one specific thing, but experience results in compounding benefits. There’s a cost to keeping both your schedule and your eyes open, but perhaps it can lead to surprising things. There’s a cost to choosing the path of learning rather than the quick fix, but who knows what the true cost is down the road?