Month Two Week One: Older and Somewhat Wiser

Watch me program live every morning at 9:30 EST!

Check out past streams on YouTube!

And off we go into Month Two! As Ferris Bueller famously put it: life moves pretty fast. Wild to already be a week into startup number two.

So what is the startup this month anyway? The name of the startup product this month is Pic Story! I’ve prepared a product pitch page, which has all the details in terms of what Pic Story is, where you can get access to it, and other facts and goodies!

Failure: seeing the forest for the trees

And now for the failure of the week feature! This weird world is great at showcasing a success, but behind every success lies ten failures. In each weekly recap, I’m going to put my failures up front to show you all that stuff is hard, and it takes a lot of trial and error to get it right in the end.

My failure this week was getting too wrapped up in a … shall we say, “not-obviously-productive” Friday afternoon, and letting that overshadow the rest of my accomplishments for the week. By all accounts, I entered Month Two with guns absolutely blazing: the landing page for Plotters took several days to build, but I knocked out the landing page for Pic Story in one single morning’s work. If I play things well, once I solve one problem, I can piggyback off of that solution, and let a previous month’s work supplement and enhance future months’ work.

To see that play out in such an obvious way was wonderful! I got days worth of work done in hours. Most industries would kill for that kind of a productivity boost, and we programmers get it for free all the time!

In addition, I had awesome streaming sessions all week. I made a pretty sweet connection with another Clojure livestreamer as well: you should go check out his stream. I’m getting more activity in the chat, I’m getting more viewers, more views, and everything is on the up and up.

But on Friday afternoon, I decided to dive headfirst into this Vagrant box configuration that I’m trying to build out. One of my absolute least favorite aspects of app development is server configuration and maintenance. The programming part of my mind is so fixated on simple, pure, functional code that I get a flop sweat every time I’m forced to venture into the the weird, sticky universe of Linux Stuff. Everything is completely wack, the docs are intimidating, I don’t know where anything is, config files and log files and code files are scattered all over the place, and I’m scared to touch anything for fear of silently breaking something else.

It’s a feat to get anything done period, never mind when three weeks goes by and you have to go back and fix something. Uh … where was that thing? /var/local? /usr/local/var? /usr/etc/var/local/bin?

So I was trying to put in the time to get my turn-key Vagrant config finally finished after weeks of frustrating afternoons, wondering if I’m already in over my head in terms of time spent vs. time and money saved, lusting after Heroku and wondering if those steep hosting fees could be worth it after all. The hour grew late, and I had to shut down for the week on a down note, task left unfinished and with more questions than answers. It left me with a sour taste in my mouth all weekend, and overshadowed all of my important wins for the week.

There are probably a few things I could do to combat those kinds of feelings. One would be to schedule an “easy win” for the very end of the week so I can be confident that I’ll end on a high note. Another would be to put in more reflection time so I can get a better sense of balance between wins and losses.

My dream state is to be able to reframe the “loss” as not a loss, but a “not yet” kind of thing. Mark Rober does a great job at explaining this “not yet” phenomenon in this TED talk. If you treat a supposed “loss” the same way you treat hitting a Goomba or missing a jump in Mario, then you can reframe it into being something that you can’t do yet, but will be able to do soon if you put the work in:

Time block planning

One big win I did have this week was getting more serious about time block planning. I’ve been slowly integrating Cal Newport’s Time Block Planner into my daily routine, and when I commit to it, it does wonders for my day. (I don’t have any kind of promotional relationship with Cal Newport or the planner, I just really like it).

One effect that time block planning has had is that I can approach my day much more calmly if I spend the first part of the day planning things out. Given that I’m a one-man operation, there is a lot of stuff to do in any given day or week, and our amazing-but-limited human brains can only hold on to four or five things at once. Which means that every time I have more than four things to think about, I start to get nervous. Even if I only have seven things on my agenda, my brain can’t handle that many spinning plates at once, and so seven things can start to feel like 500 things very quickly.

When I get it all out of my brain and into a schedule, however, all of a sudden I can see that everything fits on a single page, and everything has its allocated time block. Everything is accounted for, and everything has a place and time. My mental picture of my agenda transforms instantly from a dark, swirling storm cloud into … I dunno, like a little box with three marbles rolling around in it: something un-threatening and manageable. Something I can control.

The other thing it does is gives me a way to feel good about what I get done in a day. Again, when my tasks are a shapeless blob in my mind, I can get 80% of the tasks done but still not feel very good about my productivity, because I can’t see that I got 80% of them done. But when I schedule them out and make deliberate choices about what I’m doing and how much time I’m going to allot to each thing, I can see exactly how much I’m getting done, and anything that doesn’t get done was probably something that I consciously decided I didn’t have the time for.

The one thing that I find myself resisting sometimes is spending time on planning in the first place. After all, that half-hour I spend doing the planning could be spent on the actual work itself. Wouldn’t I get more done if I had an extra 30 minutes? Well, maybe, but then again, I would be missing out on all of this:

• The opportunity to prioritize my tasks and reflect on what’s important to do
• The focus that comes from knowing that in any given block of time, there’s only one thing I need to be doing
• The feeling of calm I get from the structure that planning gives me

I have to think that I’m getting way more out of it than I’m putting in when you consider all of that 👆

Daily warmup exercises

I’ve been doing a new thing in the stream: daily morning warmups. Seeing as I’ve been programming in Clojure for all of five weeks now, there’s a ton of stuff that I still don’t know about the language, and there are a lot of skills and techniques for me to acquire.

This gets back to the idea that “wasting time” on planning is really winning you productivity; by “wasting time” on a morning warmup, I’m really getting an improved skillset in exchange. The tricky thing is that these skill improvements can be practically invisible. Once you achieve a certain baseline level of skill at anything, it becomes hard to see what your limitations would have been if you didn’t have that heightened skill level in the first place. You’ve achieved a new baseline, a new sense of “normal.” As Greg LeMond said of bike racing:

It never gets easier, you just get faster.

By Steve Selwood - Own work, CC BY-SA 3.0, Link

In the end, I’ve always felt that spending time on education has always been worth it. I always get more value out of learning something relative to the time I spend on it. The cranky little bean counter in my head will often push back against spending time on warmups, but all you can really do is tell that guy to shut up and accept the fact that the value is both totally worth it and is intrinsically difficult to notice or measure. Bean counters hate stuff like that, but what can you do?

Outlook for the next three weeks

I think I’ve got a much more realistic scope of work this time around. I was watching this talk over the weekend, which is about a Clojure-based game development platform, and the presenter says this about making games:

“A game is the hardest thing in the world to make … it’s like solving every difficult problem in computer science 60 times a second”

Granted, I wasn’t trying to build a first person shooter or anything crazy like that, but Plotters was still a fairly complicated concept so far as the nuts and bolts are concerned. It was a pretty big ask to whip that thing into a functional state in a single month, especially as a new Clojure developer.

This time around though, the product is much simpler. The basics of what I need to do seem obvious: all I need is the ability for a user to create basic, one-dimensional layouts, and to add basic images and basic blocks of text. After that, if I want to get more elaborate – e.g., layouts-within-layouts, image effects and filters, overlays, etc. – I will need to have completed the “basics” first. This sets me up with a more natural progression of work, and an obvious rubric for sorting things into “need to have it now” and “would be nice to have, but not yet.”

So I feel better about the scope, and I feel stronger in the language too! I’m starting to enjoy the fruits of REPL-driven development, I’m getting more comfortable with interpreting errors when I encounter them, and just feel more comfortable coding in Clojure in general.

Strong vibes my friends, I’ll see you next week 💪

- Andy