Last year I attempted to build in public - doing this alongside my full-time work and family commitments was tiring and in the end I couldn’t be arsed. It was annoying. Everything I was doing was being framed as “how can I package this up as content” or “how can I get people to engage with this”. It didn’t sit well with me and it was exhausting.

So I’ve been thinking if I could come up with a system to still be active on social, share things that may be useful to others but with the minimum of effort (I’m a big fan of minimal effort). With that I’m starting my own little SaaSE experiment - Social as a Side Effect - I’m going to be creating a system that automates and shares content that I would be creating for myself anyway and sharing it if it is even the tiniest bit interesting.

• I already document and save links I find interesting to Pinboard - what if I automatically tweet the ones that I think others will find useful?
• I already document some of the automations I use so I don’t forget - what if they can be useful to others? Could I share this documentation with a small amount of tweaking? Could the ideas I write down or journal about be shared?
• I already summarise the books I read and take notes - what if these could be helpful to others?

So I’ve started that from today. In fact I wrote this in Obsidian and my system has shared to you without me doing a thing. Like I’m some kind of freakishly cool robot from the future.

Working on a side project sometimes feels like walking through treacle. Especially when you have commitments that take priority time wise - for me it’s my full time job & family. I am definitely the tortoise rather than the hare when it comes to side projects - and that’s ok.

I’ve learnt changing my perspective is magic. I can change the reason I am working on a side project in an instant. The reason for me nowadays isn’t having it make shed loads of money (that’d be nice) or to have millions of users. It’s for me to learn, be creative and build something I love (and hopefully others will too).

Instead of having a goal of launching my side project I have a system. The system is simple - work on it a little bit every day. This way I am constantly winning. In one of Scott Adam’s books he wrote that when we use goals to measure success the best you can hope for is to be in a state of presuccess failure. I want to be joyful every day when I work on something in my spare time - else what’s the point? Working like this has led to me being excited to work on it and this in turn enables me to work consistently day after day over a long period of time (in the little spare time I do have).

When using a system we need to have faith that it will work. It’s often the case that we don’t know it’s working until we’ve been doing it for a decent amount of time. The Valley of Disappointment is what James Clear calls the period when the outcomes of your system are not meeting your expectations - but things will often change if we just hang tight and keep on doing what we’re doing. I have to remind my self this daily. I’m kind of impatient.

With systems we can define what success means for us - for me it’s learning, being creative and the joy you get from making things. Paul Jarvis says a similar thing in Company of One when defining growth for your business: “start small, define growth, and keep learning”.

By consistently applying your system every single day the journey becomes more fun than the goals. Goals become a byproduct of your system.

When using Bubble I couldn’t find a decent icon button plugin so I made one using Font Awesome and Bootstrap. I thought others might find this useful so I created a quick video.

Shared - HTML Header

<link href="https://maxcdn.bootstrapcdn.com/bootstrap/4.3.1/css/bootstrap.min.css" rel="stylesheet">
<link href="https://cdnjs.cloudflare.com/ajax/libs/font-awesome/5.9.0/css/all.min.css" rel="stylesheet">

Elements - initialize() function

function(instance, context) {
	var btn = $('<button id="but" class="btn"></button>');
  instance.canvas.append(btn);
  
  function clickHandler(e) {
      instance.triggerEvent("click");
      e.preventDefault(); 
  }
  btn.on('click', clickHandler);  
}

Elements - update() function

function(instance, properties, context) {
	var btn = $(instance.canvas.children()[0]);
  btn.addClass("btn-" + properties.type);
	btn.html('<i class="' + properties.icon + '"></i> &nbsp;' + properties.text);
}

I don’t like shipping personal work. Even writing this is hard. I think it’s a heady mix of fear of failure, change and being called out for the imposter that I am. Or it might just be my flare for the dramatic. Who knows? All I know is I can ship for other people all day long (this is good as that’s my job) but when it comes to doing projects for myself it’s always harder. It’s strange as I love making things. It’s the best.

I find adding a layer of automation between myself and the actual shipping helps. It’s took a long while for me to figure this out. For example: I now use a build process for this blog that removes me from actually hitting the publish button. It means I can just push this markdown file to a git repo and then some time during the night it will get published by a fearless build process. Magic. Then at some point next week WHEN I LEAST EXPECT IT I will tweet about it (without me doing anything and once I’ve forgotten about it). You may even have arrived here via that tweet.

I love the idea of using no-code tools to make mini-apps for your team (and other teams). I knocked together a quick video manifest parser using Bubble and Node.js. A developer could do this on the command line easily but I love being able to open up these type of tools to people who aren’t quite as technical.

This tutorial shows you how to create a Bubble plugin that uses server side actions.

What do we want to achieve here?

• An app that we can pass in a url of a DASH or HLS manifest
• The app outputs the parsed manifest to the screen

How are we going to do this?

• Create a Bubble plugin that takes a url paramater input
• The Bubble plugin should download the manifest from the url
• The manifest should then be parsed using server side actions using either m3u8-parser (if HLS) or mpd-parser (if DASH).

Create a Bubble plugin

• On Bubble go to My Plugins page and click New plugin
• Name your plugin something catchy. I called mine manifest-parser. Super catchy.
• Fill in your plugin general details.
• On the Actions tab click Add a new action. Name your action in the popup. In the drop down for Action type select Server side. This is where you can start using the power of Node.js. Exciting.
• Now we need to pass a couple of parameters to our server code. These are going to be the url of the manifest and the streaming protocol (DASH or HLS). In our server code we will load the url and parse the data loaded with the respective parser (https://www.npmjs.com/package/m3u8-parser for HLS and https://www.npmjs.com/package/mpd-parser for DASH). Fill in the Fields section like this:
• By doing this we are able to view these params in our test app. I have a Parse button, an input for the url and a dropdown to select HLS or DASH in my test app. Go to the app you are testing your plugin in and attach a workflow to a button. Now on the workflow you will be able to select your plugin from the Plugins menu. Beautifully illustrated here:
• Now as part of the workflow I can pass in the values from my manifest URL input and the HLS/DASH dropdown, like so:
• Yes! Time for the fun part. Running the server side code and utilising Node.js packages. Hop back into your plugin project. In the Returned values section add a parsedManifest key to be returned (this will contain a string representation of our parsed manifest - I guess that was kind of obvious from the name)
• This is the bit that seems to trip people up - doing an asynchronous call from the run_server function. The below is the basic outline of how to do this. (you’ll notice your dependencies are automatically updated - make sure the This action uses node modules checkbox is checked).

function(properties, context) {

  const fetch = require('cross-fetch');
  var url = properties.url;
  let manifest = context.async(async callback => {
    try{
      let response = await fetch(url);
      let plainText = await response.text();
      callback(null, plainText);
    }
    catch(err){
      callback(err);
  }});
  return {parsedmanifest: manifest}
}

• Now create a textfield in your test app. I use a custom state from the workflow to display the return value of the above:
• Hit Preview and run your app. Drop in any url and it’ll display the source as a string in the text box - magic! Now all we have to do is flesh out the server-side code a bit and we’re done. Update with the code below and try dropping in a manifest url and running the app.

function(properties, context) {

  var m3u8Parser = require('m3u8-parser');
  var mpdParser = require('mpd-parser');
  const fetch = require('cross-fetch');

  var url = properties.url;
  var isDashProtocol = properties.streamingProtocol === 'dash';
  let manifest = context.async(async callback => {
    try {
      let response = await fetch(url);
      let plainText = await response.text();
      if(isDashProtocol) {
        var parsedManifest = mpdParser.parse(plainText, url);
        callback(null, JSON.stringify(parsedManifest, null, 2));
      } else {
        var parser = new m3u8Parser.Parser();
        parser.push(plainText);
        parser.end();
        callback(null, JSON.stringify(parser.manifest, null, 2));
      }   
    }
    catch (err) {
      callback(err);
  }});

  return {parsedmanifest: manifest};
}

Changing the way I look at things has been one of the most powerful and insightful things that I have done. I used to run a lot. Then I got fat and didn’t run a lot. When I ran a lot it was always for a goal - a half marathon or to hit a certain weight. This wasn’t sustainable for me over time and I didn’t find it fun (which is massively important for me).

Over the past year or so I have been running for a different reason. I now run today so that I can run tomorrow. I’ve been thinking a lot about Infinite Games and Systems over Goals and this fits into that way of thinking.

There was a point a got so unfit that running was becoming harder than hard. It hurt. But applying this system of running (or exercising) today with the only goal to be able to run (or exercise) tomorrow it has become fun and easy. I love it. I don’t give myself a hard time and I’ve kept it up for over a year and lost over 30kg with it. I’m never going to win any races but I’m definitely a happier tortoise than I was a hare.

If you are stuck in a rut and don’t think you are making progress focus on your habits and your current trajectory rather than how close you are to your goals (as this can be disheartening and might prevent you from even trying).

Try and remember that it’s not where we are, it’s where we’re going. If we can change our habits and systems to change our trajectory that is often better than being closer to our goals and plateauing.

Don’t worry about the past - it’s done, it’s one thing we cannot change. But we can change the future. Give yourself an edge by honestly evaluating your situation, looking at the choices you get to make every day and choosing the best one for that situation. If we make the right choices time after time we can find ourselves in a very different situation in a years time.

I saw this on reddit and thought it was too good not to write down as a gift to my future-self.

You should think about yourself as three different people - the past-you, the present-you and the future-you.

Be grateful and forgiving to the past-you. You should thank the past-you for doing things that have put you in the position you are in today. You should also be forgiving of the mistakes the past-you made, as you would forgive a good friend.

The present-you is where the magic lies. You can’t alter the past-you, but you get to shape the future-you. Do things as the present you that the future-you will be grateful for. Choosing between the couch and the TV? What will the future-you thank you for? Do that. Want to sit down and do some work on that side project you’ve been threatening to do for years or sit and veg? What will future-you thank present-you for? Do that. It’s easier doing a good turn for someone else.

When you become future-you remember to be grateful for past-you for all the good things past-you did. Past-you is pretty sweet. I like to picture past-you on a penny farthing.

I have this sleep thing which is one part hilarious one part terrifying. When I’m in the first stages of sleep I have a startle reflex that makes me jump up in bed and start screaming at the slightest noise (even if I make the noise myself). Vicky my partner is often woke by me yelling “HELP, VIC” and it leaves me totally confused and thinking I’m dying. Every. Night. For 12 years.

Recently I’ve found a way of pretty much stopping it altogether. I’ve put together a cheat sheet below of how I stopped the old SLEEP SCREAMS. It’s a combination of information from Shawn Stevenson’s Sleep Smarter, Hal Elrod’s Miracle Morning, web research and personal anecdotal evidence.

Sleep Cheat Sheet 1.0

1. Get up nice and early (I tend to get up between 5:30am - 6:00am)
   • Meditate.
   • Get outside. Natural light exposure triggers the production of more serotonin. The best time to get natural light is early in the morning - 6:00am - 8:30am for at least 30 minutes.
2. Exercise
   • Lift heavy if you can bro. If not go for a walk or run - try to do this around 7am.
     • Use topical magnesium on anywhere that is sore before going to bed.
3. Eat well
   • Alcohol - cut down or pack it up.
   • Cut carbs and sugar.
   • No caffeine after 2pm.
   • Use magnesium supplements.
4. Winding down
   • Take a hot shower or a bath 90 mins - 2 hours before going to bed. After that wind down with a cup of camomile.
   • Go to bed at the same time each night. The best time to be asleep is between 10pm - 2am.
   • No screens an hour before bed. Or get some of them blue lensed glasses if you want to watch telly.
5. Bedroom environment
   • Get a fan on or open the window.
   • Get yourself a weighted blanket. I love mine.
   • Get it dark - preferably so you can’t see your hand in front of your face.
   • Use red light if needed - it doesn’t affect your circadian rhythm as much as other lights.
   • Keep your room cool.
   • Put on some white noise - I use a river on my Echo - running water actually slows your heartbeat.

And one that I think is the most important. If you can’t fall asleep, don’t stress about it. It is what it is.

Over the course of the last month a lot of teams have gone from working in the office to working remotely. Teams have had to adapt quickly to the new situation and it’s nuances. This is my take on running a distributed team.

My current team was semi-remote - half of us were in the office, the other half spread across multiple timezones. I was based in the office so was involved in daily chit-chat about product and roadmaps - but since being remote I’ve noticed just how much of this I would’ve missed if I was remote. I’m currently dogfooding our remote culture and I’ve noticed a few places we’ve come up short.

The daily standup

Having people located across timezones meant we needed to have a standup time where everyone could attend - this was around 4pm everyday OT (office time). After reading this article by Jason Fried I proposed doing standup asynchronously over Slack - we did this for about 9 months. I was pretty happy with it - everybody got to update their days without being interrupted. The Slack channel was public so anyone else in the company who was interested could come and have a read.

Then I tried this async approach whilst being remote full-time. I had previously WFH one day a week but I hadn’t experienced being fully remote for any period of time. I found I missed interacting with the people in the office, I missed chatting and just connecting with my team mates. We’ve since implemented a standup/knowledge share/general hangout combo each day over Zoom at a time that is convenient for all - it generally lasts 15-30 minutes and in that time we let everyone know what we’ve been working and also discuss anything that comes up (we tend not to take it offline but talk it out there and then). So far the team likes it and the previously-fully-remote team members think it’s an improvement. This Zoom meeting is open to anyone in the business who is interested or who wants to discuss something with the team.

Slack etiquette

The way we use Slack hasn’t changed since we went into forced-remote mode. We try and use Slack asynchronously - we don’t expect answers right away. We have a pinned message setting expectations about the way we work:

I personally also turn off notifications and badges and minimise Slack whilst I am working. I also use encourage the use of Do not Disturb mode after hours (I tend to check-in in the evenings and people are able to force a notification to me if urgent).

Zoom/conference calls

Headphones with a mic is handy (rather than laptop speakers/mic) and we also mute when others are talking. I know## there is a bit of thought that everyone should not mute but get better headsets but I think with kids around due to homeschooling that might be tricky - I know it would be for me with my kids.

Managing your team

I’ve found the best way to manage a team remotely is similar to how I manage the team in house - giving trust and responsibilities whilst ensuring psychological safety for the team to discuss anything small or large. My team is awesome, they are skilled and driven. I bet yours is too. I’ve never been a bums-on-seats manager - If I can’t see you working then you aren’t working is not my style and would be hell in the current situation. I can imagine micro-managers aren’t having a great time of it currently.

LISTICLE TIME - top tools we use for remote work you might find useful

• Slack
• Zoom/Teams/Slack video/Google hangouts - video conferencing
• Droplr - I use this every day for screenshots or sharing video
• Zeplin - great for design teams to distribute designs and assets to devs
• Decent headphones/mic
• Jira or ticket tracking software so work is well documented and easy to pick up - this seems obvious for software teams but may be a new concept to those not in the software industry.
• one of these for emergencies