Books of 2014

Didn’t read as much as I wanted/hoped this year.

  • The Millionaire Fastlane (3/1/2014)
  • How to Fail at almost Everything and Still Win Big (15/1/2014)
  • Hooked: How to build habit-forming products (26/1/2014)
  • The Power of Habit (23/2/2014)
  • Go for No! (25/2/2014)
  • All that is Solid (31/3/2014)
  • Manuscript Found in Accra (1/4/2014)
  • Fluent in 3 Months (23/4/2014)
  • David & Goliath – Audiobook (25/4/2014)
  • Be Iron Fit (27/4/3014)
  • No Exit (5/4/2014)
  • The Obstacle is the Path (10/6/2014)
  • The 1 Hour China Book (16/6/2014)
  • Beyond Training (10/7/2014)
  • On the Shortness of Life (18/07/2014)
  • Software as a Disservice (7/9/2014)
  • How to fix Your Software Project (15/9/2014)
  • Growth Hacking Handbook (Skimmed) (10/10/3014)
  • The Martian (21/10/2014)
  • How to Get to the Top of Google (Skimmed) (31/10/2014)
  • Smart Calling (Skimmed) (31/10/2014)
  • The Three Body Problem (26/11/2014)

This year’s stand out books were “How to Fail at almost Everything and Still Win Big”, “All that is Solid”, “The Obstacle is the Path” and “The Three Body Problem”.

Not so remote

Fostering a team feeling when everyone is remote can be extremely difficult. It’s easy to feel like you are working in a total silo, and can be made worse if everyone is spread across distant timezones. Being able to function as a team is a key component to project success. Feeling isolated and alone when problems come up can make work frustrating and stressful at times. Here are a few ways to try and overcome that:

  • Try and arrange core hours where the whole team is available and together on Skype/HipChat/Slack.
  • A weekly call with everyone to update on work, issues and client feedback.
  • A daily call between project managers and members of the team to chat about current progress and the project as a whole.
  • Code sharing sessions. Show code to other members on the team and explain what features are and how you’ve gone about implementing them.

Move fast and break things

I was thinking about the “Move fast and break things” approach to projects this morning. A few projects I’m currently working have been moving at a snails pace and the longer projects go on and the bigger they get before being launched fills me a certain kind of dread. I feel really comfortable launching with a few half baked features rather than everything in one big bang. When there are so many moving parts in a launch, no matter how much you test, real users are going to find problems, and trying to keep on top of them can drive you insane. It’s the difference between trying to steer a small sail boat vs a cruise liner. If you start small you can probably respond quickly to change and get to where you want to go than if you launch big and try and change course later on.

Now I don’t condone breaking things, but I do agree with the idea of moving fast and staying agile. So just “Move fast”, that’s all you have to do. Accept that things will break and things will need improving.

“A good plan violently executed now is better than a perfect plan executed next week.” – George S. Patton

Generate a random email address in TextExpander

Made this short snippet to help generate random email addresses using TextExpander. Set the snippet content type to “Shell Script” and paste in the following. You’ll need Ruby installed which comes with most modern versions of OSX.

The snippet will generate a different address every minute and copy it to your local clipboard incase you want to paste it in again. It also uses YOPMail which you can check for emails too.

Hard Deadlines

On almost every single project I’ve worked on, hard deadlines have nearly always been the cause of any stress or frustration that arises. One day you’re asked to make rough estimates and then next thing you know they become pegged to a date in the future that you must meet at all cost (But you said you think it would only take X days!). Even worse is when someone non-technical makes the estimates for you and passes them down from on high (Look, this is the all the time we have, I’m sure you’ll be fine!).

Why do we still insist on having hard deadlines? Yeah I know, we asked for more features but now the project is “late” so you’ve failed to do your job. Yet, if the deadline wasn’t concrete, the project would have more features then initially scoped and delivered in a timely fashion, you’re a success!

New features are always requested, changes are always wanted and bugs will always be found. If everyone just accepted (understood) that writing software isn’t exact science then we’d all have a lot less stress to deal with and we can stop feeling like a failure for not meeting that pie-in-the-sky deadline.