HACK / MAKE

One of my first major pieces on this site, published in February of 2012, compares and contrasts the trend of minimalism with what I was calling “active ownership”:

Active ownership, which differs from minimalism, is about investing your limited attention, money, space, and time to what you value so that those things will thrive. Being vested in something makes you care more about it. You can’t do or have everything, so when you choose to take active ownership, it becomes a commitment to it and decisions and compromises have to be made about what commands your limited attention. As a result of the explicit choice you make in how you spend your attention, you reduce the things around you to what’s most valuable. What’s not valuable gets cut from your attention budget.

When I wrote this, and for several years after, I was incredibly invested and active in Hack/Make. I was writing, editing, and building a community of friends around the work I was doing here. I practiced the process of writing, editing, and publishing while discovering a voice online. I made decisions and personal sacrifices so I could focus on writing for this site. It’s been a place for me to explore ideas, code, and a systematic thought process in a time when I was setting the building blocks in my adult life. I’m a much better of a person because I actively invested myself in that work.

But for more than a year, I’ve been struggling to stay passionate about Hack/Make.

When I look back through the archives, though I’m happy with the body of work as a whole, there isn’t a lot of individual pieces that I’m terribly proud of. Some of that is because I’ve matured as a writer and my old stuff reads as weak. But I also think it’s because I’ve matured as a person and the way I think about the topics I wrote about here has evolved. Many of these topics—task lists, scripting, tools—were the problems I found myself interested in at the time. Most no longer hold my interest since I’ve either figured out something that works for me or recognize the problem as unsolvable. By trying different productivity tools and systems, I’ve learned that less is more and that I enjoy life more when focusing on other things.

I’ve spent the last couple of years making friends, traveling, and falling in love. I see the beauty and hardship, the complexity and the honesty of the human world in these people and places. When I remember to stay in any given moment, I forget about being “productive”. I now embrace getting out from in front of the computer. I look forward to getting away from the safe feeling of methodologies and the comfort of routine: they served their purpose at the time, but often being comfortable for too long means you’re not growing. Ditching the constraints of all these systems means I get to explore the intricacies of being truly human.

To keep the site alive I’ve tried drafting posts about how the blog will evolve in nature as my interests have changed. I’ve tried updating the tagline of the site to set the course for a new vision that excited me and I’ve spent countless hours brainstorming ways to rename the site so I wasn’t disgusted by the word “hack”—which I’ve come to loath—every time I sit down to write. Through all this, I realized I’m just not excited about Hack/Make any more.

Passions change, focus shifts, and, sometimes, what once brought you joy no longer does. I was no longer taking active ownership in the site nor consistently reinvesting myself in it.

I closed that article, four years ago with this:

This process of actively owning, continuously editing what you do, and explicitly choosing what’s around you results in a deeper passion for those things and is worth investing in.

It’s time for me to make some edits. I’ve written about focus and attention and I need to spend mine elsewhere. I want to reset my writing practice and take time to collect ideas, write drafts, and hone the craft. I need to bring joy and humanity back into my writing and rediscover my passion for it.

Though it would be easiest to take it offline, I’m going to keep hackmake.org live. It’s still a good reference for myself and, hopefully, for others who want to learn about productivity methods. If you find this study to be bringing you energy, enjoyment, or help provide you some feeling of flow in your life, I encourage you to continue. It’s not that I think this practice is a waste, it’s just not what I need to focus on.

Writing will always have a place in my life, whether or not I’m posting to a blog. I’m learning that, often, the payoff is the writing. It’s in the writer’s cramp and in filling notebooks. In thinking through problems and developing your opinion. In evolving your outlook and seeing life in fresh new ways.

I’m still drafting my next chapter but found in life’s little moments is more than enough material.

I’ve removed analytics and page tracking from hackmake.org. For years, I’ve used Gauges for analytics. They’ve got a great product. It’s simple to use and not owned by Google. Recently I’ve been reading more discussions about the privacy concerns of third-party tracking and advertising scripts, the data they collect (and often resell) and the speed impacts they have on page load times.

Often the discussions pointed to browser plugins like Ghostery or EFF’s Privacy Badger which block these third-party scripts from loading on a page. I gave it a shot and quickly forgot about the little ghost in the top corner of my browser keeping all the riff raff out. iOS 9 was just released and contains a feature called Content Blocker built into Safari that lets developers make apps that block ads and third-party scripts. I’m also excited to start using this.

Since I don’t want this stuff loading for me as I browse websites, I thought it rude of me to continue tracking you.

---

I’m interested in seeing if anything will change with what I publish since I no longer have analytics telling me what people are clicking on. I’ve never paid too much attention to this site’s (admittedly small) traffic numbers, nor experimented much with topic or writing style to chase clicks.

If anything, it might free me from the little sting of hurt when I see the downward traffic trend that comes with writing less. I have to keep in mind that number doesn’t show the amazing things I’ve experienced and achieved in my life since spending less time writing for this site and more time on other things.

This last July, I came across an article by Christian Tietze that piqued my interest: Create a Zettelkasten for your Notes to Improve Thinking and Writing. Zettelkasten, as I learned, was a system that helped many researchers keep their small ideas filed away so they could find them later but also keep these little notes linked in important ways.

That idea stood out at me.

Each note was not just a thing—not just a text file in a directory listing—but a node on a network of interconnected ideas. If you tend to think in themes like I do, these notes, jotted over time, compile in to great bodies of work. If filed properly, that relationship would cause surprises for you over time, zettelkasten promised.

In 2012, I became captivated by the idea of carrying a pocket notebook. In Jotting Notes and Stealing Ideas, I wrote:

Paging through the little book, I found that even though the ideas weren’t all novel or penned by me they became mine in the way they were threaded—connected—page by page, in the same messy scribbles, in the same voice and shorthand, all working together towards the same goal.

These notes, at the time, are just ephemera. We don’t know what they mean yet. But:

When you capture an idea it’s just a small piece of something bigger. Something you can’t really picture or describe yet. But when you look back through the pages you start to see how the ideas connect and the shape of something begins to come together.

A note could be connected to a simple idea from years ago that you rediscover, the way you pull an old notebook off of your shelf and stumble across the thoughts of your younger, more impressionable or more spirited self. Our digital notes could have an impact like flipping through an old notebook if it had a bit more context, like the adjacent pages in that weathered book.

Thinking Is The Work

Whenever you want to think to some purpose, you should consider writing it down.

Christian also revealed that wisdom in his post. This isn’t “productivity,” just plainly about efficacy. If you’re spending time thinking, you should document your thoughts so they can be useful for longer than their fleeting moment in your mind.

I’ve often confused productivity and efficacy. Being effective doesn’t always have a “shippable” end product, yet the non-fruit-bearing work can still be useful. This work is all research. It’s the thoughts, articles, evidence, meeting minutes that are all going to eventually lead to some idea connecting. You may not be a scholar but as a knowledge worker, the more of that knowledge that you collect and process, the more power you have. I haven’t been in my career very long and already I’ve wished many times that I’ve had maintained notes on design decisions from previous jobs. I’ll run in to the same design problem years later and wish I had documented my learning. Your career path will likely follow similar roles and responsibilities over decades and these notes and connected ideas will only form stronger ideas, more solid proof, or evidence of past learnings. Those problems you’ve solved (and hopefully documented along the way) is the work you do. If you’re smart, you’ll make sure those solved problems will be of use for you again in the future.

Just to make sure you’re with me so far:

• Your notes are ideas that are interconnected
• If it’s worth thinking about, it’s worth writing down
• What has happened can help inform you of how things are going to unfold in the future
• Notes aren’t just notes, they are the research and documentation of the work that you do

I wanted those things. I wanted to change how I documented my work, my thinking, and my research. Zettelkasten is often done on notecards and I wasn’t enticed by the paper knowledge base it suggested. I try to make very deliberate decisions about the tools I use. I think a lot of bloggers will tell you that and then drop an affiliate link to their tool of choice, wrapped in an eloquent exposition of how said tool changed the way they work. Watch out for those people. (Question everything I have to say, alike.)

This was going to be a breathing knowledge base of the things I jot down, the products I develop, the failures I make, and that work mattered to me. I wanted something that would endure. The choice that was clear to me after testing a few options was MediaWiki. If the world felt comfortable using it as a platform for our global knowledge, I did too.

An Unordered List of Notes I’ve Been Collecting About Using Mediawiki

• Self-hosted MediaWiki on hardware I own
  • You control your knowledge base, you control your information
  • I’m not relying on anyone else to store my data safely; backups are my problem
• Internet architecture wins
  • Extensible and open source
  • No company is making money off of your life’s knowledge work
  • Web APIs > Applescript
  • Server-side software = light (Rule 8)
  • Take the tradeoffs of slower and web-based for longevity
  • Include JS tools, like Mermaid
    • Mermaid, by the way, is hot shit. Doing charts and process maps inline with your other documentation is so lovely
• Everything is just a page. Simple.
  • Make pages basic—just few words or a sentence—or compile ideas together using transclusions
  • Don’t worry up front about categories or how you organize; just do your work
  • After a while you’ll start to feel a trend in how things are organizing themselves and start following their lead
• Plain text is simple for typing notes but doesn’t connect ideas together well
  • No, “search” is not connecting them
  • Nodes are connected by hypertext
  • HTML with hyperlinks connects the world’s data, your notes can benefit from this
  • Internal links in apps like Evernote or nvALT are nasty
  • Easily link ideas just by wrapping the name of the page you want to link to in square brackets, like [[Linked Page Title]]
• Leave yourself future breadcrumbs with red links
  • You don’t need to create a page to leave yourself nuggets of ideas
  • Create a red link and come back to the idea later
• Change history; see how things evolve over time
  • Commit messages help give you a summary of changes and the reasoning you made
  • Recent changes in wiki sorted by date
• Connection of ideas > simplicity of capturing
  • nvalt can still be a quick way of creating notes but they should be managed somewhere else long term
  • Using a notepad on your desk or a scratch text file is a very fast way of capturing
  • What you write down when you capture is different than how you would write something for retention, so don’t convolute these in to the same step (Ever write shorthand in a quick note and then have note and then have no idea what it means tomorrow or two years from now?)
• Customization hinders simplicity
  • Pretty urls will break on upgrade. K.I.S.S
  • Extensions and templates are helpful; don’t get carried away though
• WikiMarkup isn’t markdown but it can be powerful
  • Don’t be afraid to cheat by putting in some <nowiki> blocks if MediaWiki markup drives you nutty for big blocks of notes you copy/paste
  • pbpaste | /usr/local/bin/pandoc -f markdown -t mediawiki | pbcopy is your friend. It takes markdown that you’ve copied, from say your scratch text file, converts it from markdown to mediawiki markup and puts it back on your clipboard, ready for you to paste into the web form

What This Has Meant For Me

I’ve been using a wiki for my notes for over 6 months now. Thinking of my body of notes as a knowledge base rather than a stack of text files helps me keep the different ideas connected. I now think of my note pages like I would read them on Wikipedia, explaining to myself where ideas came from and predicting where they’re going—the history of the thing and how it was executed. It’s not just notes from a meeting but notes on an interaction with people, who have their own motivations and goals, on a project that has a history and a roadmap. They are all connected and I want my system of documentation to compliment that.

“I’m a person of simple needs.”

I like this because it’s not making one out to be a “simple” person but it’s the needs that are simple. Still, the mind can be complex, the desires great, intentions pure, and friendships in abundance. I feel like often being called a simple person has a negative connotation, like a farmer being a simple man (and maybe why “minimalist” has proliferated… calling yourself simple while still being fancy). Understanding that you have simple needs and forming your life around that has a strength and vigor behind it.

A couple years ago (see: archives) I was very much in to finding or writing hacks to help smooth out the little bumps when software wouldn’t quite work the way I wanted it to. Some of these hacks were quick, inelegant fixes just to satisfy my itch of trying to solve a problem in a different way and some were bigger projects that I thought might get a decent amount of use over time. With that passage of time, different jobs, and work styles, only some are still in use while many of those hacks have become irrelevant, abandoned, and forgotten.

I’ve learned a few things while <airquotes>hacking on my workflow</airquotes> that I’ve only recently became cognizant of:

• It you want your “hacks” to be functional for a long time, don’t do much funky stuff
  • The problem here is that if you’re new, you don’t know what’s funky and what isn’t
  • Funky stuff includes (but is not limited to):
    • Referencing outside dependencies which aren’t controlled; links break or files move and your script fails
    • That clever solution you thought of which was just too clever (clever = complex; complexity = evil)
• See if other people have built it (and done a better job)
  • I heard a saying once: “A new engineer thinks, ‘Hey, I could build that’ while an experienced engineer thinks, ‘I bet someone else has built that”
  • Building might be fun but maintaining isn’t, so leave that to other people as much as you can
• Document what you’re doing
  • The path to how you solved this problem is really important and will prove valuable in the future (probably more valuable than the script you’re writing)
  • The links, StackOverflow posts, and mailing list archives that helped you solve this will help you again next time, or when this breaks
• Document what you’ve done
  • Not for others but for your future self
  • Documentation doesn’t always need to be inline because you should be writing readable code
  • Keep a wiki of what scripts you have, where they’re expected to live, what other scripts might reference or execute them
    • I easily finished the below script when I found an old one that I had totally forgotten about that did a similar thing
    • If I would have had a scripts database to search through (like I do now) I would have solved this problem a lot easier
  • Equal parts writing code as writing documentation; if you’re spending 5 minutes thinking, you can spend 5 minutes writing about what you were thinking. You don’t get that time thinking back but you can keep that knowledge if you write it down
    • There’s a good chance that you’ll never use this hacky script again but you’ll probably use this knowledge again, so actually learn something for good by writing it down
  • The good developers I know document everything
• Build in checks to see if everything is working as planned
  • I’ve spent enough time writing scripts, testing them out, and then loading them in to Lingon only to have them fail in the next day or two after I’ve forgotten about them
  • I don’t check back and this backup script script hasn’t ran in 6 weeks
  • I’ll be honest that I don’t know a good way to programmatically check that something hasn’t happened but it’s a good thing to think about and build in to your scripts if you’re smarter than I am

---

Here’s a good example of not doing funky stuff.

I was writing this script today that I’ve wanted for a while but just haven’t sat down to do. It would take the first line of a text file in BBEdit, make it in to a URL-friendly slug, and save the current text file with that slug as the filename. I’ll use this for every blog post I write (which doesn’t happen so frequently anymore).

At first I had this:

set title_slug to do shell script "echo " & quoted form of title_text & " | ~/Dropbox/bin/sluggify.rb"

where I reference an external script (sluggify.rb) which takes “A Title Like ‘This’” and does some gsub foo on it and turns it into “a-title-like-this”. What happens if, say down the road, I stop using Dropbox to sync and take my belongings to some other cloud? This script breaks because it can’t find ~/Dropbox/bin/sluggify.rb and I have to go fix it. Instead, I can do something kind of less funky like this:

set title_slug to do shell script
        "ruby -e \"input = "
            & quoted form of title_text
            & "print input.gsub(/[ [:punct:]]+/,'-').gsub(/(^-|-$)/,'').downcase\""

where I take that ruby code and execute it inline. Less external dependancies, less funky stuff. Here’s the full script, by the way (because I like you):

set user to system attribute "USER"
set drafts_folder to "/Users/" & user & "/Dropbox/hackmake/drafts/"
set ext to ".md"

tell application "BBEdit"
    tell text window 1
        set title_text to contents of line 1
        set title_slug to do shell script
            "ruby -e \"input = "
                & quoted form of title_text
                & "print input.gsub(/[ [:punct:]]+/,'-').gsub(/(^-|-$)/,'').downcase\""
        set draft_path to drafts_folder & title_slug & ext
    end tell
    save document 1 to draft_path
end tell

---

You’re not what you make–You’re the problems you solve.
—Internet Contrarian, Sean Korzdorfer in An Annotated Life

I’ve been drifting back and forth in the last year about how important “they way we work” is. Is Microsoft Word enough? Or do we need to find a fancy way to do something as to satisfy our feeling of being a special snowflake artist-type? I used to put more value in the things I make but, over time, I’m realizing that a lot of those things just whither away or are never paid attention to in the first place. That doesn’t mean stop making but I think I’m putting more energy in to reflecting and trying to understand the process that got me to the end of a project—that’s what makes me better at what I do.

The problems I solve and the things I learn along the way are a much better indicator for me of “working better” than what’s in my toolkit. I focused a lot on capturing what I needed to do but not capturing what I had done and learned. With this post-productivity mindset, I’m focused more on what I’ve learned not what I’m doing and that helps me hack better and work smarter.

A few months ago I moved in to a new apartment. It’s taken me a little while to settle in and I finally got around to hanging up some shelves and a bike rack. In the past, I’ve used whatever hack possible to sink a drywall anchor because I didn’t want to spend the money on a drill and didn’t really want the extra things to store in a tiny New York flat. I finally wanted to get a drill so I could properly sink the drywall anchors on not have my bike crashing down from its hanger. When I was at the hardware store I looked around and found a manual, crank-by-hand drill. It was small, inexpensive, and tailored exactly for what I needed. No extra features, no batteries. It wasn’t the best drill on the market. It was the simplest tool built for the job and it was the perfect tool for the job.

We can’t forget to look for what’s the perfect fit for us, not just what’s the best based on features or what other people think.

I think I was in 9th or 10th grade when my older brother brought home a copy of Getting Things Done. I don’t really remember the way he described it or what convinced me to get in to it but he gave me a copy and I dug in. At that age you’re easy to influence and like many I’m sure whose brother came home with beer or drugs, I got in to GTD at a time that it greatly impacted my perspective.

I picked up GTD at a time where I needed a map for life but now I think it’s been leading me off course.

I started using Things in the early beta days and used that through highschool and college. A few years ago when I learned about people who were using OmniFocus and really trusted it, so I made the move. You’re always changing so your processes should evolve too and eventually I felt over OmniFocus. It just didn’t fit the model of how I wanted to work and live. I don’t believe that switching software can lead to transformative change but I do think it can help nudge your habits enough to starting seeing things differently—from a new perspective.

---

Trello is about giving you vision in to what you’ve written down, not about actually doing it. It’s almost a stale trope at this point, but I’ll reiterate it anyway: we don’t need to do more things we need to be more conscious about the things we do. Just like the world around us not really caring about what we do, neither does Trello. It doesn’t sit there taunting us, telling how much we haven’t gotten done. A blank card is just a blank card. It’s not an obligation, a promise to yourself, an expectation, or another opportunity for you to let yourself or someone else down. A card is just a card. Use it for a project you want to do, a reminder for a thing you should say to someone special, a divider or break point in a list, a thing that makes you happy and that you should do more often. The card isn’t begging you to check it off as done then evaporate. There isn’t even a check box on the card. Let your Bucket List sit right beside your Today list. Who’s to tell you that your work today is more important than the rest of your life? Leave it there, let that list sit in front of you all day, everyday. Don’t let that thing disappear. Let it fester as a reminder of what’s important to you and let fade away your little tingly feeling of marking off another thing as done.

From the Trello launch blog post in 2011:

Trello is probably the simplest thing in the world: it’s a web page where you make a bunch of lists. Each list contains cards. Each card is a thing that someone might want to work on.

It is simple (and you should keep your life that way). Here are some things I like about Trello:

• It’s a website
  • Forget about sync, updates, OS compatibility
  • The web links a lot better than apps, internally within Trello and externally
  • Trello’s success isn’t at the hands of Apple approving their updates (I’m becoming that guy)
  • Web back ends have APIs
    • I’ve wasted so much time hacking at things like of-export to get information
    • HTTPS is king
    • I could actually build reliable tools using Trello data
• The back of a card is a workspace
  • It does markdown
  • Half of this post was written on the back of a Trello card
  • OF’s notes field and file attachments suck
• Comments
  • Leave comments/log for myself
  • More than it’s done but how I did it
  • See progress as an idea evolves
• Trello, Inc
  • Now its own company, not a part of Fog Creek
  • Joel knows how to build exceptional companies

Maybe some day I’ll go in to more detail about how I use Trello but I think that’s less relavant since the process of setting it up fresh without a lot of bloggers telling you how to use it is a great opportunity for introspection on the way you work and good practice in figuring out what you need. I’ve been using it full time for 3 months now actually kind of enjoy using it. It’s given me what I need and nothing more. I don’t obsess about what’s in Trello or how it’s organized like I did with OmniFocus. I don’t need to do maintenance to keep it useable. I go in, get my work done, and get out.

---

I’m starting to reduce what value I perceive these tools to be in my life and that’s causing the perspective shift. GTD was a user manual for a tool that I followed until I began to master the craft. With a little more experience, I recognized that the tools just helped guide me through the craft until I was comfortable doing my work without those instructions. I used to depended on them for success but now I can lift my head out of the manual and go learn something else.