#029 — Garbage Day

I’ve been talking about productivity tactics a lot, because that’s what has been on the front of my mind. Working on my book over the last year developed the habits I needed to work hard; now I’m trying to build on that by becoming more efficient.

Image Source: kleinAlexis (Pixabay)

One thing I’ve done that has proven to work out fairly well is to split my day up into distinct periods for focused work and non-focused work. In doing this, I’ve carved out time in the late evenings and weekends for my heads-down stuff, and then left myself very flexible for collaborations, chores, informal research, etc. throughout what most would consider standard business hours. That has been working out great, and so now I’m looking to optimize things even further.

When I look at my deeper work that requires focus (i.e. writing, coding, business analysis, rigorous research, etc.)–there is a clear gradient between things that I am excited about and really want to work on, things that are kind of neutral, and things that really drag on me and make me feel stressed/exhausted.

It wouldn’t be fair to categorize these different emotional reactions as a measure of “how valuable” my work is, or even “how much it matters to me.” Sometimes the important stuff truly is annoying to work on, sometimes the less important stuff is a true joy to dig into. In fact, it’s precisely the lack of correlation between emotional state of mind and relative importance and urgency that has got me looking for a better way to decide what to work on when rather than just asking “what I am in the mood for?”

And with that in mind, I’m going to experiment with the idea of introducing Garbage Day. The theme for that day each week will be to dig deep into any of the stuff that has been making me feel like garbage for not making progress on it. I’ll expect this day to be a struggle, I’ll expect to encounter resistance at every corner. But I will also see any and all output on that day as an investment in the ongoing sustainability of my work.

The tricky thing is going to be figuring out where in my schedule I should insert this day each week, and that’s something I’ll need to experiment with. I need to come into Garbage Day with enough will power to make progress, and come out of it with enough room to recharge so that I don’t feel burned out in the days that follow.

Another unanswered question that I’ll need to verify through experimentation is whether or not structured procrastination (which is ultimately what this is) will actually serve to optimize my productive output or not. If Garbage Day starts to feel like something I’m anxious about each week, then that’s no good. If on the other hand, it becomes a way to put myself in the right mindset at the right time, it’s good!

The question of “should I work on this today or would it be better to take care of it on Garbage Day?” is, if nothing else, a very sharp-edged prioritization tool. Let’s see if I can wield it skillfully or not.

I’ll set a reminder to write up an update 8 weeks from now; win, lose or draw. Until then, time to take out some (mental) trash!

#028 — Minimum viable overlap

Many seek out connections with people who are very similar to themselves. This has never been the case for me, and I struggle to understand it.

Image source: Pixabay

I try to learn what I can from everyone who crosses my path in life, particularly if I can see some glimmer of something I value in the work they do. But I only end up making close connections with those who are meaningfully different from me in some way.

In other words, I like when there’s a gap I can fill for someone else, or a gap they can fill for me, or both. Because when you have that, it increases the chance that you will have a multiplier effect by working together on something.

When surrounding yourself with people who think like you, act like you, care about the same little details that you do, it’s true that you might be able to locally optimize in your field of expertise. But that can quickly devolve into an inward focus, and is the driving force behind what creates echo chambers.

The key thing I care about in any collaboration (and maybe this isn’t a very popular viewpoint) is that I want each and every person involved to be “standing on sovereign ground,” where they can be totally responsible for their own pieces of the puzzle. If I surround myself with people who are too similar to me, I end up wanting to argue over the little details rather than the more meaningful and important whole.

Collective ownership, if it can be had at all, is something I believe works best when everyone bets on their own strengths and then covers for each other’s weaknesses. This is how you end up with a whole that is greater than the sum of its parts.

A vulnerability of having this sort of mindset is that it raises the question of “how do you learn to be good at the thing you bring to the table if you’re not surrounding yourself with people who also working to get good at that particular set of skills?”

To that I’d say, experience does teach you more than any other person can. Simply doing the work is more important than finding the right teacher, or the right mentor, or the right team… because without doing the work you can’t really know how to answer questions on what the optimal collaboration strategies are like anyway.

But beyond that, this is about who you “set up your basecamp” with, it’s not about who you meet along the path to where you want to go. So if there are people out there doing similar work to you, it always makes sense to talk with them, to study their work, to read what they’ve written, etc. But it’s also important to remember that those folks are there to get ideas and inspiration from, not necessarily to work closely with.

And to that last point, there are some exceptions. But that would get me talking about mentorship, and that’s a complicated topic that I’ll save for some other time.🙂

#027 — Fit to purpose

Even when you try to avoid it, it can be easy to jump into how a problem ought to be solved before you really understand the problem itself. This always ends badly.


Take for example, a simple “contact us” link. You can argue that it ought to be at the top of the page, because then it’s easy to find. You can argue it should be down at the bottom, because only people who actually read the site will bother to contact you. You can even argue “why not both” or an in-between solution. These all have their various pros and cons, and so it’s reasonable to consider them.

But sometimes when you go to place a contact link on a page, you realize that you never really thought about who would use it, and the surrounding context that got them to land on your website in the first place.

Once you dig into that question, you may find that it leads you to revisit every piece of content and every design decision throughout an entire page. So your call to action is that you want people to contact you? OK, about what? What will they know, and what will they not know at the time they decide to contact you? What do they need to know in order to decide if they should contact you?

These deep questions can bubble outwards from a seemingly simple design decision around the placement of a single element, revealing much larger concerns that were left unconsidered in the early stages of a design process. “Where do we put the link?” can quickly turn into “Is this website even useful at all?”–and that’s a scary thought!

This is one of the many reasons why it’s tough to do design and development work at the same time, but it’s also one of those things where if you leave space in the schedule to do the necessary redesign and rework, it can make all the difference in the end result. It also helps to remember that the whole point of design is to find the right questions to answer.

The tools we love are the ones that are a perfect fit for their purpose. The ones that confuse us and frustrate us the most are the ones that we’re not even sure what problem they’re trying to solve. This point applies equally well to wrenches and websites, and it’s worth keeping in mind.

Note: I’d like to thank Jordan Byron for inspiring the ideas behind this post.

#026 — Trending Topics

There’s something that I don’t do which I think has been a huge net win for me, both personally and professionally: I almost never discuss trending topics in public.


I actually go a step farther and usually disconnect myself from people and places in which “what everyone is talking about” is the focal point. This is why I don’t have a Facebook account, it’s why I’m selective about who I follow on Twitter, it’s why I usually only frequent HN or Reddit when my own work has been posted there.

It’s not so much that I think it’s somehow wrong or bad to be talking about “the flavor of the month”–it’s that I feel like it’s way too easy to have commonplace, largely meaningless interactions around them. When the whole world is talking about one particular thing, everyone sounds like an echo of everyone else… and whatever unique signal there might be in the mix is lost in an endless amount of noise.

It also too easy to make a quick joke, or drop a bit of witty cynicism and feel like you’re somehow “participating in the conversation”–and locally, people reward you for that. They’ll click the heart. They’ll reply with their own quip. They’ll retweet you.

The problem is, none of this ever leads anywhere. The only effect it has is to keep some topic in the front our collective consciousness for a while, while we go back and forth in closed loops over the same ground. Some cream does rise to the top, but most of us are just the dry milk stuck to the edge of the bottle in these conversations.

I think to some extent, people do this (whether consciously or not) more as an act of social bonding rather than as a way to communicate actual knowledge or propose meaningful solutions to problems. And that makes sense, because any topic that “anyone can weigh in on” is one that few are qualified to truly be an expert on.

But for me, if I can’t bring some genuinely unique, genuinely valuable perspective to a topic of interest, then I usually try to avoid talking about it at all. Sometimes,  I can’t resist jumping in and fanning the flames a bit on some hot topic, but usually I end up regretting it. I feel it dilutes me, distracts me from building my castles in my own little corner of the world.

Maybe I’m the odd one, for not wanting to be a part of the global conversation on nothing in particular. But there’s a quote from Zig Ziglar that I love, that I think sums things up nicely: “Be a meaningful specific, not a wandering generality.”

That’s what I try to do, as best as I can. But I have to admit it’s hard, when you have things like BAD HOMBRES, NASTY WOMEN just begging to be shared:

Whoops. I better stop now before I start selling some tremendous Trump Steaks.

#025 — George

There are many people that I’ve learned important lessons from in life, but I think George was probably the first. He’s my best friend’s dad, and he and his family have run a tiny pizza shop since they first immigrated to the US from Greece in 1978.

Screen Shot 2016-10-19 at 10.49.26 PM.png

The shop itself is called Mike’s Pizza Palace, named after George’s brother. Mike retired a few years ago, but George still soldiers on. He takes something like four days off for the major holidays each year, but otherwise works seven days a week, and has done that for nearly forty years.

By all measures, this is somewhat ridiculous. To work from 8am to 10pm day in and day out, for decades and decades, it’s a life that few would ever want to live. But there is also something deeply inspiring about it: That this small family has kept the doors of their shop open and their business afloat throughout nearly every change you can imagine in the world, but inside it has always remained a fixed point in time.

The picture above is from the 1980s. If you walked into the place today, you’d see roughly the same thing as what you see in the picture above–with only modest updates to the decor. It’s like walking into a time warp to go into this place.

I spent so much time hanging out here when I was young. I thought I was just keeping my friend company while his mom and dad worked, getting an endless amount of free pizza in exchange for putting together some pizza boxes once in a while. But what I really was getting was three critical life lessons that truly helped shape who I am today:

  1. A business doesn’t need to be fancy or exciting to be successful. In fact, simple businesses are powerful because they can be boiled down to a science–you just need to be selling something people want and doing a great job at it.
  2.  The idea of a small family running their own business so that they could provide for their own kids, bootstrapping from basically nothing, is something working class people can do. It’s not just reserved for those with boatloads of opportunity in life or a deck stacked in their favor.
  3. Nobody works more than George. Nobody!!!

That last point is the one that I think has stuck with me the most. I always joke with my friend about this and I think he probably just thinks it’s just banter over beers. Because I start talking about “Oh, I’ve been working a ton lately. I’m feeling like I’m turning into your dad.”–and at first I say that in this sort of complaining way.

But then I always catch myself and talk about how much I admire that weird combination of stubbornness and stamina that can cause someone to keep something up and running over the long haul, no matter what’s going on in the rest of the world.

It’s a double edged sword, of course. But from George I learned to respect the virtues of hard work, and that’s a lesson I’ll carry with me through the rest of my life.


#024 — jsGrid Onboarding

Yesterday I spent a tiny bit of time playing with jsGrid, and the first run experience was great! It’s so good in fact, that I won’t bother explaining it at all. Just click the image below and it’ll bring you to their homepage and you can see for yourself.


This is a great example of building a website that can quickly get someone started on using an open source tool, while still making it possible to find relevant reference material, too.

A+, would onboard again!

#023 — Future tense

There is something I learned quite a while ago and it really stuck: there’s no such thing as wanna do or gonna do… there’s only what you do and what you don’t do.


And so I’ve gotten pretty good at accepting the idea that if there’s something in the future you’re chasing after, you damn well better be chasing after it in your actions rather than just in your thoughts and words.

But I still have an Achilles’ Heel: I tend to jump quickly into future mode while leaving present matters unattended to. And when I do that, I can sort of claw and scratch my way into a better future, but it doesn’t come easy.

The present sucks, usually. Because the present is the accumulation of past decisions that stand in the way of a bright future, and it’s also where all the unplanned surprises happen. But every future moment in time will be the present sooner or later, so it pays to think about how to arrive there with as little debt is possible (where debt can be unfinished work, financial debt, tech debt, you name it.)

The future is full of um… whatever the hell is in the picture above. And that’s glorious. But the present has some trash that needs to be taken out to the curb, and that’s pretty important, too.

#022 — Phoenix onboarding

Today I spent another short session trying to install and take the first steps with an open source tool that seems interesting. My choice for this morning was Phoenix.


This framework interests me for a few reasons, but mainly because I’m dipping my toe into some realtime-ish web development stuff, and I am hesitating on “Sticking to Rails” even though Rails 5 seems to have some tools built in for this sort of work. So to me, as a total outsider, Phoenix means some capabilities for building realtime apps, backed by the Erlang VM, with Elixir as a handy bridge to make things feel on the surface level to be a bit more Ruby-like.

I am an intermediate level Rails developer and I have a basic understanding of Erlang, but haven’t used Elixir much at all before. Still, this seems like an interesting place to play, and I need everything up and running before I can do that, right?

The first page I landed on was Phoenix’s Overview guide, which has what looks to be a conference talk front and center. I bet that’s interesting, but the first 90 seconds of it do not immediately show me some sort of demonstration–and I’m literally so impatient that this causes me to close the video. (Real talk: I initially only watched for about ten seconds before giving up, and only checked the first 90s after writing this post! I am the worst.)

The thing is, I already am here on this page knowing I want to try Phoenix. I know next to nothing about Phoenix, but I’m open to the possibility that it might be useful to me, and so I just want to know how to get the bits and bobs in the right place so that I can start playing. Maybe others want the lecture first, but I don’t.

I scan the site’s sidebar and find the Up and Running guide. Yes! That’s what I’m looking for, I think. It tells me to go read the Phoenix Installation Guide first, so I head over there.

That guide tells me to first get Elixir set up by following the Elixir Installation Guide and I do that. I already have Homebrew set up on OS X, so installing Elixir only requires running two commands. (Actually, that’s a small lie, I had to unlink an old version of Elixir which I forgot was installed, but that was easy and Homebrew told me how to do it.)

I close the Elixir Install Guide tab in my browser and am back on the Phoenix install guide. It tells me I need to install the Hex package manager and gives me the command I need to run to do that, which works without issues.

Then it warns me about the possibility that Erlang might not be installed but reassures me that most package managers do install it (Homebrew is one that does, I think? I already had Erlang installed either way.)

Then it gives me a command to run to install Phoenix, and tells me what to do if for some reason that command doesn’t work. But the first command works without issues, so I ignore the “what if it doesn’t work” instructions.

Then the guide tells me about Plug, Cowbow, and Ecto, which are default packages used by Phoenix which if I do nothing will be automatically set up so that I don’t need to worry about them. Not sure why I needed this info? But alright, that’s fine.

Then there’s something about Node.js being an optional dependency, because it’s a dependency of a dependency of an optional dependency (Brunch.io). No problem, I already have Node set up, although it seems like this is usually the underlying reason of why I have Node set up. I’ve never built an actual Node application myself. This is fine except that I have no clue whether I’ll one day update Node (or not update it) and it’ll break a bunch of different tools in different ways.

I close the installation guide and get back to the Up and Running Guide: It gives me two ways to create a new project and I run the shorter command. I only realize after scrolling that it tells me that’s what I should have done, along w. some other notes about what to expect.

One of the things that I skipped over was an explanation about how if when the setup asks you to install the dependencies for the application and you say “no” then it will lead to a broken application and you should have either installed them manually or used a flag before you ran that command if you didn’t want that to happen. I said “yes” so fortunately I don’t have that problem, and I do have Brunch.io even though I still have no clue what that is.

I could take time to read all of this stuff, and if I were seriously evaluating Phoenix for a first project, I should take time to read it. Long before I shipped Phoenix into production I would read it. But right now I just want to play around, and so as long as by computer doesn’t break as a result of installing this stuff, I do not care about what dependencies are being used and why, I just want the shortest path to application building!

The project skeleton is generated and within its root directory I run a command that’s supposed to set up the Postgresql database that will back the application. I already have Postgresql set up for use with Rails, so this wasn’t a step I needed to worry about when installing dependencies.

When I run the database creation command, it asks me if it’s OK to install Rebar. I don’t know what Rebar is, but sure, why not? And I don’t know what will happen if I say no.

Rebar installs successfully, but then the command fails with a fatal error, because my Postgresql setup does not have a postgres role configured. It was at this point where I was about to search for a StackOverflow post due to muscle memory, but on a closer skim, the guide actually does mention this scenario, and helpfully links to a guide that explains how to resolve that problem.

At first the in-page anchor doesn’t work so I’m just looking at the top of a massive document. I click it again and somehow it brings me to roughly the right place.

The advice boils down to “Create a postgres role” and has some basic documentation on how to do that. This requires me to remember how to manually run psql with my current setup, because I almost never need to do that. But then after I do that, running the following line on the psql console works just fine:


Confession time: I have no clue what I just did. I think that the postgres user is probably meant for system-level access for PostgresSQL or something like that… my setup is done differently through whatever tutorial I followed for “Postgres Rails OS X”. In production work, either someone else on the team is responsible for the production/staging servers or I use services like Heroku who hide all these details, so I’m a first-class “muddle through it in development” sort of person and have no idea about the inner workings of these low-level dependencies.

I probably should know more about them, so I start to feel guilty about that at this moment in the setup process, but then I remind myself that I only install new stuff very rarely and so it’s not a big source of friction for me, and never something that negatively impacts my customers.

Anyway, where was I? Literally, what page was I supposed to be on? Ah yes, I close my most recent tab and now I’m back to the Phoenix Up and Running Guide.

It tells me how to fire up a server, and I do that. It works without issues, and hey, I see the welcome page!


I love this page because it has some useful links on it, and I also love it because I’ve just slogged for 20 mins through miscellaneous “run this and then that and if that doesn’t work try this…” sort of stuff, and so this is my first small win.

But this is Phoenix’s “Hello World” to me, not my “Hello World” to Phoenix. A subtle but crucial difference, but one that I care a lot about. So I follow the link at the bottom of the Up and Running guide and end up on the Adding Pages guide which is supposed to be the next step in the process of building stuff with Phoenix.

There is great information in this guide, but probably too much detail, and probably not quite in the right order. I skate past a couple pages of “This is what our folder structure looks like” to find the A New Route section, which is where the real instructions begin.

I am familiar with Rails, and because Phoenix is vaguely Rails like, I am not surprised that I need to touch four files in order to get a Hello World page to render–a route, a controller, a view, and a template. I am overall even slightly curious at this point, because now that I’m digging into these files I can start to see how they are similar/different to things I already know. But for the most part, I’m still thinking “just tell me where I need to put this stuff so I can see what happens!”–and many pages of documentation hurt more than they help. Explanations are very useful to me, but only after I have an end-to-end example running.

I get my four files in place and amazingly, did not mess up any of my copy-pasting. I even stopped for a minute to install the language-elixir package in Atom… because without syntax highlighting it’s hard for me to spot syntax errors. This all goes smoothly, and soon enough I’m looking at a Hello page coming from code I at least pasted into the right places… a sign I have at least the very basic beginnings of a working environment.

I go back through the second example in this guide which adds a parameterized route that lets me put Hello, Gregory onto the page by visiting /hello/Gregory — I only need to touch three files this time to make that happen, and I’m basically convinced that this workflow is very close to Rails and can not stress about it anymore.

So what happens next? Unfortunately, nothing. There’s no link at the end of this guide page to the next step, and the sidebar is just a bunch of different framework features. There’s no demonstration application I can find on the site, and it seems like the best bet for finding one might be to buy a book.

I’m sure if I dig deeper, I’ll muddle through. But I haven’t done any CRUD stuff yet, and so I’m not even sure that I can read and write to the database I set up. I got as far as Hello World, and then was sent off into the forest to figure things out for myself.

The difficult admission here is that when it comes to complicated open source projects, the Phoenix documentation and setup process were in my view, above average in their quality and consideration for the kinds of problems developers might run into. But they’re also representative of the incredibly low bar we’ve set for onboarding in open source tools, and also the shit soup that we build our libraries and frameworks on top of.

We can and must do better than this! The real challenge is to figure out how to do it in a way that’s reasonable–particularly in projects that are built by volunteers.

So… that’s something I’ll keep thinking on. But I think I’ll also keep doing these onboarding teardowns so that we can understand the problems better, which may eventually lead to better solutions.

#021 — Electron onboarding

Today I spent my first half hour looking into Electron, the GUI toolkit behind Atom, Slack, and a bunch of other things. I started with this video:

It’s basically a very high level, marketing-ish overview, but it tells you the main idea: That in Electron you can use HTML/CSS/Javascript as well as Node.js to build a GUI application, and the operating system integration stuff is handled for you.

OK, cool, so what’s next? Download a Quick Start boilerplate repository that lays out window in Electron with some “Hello World” HTML rendered within it. I’m glad this exists: it worked on the first try for me, and saved some of the guess work of getting the right files and dependencies in place.

From there, you’re supposed to download another application that teaches you Electron’s APIs and is supposed to (I guess?) help you get started on using the boilerplate code to build your first application.

This is the first page of that API demo app:


I have no doubts that this demo app will be useful, but the question is, is this a great onboarding process? It’s clear that considerable effort went into it, but who was the target audience? It seems there is a missing piece here.

Most people–even very experienced programmers–want to see what can be built with a tool before they learn its inner workings (such as item number two on the list here which the slightly unsettling “handling window crashes and hangs”)

So I was pretty surprised that with language like “It’s easier than you’d think” and a polished marketing video, that the on ramp didn’t lead in with something like a mini-text editor, or an address book application, or a tiny chat tool, etc.

I’ve certainly been guilty of this sort of thing in my own projects.But here’s hoping I’ll take a more human-centric approach towards onboarding people in the future, because “how to handle window crashes” is not what I’d want to know about Electron on a first run through, and if it’s the first thing I need to know, well… that’s a sign of a deeper problem.

This is less of a criticism of Electron and more some ruminations on things related to #HumanizeTheCraft. I will do what I always do at this point with open source projects, muddle through, ask around, and tinker until I can actually start learning the tool.

But if we want to make development tools genuinely more accessible, we’ll need to do better than this.

#020 — Living in the present

An adventurous journey across a vast sea begins not with pushing off from the shore and sailing into the unknown, but with carpentry.


And this is such a difficult idea to those who can easily dream big: that the only way to reach the wonders that lie beyond the horizon is to begin with the relatively mundane work that must be done here on dry land.

But is that work really mundane after all? Of course not. Anything done with care and craft can be made into a rich and fulfilling experience. Still… compared to that impossibly beautiful dream, everything tends to pale in comparison.

I’m writing this as a reminder to myself. My twenty year vision is perfect, my five year plan quite clear. But it’s always what I do with the next five days and the next five hours that will get me there in the end. Sometimes that means building little piles of sawdust, rather than splashing in waves of saltwater.

So we grind on. Head in the clouds but feet in the dirt. And of course it stretches us, but it’ll be worth it, right?