DEV Community: MurrayVarey

Daily Good Times! The Easy Way To Keep A Gratitude Journal

MurrayVarey — Fri, 28 Feb 2020 20:20:04 +0000

Hands up, who’s tried to keep a gratitude journal?

The powerful effects of a gratitude journal are well documented. By simply writing down what you’re grateful for, you’ll develop a more positive mindset. You’ll become happier. Apparently, you'll even sleep better.

So why is it so difficult?

I’ve tried -- and failed -- to keep a gratitude journal many times before. Each time would be the same: The first day, full of enthusiasm. After three days I would ‘forget’ to write something. After a week I would quit, much to my relief. Gratitude journaling wasn’t for me. Or so I thought.

That changed a couple of months ago, when I was persuaded to give it one last go. Two months later, and I’m still going strong. Now I love my gratitude journal.

In a second I’ll explain what’s changed. But first let’s take a quick look at the standard gratitude journal advice.

The Typical Gratitude Journal

The typical gratitude journal goes like this:

Every day you open your (probably expensive) gratitude journal
You write down 3-5 things that you’re grateful for
You do this in the morning or evening, so that the positive feelings can power you through the day (or next day)
All your 'gratitudes' should be precise, rather than general. Otherwise you end up going through the motions
Oh, and you should reflect on each entry before you jot it down

I found that way too restrictive.

The first problem was the whole morning/evening thing. I had little wriggle room at those times of day, so I struggled to make gratitude journaling a consistent habit.

The next problem was not knowing what to write. Even when I did crack open the journal, I would sit there struggling, staring at an empty page. So I gave up ... until a book changed my mind.

The Happiness Advantage

Everything changed when I read The Happiness Advantage by Shawn Achor. Its central idea is that we have the relationship between happiness and success inverted: success doesn't lead to happiness, instead happiness leads to success. It's a persuasive book, and Achor repeatedly emphasises the power of gratitude journaling.

Then he dishes out one piece of advice that goes against the typical gratitude journal tip. It was enough to get me rolling.

Gratitude At Work

The advice in The Happiness Advantage was this: write your gratitude journal at work. Set a notification at 11am for doing this. That's it.

This may seem obvious, but it was exactly the tip I needed. I couldn't squeeze journaling into my already-crammed morning/evening routine. I am able to make the time in the middle of the day.

Now you might be thinking: I can’t stop work in the middle of the day to write a gratitude journal. I had the same concern, but actually it wasn’t a problem. After all, taking five-minute breaks is something that you probably do quite often (particularly if you’re timeblocking, like the Pomodoro technique).

This worked well for about a week ... but then I noticed that gratitude journaling was becoming a struggle. Rather than making me feeling positive, it felt like a drag. Whenever that notification popped up, I would groan inside.

That’s when I started to change things.

The Rename: Daily Good Times!

The first problem, I realised, was the name itself. ‘Gratitude Journal’ doesn’t click with my brain. It's too sincere, too cheesy. It felt like homework!

The solution? A rename. I needed something that would light me up.

After experimenting with a few names, I landed on Daily Good Times! Now, when that notification pops up, I’m inspired to write things down and feel happy about life. I picture summer afternoons walking through a park, sun shining, people dancing, usually a group of drummers sat in a circle. (That might be some people’s idea of hell … but it works for me.)

Find a name that lights you up. Your journal, your name.

Capture Awesome Moments

So you've got your rename. The next question is: What the hell do I write?

In the past, I would sit with my journal and ask "What am I grateful for?" For a cynic like me, this soon became a struggle. Any joy -- any gratitude -- was gone. This was a problem.

Luckily, the answer was in the name Daily Good Times! I started capturing, well, good times. This was a game-changer.

My advice for anyone starting a gratitude journal: simply jot down moments that made you happy. They can be from this morning or from years ago. It doesn’t matter.

Daily Good Times! is filled with:

Awesome nights with friends
Hilarious/dumbass conversations with my kids
Great things that happen at work
etc.

Focusing on moments brings so many advantages:

Easy: Unlike some gratitude journal prompts, writing about moments doesn’t take a huge leap of imagination. If it happened and it brought you some joy, then it counts.
Specific: One of the keys to a gratitude journal is being specific. By definition, writing about moments does this.
Moment Album: Over time, your journal becomes like a photo album, but for moments instead. It's there to revisit whenever you need.
Clock-able: I soon realised that I was clocking good moments as they happened -- partly so that I would have something to write. “Is this cheating?” I wondered. Of course not! The whole point is to look for positives. Far from cheating, it means that the journaling is working.

You might think “I don’t have any good moments to write about”. If so, great -- you will definitely benefit from this exercise. I guarantee that there have been some positive moments in your past, however small -- a friendly gesture or a fun conversation. It might take some effort to think of these, but it will get easier as you work out your positivity muscles. And then you’ll be flying.

Develop Other Prompts

Once you've grown the journaling habit you can develop some more writing prompts. Here are some of mine:

Bad Times (with a Positive Twist): Take a bad thing that’s happened, and try to look for a positive take on it. This is tricky at first -- it’s like the ultimate positivity workout. But you'll soon start to look for the good in everything. Example: I recently fell over while running, badly scraping my knee. It was nasty -- there seemed to be no positive spin. After a bit of thought, I turned this into an Injury Comparison bonding session with my 5-year old.
Read about Others’ Lives: Reading about other people’s lives can be a source of inspiration. It can give you a direct contrast with your life, and make you reflect. Example: I was reading read Trevor Noah’s fantastic autobiography, “Born A Crime”. In it, he talks about growing up without proper water. This gave me a lot to think about.
Repeating Ain’t Cheating: Are you allowed to talk about something twice (or more)? Damn right you are! Revisiting those good moments is a great thing. So long as it doesn't become rote.
Sneaky Affirmations: Sneak in moments that remind you that you’re awesome. Boss said you're doing a great job? Write about it, and expand on what you've done well.

Quick Tips

Here are a few other tips that I've found useful:

Write As If No One’s Reading: The saying goes “Dance as if no one’s watching.” The same is true for a gratitude journal. Don’t get bogged down with thoughts like “What if Ellen reads this?” (a) she won’t, and (b) you’re writing about good times, so she’ll probably appreciate it. Good times often involve other people, and so you should feel okay to write about that.
Be Relentlessly Positive: For me Daily Good Times! is a Positive Only zone. After all, it's like my optimism gym. There are plenty of places in my life to be balanced or considered -- this ain’t one of them. Sure, some of the things I write make me sound borderline hippy-dippy insane. But remember: Thank as if no one's reading!
Pick a Format that’s Convenient: Digital or paper? Don't get hung up on it. Do whatever works for you.
It Doesn’t Have to be Daily: Don’t feel pressured to write in the journal every day. Doing so can add to the grind. Twice a week will still give you those benefits. (And you can keep the name Daily Good Times! … because it’s your damn journal.)
Fewer Items: You might find that 3-5 items is too many. In that case, start off with 1. The main thing -- particularly when starting -- is to make it easy for yourself.
Reread Your Good Times: Soon, you'll have a collection of your awesome moments. Any time you need a pick-me-up, then it will be there to read over.

Have Fun!

The main lesson is: Do whatever you can to make gratitude journaling fun. For example, decorate your journal. If images are your thing, then post them in there. It all counts!

Does It Work?

So does gratitude journaling -- or Daily Good Times! -- work?

Hell Yes!

For me, the positive workout is almost life-changing.

Let’s use an example: recently, my car died. Previously, that would have seemed a disaster. Juggling work and child care proved a challenge, not to mention the costs. However, through writing in Daily Good Times! I started to find positives -- friends who helped out, improved knowledge about cars (check your coolant level, folks!), the fact that it wasn’t that bad. Life moved on.

This has been the general pattern. I feel more in control.

(And if you’re cynical about that … then you definitely need to try gratitude journaling.)

Wrap-up

Gratitude journaling changed for me once I decided to make it fun. The key was

Keeping a consistent time (this can be at work), and
Focusing on Happy Moments

If you've struggled with gratitude journaling before, give it a try. And remember: have Good Times!

Have you kept a gratitude journal? What worked for you?

(Header Image from Pixabay Photos)

What The Heck Is Git? (A Rundown for New Programmers)

MurrayVarey — Wed, 12 Feb 2020 22:32:50 +0000

TLDR; Git is an incredibly powerful tool for any developer. It will help you in many ways. Git can be complicated at times, but don't let that put you off.

If you’re new to programming, you're probably wondering: What the heck is Git? Or -- based on people I've spoken to -- you've never even heard of Git. Both of these are completely understandable. After all, Git is rarely mentioned in most beginner tutorials.

My aim for this post is to explain what Git is and why it is so useful. To keep things simple, the post will be light on Git commands. By the end, I hope you’ll have a feel for how Git can help you today and in the future.

Let's get to it.

What is Git?
The Problem: Files Everywhere
The Solution: Version Control
What Makes Git Special?
The Down Sides Of Git
Common Concerns
Useful Links

What is Git?

In short, Git is a version control system, used by millions of developers around the world. Git is an incredible tool -- many programmers (myself included) wouldn't work without it.

But that is a terrible answer. For a new programmer, the term ‘version control’ is meaningless.

So, before diving into Git, we should first look at version control and the core problem it tackles. This is a problem that you’ll likely have experienced already.

The Problem: Files Everywhere

It’s a common scenario. You’re beavering away on a project and are happy with the code as it stands. It looks slick, and its features work nicely.

But there’s a problem: you need to make a change. This change is a big one, and might break the code that you’ve worked so hard on.

So what do you do?

If you’re anything like I was at first, you’ll make a copy of your file:

hatShop.js
hatShop_v2.js

Now, if your change does break everything, you can go back to the original version. Great, right?

Well yes … and no.

This system -- we’ll call it manual versioning -- works up to a point. However (as I learned the hard way) you soon run into a world of pain. Pain such as:

You soon create another backup file. And another. And another. Before you know it, your directory is flooded with different versions of the same file.

hatShop.js
hatShop_v2.js
hatShop_final.js
hatShop_actual_final.js

Adding a file to the project is dangerous. With every new file, the complexity shoots through the roof. And how can you keep these files in sync?

capShop.js
capShop_v2.js
catShoop_.js

hatShop.js
hatShop_v2.js
hatShop_final.js
hatShop_actual_final.js

When your code breaks, it’s damn near impossible to identify which change did the damage. You end up making extra backup files so you don’t break anything during your investigation
Your files are littered with commented-out code, because you don’t want to forget anything that might prove useful. This becomes noise (and it never proves useful)
If you're partway through a feature and need to suddenly work on, say, an urgent bug ... well that means even more version files
Horror! You start working with another developer, and you both want to edit the same file. How do you avoid trampling on each other’s code?
Someone else has made a difficult-to-understand change in the code, and has gone on holiday. WHAT WAS THAT CHANGE SUPPOSED TO DO?

By the end, your folder looks something like this:

capShop.js
capShop_v2.js
catShoop_.js
capShop_bug_hunt.js

hatShop.js
hatShop_v2.js
hatShop_final.js
hatShop_final_with_button.js
hatShop_actual_final.js
hatShop_actual_real_i_mean_it_this_time_final.js
hatShop_from_leah.js
hatShop_now_broken.js

Fortunately for us, these are age-old problems which people have been working on for many years. Their solution? Version control.

The Solution: Version Control

Version control -- also referred to as source/revision/change control -- is software that manages changes to your code. In other words, version control takes your manual versioning system and does all the hard work for you. Version control takes a load off your mind.

There are different version control systems -- such as Git, SVN and Mercurial. Most of these work by holding a copy of your code in what's called a repository. The system tracks changes to this.

Whenever you’re happy with a change to your code, you commit that change to the repository. Each commit -- called a revision -- often contains multiple files. These commits build up to let you see and restore any changes you’ve made.

From this, version control gives you some awesome things:

Undo Your Mistakes

This is the most immediate and obvious benefit: Version control is like an Undo for your code. Except it’s better, because it doesn’t forget your changes anytime you reboot your machine.

This is amazing -- it frees you up to experiment and have some fun. Screwed everything up? No worries, just rewind back to your last commit.

Small Commits

The cost of storing a change is practically nothing. There are no backup files clogging up your directory.

As a result you could -- and probably should -- commit tiny improvements at a time. Removed some nested if-statements? Commit. Renamed a temp variable to something more meaningful? Commit. Deleted some commented-out code? Commit commit commit.

Once you get into the habit of making small commits, it becomes easy to pinpoint any specific change that breaks your code.

Version control systems only store changes. They don't make a separate copy of the file with each commit. This means you can commit as many small changes as you like without quickly taking up space with duplicates.

History of Changes

Ever found a line of code and asked: What was this line trying to do? Version control solves this problem.

Alongside every code commit, you include a message which describes the reasons for that change. This message is like a detailed code comment, with the advantage of not adding any noise to your actual code.

This means you can see who changed every line of code, when, and why.

This history builds up over time, so is something that you really appreciate as the project grows. Then -- like a kind of programming Indiana Jones -- you have a chance to rescue some code artifact from ancient times.

(I can vouch for this one, having recently dealt with a bug introduced 11 years ago. Without this code history, I wouldn't have stood a chance.)

Shared Repositories

Version control makes it easy for two or more developers to work on the same file without breaking each other’s work. This is done by merging each developer’s changes -- on a first-come-first-merged basis -- to the version of the file in the repository.

If those two changes are in different parts of the file, then this process is automatic. The same is true when developers are working on different files -- they can get other’s changes while barely lifting a finger.

Even with version control, things can get hairy. If two developers have changed the exact same part of the code, then this has to be sorted out by hand. This is the dreaded Merge Conflict, and it’s a painful fact of programming life.

Powerful Tools

Version control systems often come with ready-made tools, such as Jira, GitLab, BitBucket, and (of course) GitHub. These complement the version control system and/or act as a layer on top.

What do these tools give you? For a start, there’s the Issue Tracker which lets you record and describe, well, issues. Each issue -- generally a bug or feature -- will have an issue number, which you then mention in the commit message. This lets you trace through from Code to Commit to Issue with ease.

Add to that: task management tools, wikis, funky graphs, and whatever else you can dream up. The tools are there; version control lets you use them.

Easy Backups

One advantage of having a repository is that it acts as a backup of your project. If this is stored off-site, then you should be pretty safe from most worries.

This also makes it easy to get new teammates up and running. Simply clone your project onto their machine and hey presto. (Usually with a small bit of jiggling around … though it sure beats copying by hand.)

Synchronised File Changes

Because each commit often contains more than one file, those changes are grouped together. No more worrying about which change in file A goes with which change in file B.

Project Serenity

Gone are the many backup files that flood your directory. Gone is the commented-out code that’s there “just in case”. It has no reason to stay*.

(*Oh sure, someone can always find a reason … but it had better be good!)

Hear that? Sweet, sweet silence in your codebase. Now you can program in peace.

You get the picture. Version control is a wonderful thing. It removes a lot of the risk and stress from software development. Programming without version control is like skydiving without a parachute. Even if you survive, you’ll likely find yourself stuck up a tree.

In fact, my original plan for this article was to write about version control as a whole. After all, any version control -- be it Git, SVN, or Mercurial -- is better than no version control, right?

Wrong. I’d be selling new programmers short. It’d be like writing about search engines and not mentioning Google. Without wishing to start a flame war, there’s one clear version control system to learn: Git. Let’s talk about why.

What Makes Git Special?

“I decided that I can write something better than anything out there in two weeks ... And I was right.” -- Linus Torvalds

Git was created by Linus Torvalds -- the legendary sharp-tongued inventor of Linux -- in 2005, to help develop the Linux kernel. As the quote suggests, he set out (in his own way) to improve upon existing version control systems at that time. Many would argue that he succeeded.

Since then, Git has become the industry standard. The language of Git -- push, pull, fetch, fork, etc. -- has become everyday terminology. Git is so popular among developers that it would take a seismic shift to replace it. And that replacement would have to be something pretty special ...

So what makes Git stand out? Here are just some reasons:

Distributed System

Okay, this one sounds dull at first (particularly if you’re working solo) … but it is the core principle behind Git.

Git is a ‘distributed’ version control system. In other words, every developer has a clone of the repository on their machine -- complete with change history, commit messages, etc. This is their ‘local’ repository.

This is very cool, because it means you can commit a change to your own repository without breaking anyone else's code. It also means you can work offline, which is important for some people, less so for others.

(For the record SVN, which is 'centralised', doesn't let you do this. At least not without cheating. Mercurial, like Git, is distributed.)

From this distributed architecture other features appear, including the next one. It might be my favourite feature of Git: its branches.

Lightweight Branches

Branches in Git are mind blowing, especially having come from SVN. Git Branching was the feature that first won me over.

You can think of a branch as a new instance of your project -- effectively another repository. This lets you work on different jobs at the same time, without fear of cross-pollination.

Developing a new feature? That can be a branch. Some experimental R&D? Another branch. Need to patch up a bug? A third branch. These branches are entirely separate from each other.

Commit your changes to the relevant branch, giving you a complete history. Finally -- when you’re finished with one of them -- you merge it back to the main branch.

And boy is this easy to do in Git.

It has to be said, branches are not unique to Git. SVN has branches. The difference is in the effort involved. With SVN, branches are a chore to manage. They take an age to set up, and are a horror show to merge back.

With Git, branches are a joy. Set up and merging both happen within a blink*. The result? You use branches as nature (and Linus) intended.

(*Okay, busted. That isn't entirely true. Git still has merge conflicts -- you do have to get your hands dirty sometimes. Still, these moments are rare when compared to SVN.)

Speed

Git is lightning fast. Having moved from SVN to Git, the speed is noticeable. Even cloning a repository seems to take no time by comparison. Throw in the ease of branches and merging, and you’re laughing.

I have heard that Git struggles with huge projects with, say, millions of files. This may well be true -- I wouldn't like to be around to find out.

Project Changes

Git views changes in terms of the whole project. As a result, moving a directory (or renaming a file) in Git is simple. By contrast, SVN thinks in terms of individual files. Moving a directory (or renaming a file) in SVN is knotty, and often means waving bye-bye to your history in the process.

Open Source Community

Git is the version control of choice for the Open Source community. Its whole ethos revolves around open source.

GitHub is by far the best example of this. It is filled with awesome people doing awesome work, all for free and the genuine goodness of their own hearts. You -- yes, you -- could go on it now, and contribute to any (public) project. That’s pretty awesome.

( … And this is where I have to confess: I’m not an open source contributor. Sure I feel some guilt about it, but there is only so much you can do at a time.)

Big corporates too -- such as Microsoft and Google -- have jumped aboard the GitHub bandwagon (to the extent that Microsoft bought it). Fancy peaking under the hood of Windows' Calculator? Well you can do that right now. Please, contain your excitement. (I'll admit, I let out a little squeal.)

Powerful Commands

Git seems to have an endless supply of commands that can help a developer on a daily basis. For example, need to pinpoint which change introduced an error? Try the bisect command.

A Silly Name

For those developers from the UK -- yes Git really is called Git. You'll never get used to it. Just accept it and move on. As far as I know, there’s no version control yet called Prat or Plonker.

Switching from SVN to Git was -- no joke -- life changing. I’ve experienced the difference it makes. Once you’ve used Git, it’s tough to go back. Fortunately, you won’t have to very often.

The Down Sides of Git

Git by XKCD

Let's cut to the chase: Git can be complicated. In fact, it can be downright terrifying. Certain commands give you cause for prayer before using them. I'm looking at you, Rebase!

Git can sometimes be too clever for its own good. For example, I've never been sold on its Staging Area. Why add a second step to the commit process? (Many would disagree with me here -- I've just not found a good and safe use for it yet.)

The good news? You can get by in Git with the basics, especially when you're just starting.

Also, the tools can hide a lot of complexity. I suspect that improvements to Git will rely on changes to its tooling.

Anything else? None that I’ve encountered yet. If you've experienced more, please do let me know.

Common Concerns

Here are some common concerns about Git that I’ve come across, along with my thoughts:

I’ve only just started programming. Do I need to learn Git as well?

You got me! In this case, the answer might be no. Write code, play around and have fun.

However, the moment you write some code that you want to keep, then Git will be your lifeline.

Also, it’s worth signing up to GitHub now. There’s no harm in doing so. Have a look around. Commit a few files -- they don't even have to be code.

I’m working on a solo project. Git seems like overkill.

This can be true ... but not often. Yes, Git can feel like overkill when you’re working alone. But a lot of its benefits apply to solo projects.

If the code is truly throwaway, then setting up a Git repository might be a step too far. That's a judgement call.

I’ve heard Git is complicated

Oh indeed! Git can be confusing as hell. However, you don’t have to use its advanced features from day one. Instead, start off slowly, and commit small changes. Once you become more confident, then you can explore what else Git gives you.

Git looks like a bunch of confusing command lines

Sure does.

I’m going to admit something here: I rarely use the Git command line. Much to my shame, I cannot claim to be a Git master. And yet I still find it vital to my work.

Most of the time, I’ll use a Git GUI which hides all of this from me, such as Sourcetree, GitKraken, or SmartGit. (That said, it’s worth knowing a bit about the command line -- it can get you out of a hole.)

Git sounds expensive

Git is free! Sure, there are ways to spend money. But that’s not a worry for now. Stick to GitHub, and you’ll be grand.

I’m partway through a CS degree, and Git hasn’t been mentioned. Can it be that important?

I’ve recently come across graduates whose degrees didn’t mention Git (or even version control). As far as I'm concerned, that degree has failed you. Start using Git now -- it will help.

There must be other popular version control systems?!

There are: Mercurial and Fossil to name a couple. These might well be excellent systems (I've not used either). By all means explore them. At some point, though, you will probably need to learn Git.

I’ve been programming for years, and have never needed an old version of my code

Then you are a far better programmer than me. Please tell me your secret!

Useful Links

Ok, so you're ready to get into Git. Here are some links to get you started:

GitHub -- The Git hosting site. Sign up now.
Code Triage -- Help find an open source project
Linus's hilarious Git talk at Google

And of course Dev.to has some excellent resources, including:

Git cheatsheet for beginners

Duomly ・ Jan 8 '20

#git #programming #beginners #codenewbie

Confused by git? Here's a git crash course to fix that 🎉

Chris Achard ・ Sep 10 '19

#git #beginners #tutorial

10 Git Tricks to Save Your Time and Sanity

Jacob Herrington (he/him) ・ Aug 7 '19

#git #productivity #beginners

Git is an incredible tool -- giving you the freedom to create, change and share code. Yes, it can be complicated. Just take it easy at first. You'll soon be glad that you took the time.

Banner Credits - Banner Generator by Christopher Kade

Artwork Credits - ls.graphics

Building Habits: The One Technique That Worked For Me

MurrayVarey — Tue, 07 Jan 2020 22:39:06 +0000

Good habits are hard to build. Until recently, I had never successfully managed it. Replacing my fries with a salad? Not happening, no matter how much I tried.

However, last year I discovered a habit-building technique that sounded like it might be effective. Upon reading about this -- in James Clear’s awesome book Atomic Habits -- I jumped on it straight away. Before long, I had developed habits that — shock — actually stuck around.

What is this powerful technique? It’s called Habit Stacking.

Habit Stacking

The idea behind Habit Stacking is simple. In order to develop a new habit, all you do is:

Take an existing habit (or automatic activity) and then
Perform that new habit afterwards

In other words, your existing habit becomes a trigger for the new habit.

For example, here are some habit stacks that I’ve built into my own life:

Bedroom > Charger Stack

Aim: To stop reading my phone in bed

Method: When I (a) walk into my bedroom, I (b) put my phone on charge in the other corner of the room.

Bowl > Bottle Stack

Aim: To drink more water throughout the day

Method: When I (a) wash my cereal bowl at work, I (b) fill a bottle with water.

Run > Healthy Lunch Stack

Aim: To eat healthier food

Method: After I (a) finish my lunchtime run, I (b) buy a relatively healthy lunch (rather than the turkey sandwich that I would buy otherwise)

It’s easy to see why this technique is effective — each of us has any number of habits built into our daily activities. My trigger habits are so simple that you might not even call them habits at all. Still, I am guaranteed to do them on most days, which makes the habit stacking easy to do.

(And for those of you thinking “That’s not a Stack” … I hear you! It’s more of a Habit Linked List. Not as catchy though.)

Reverse Engineering a Habit Stack

I admit, habit stacking sounds a little obvious. In fact, you likely do some form of it already. Maybe, once you (a) step into the shower, you (b) oil your viking beard while singing a Disney medley. We all have these little stacks built into our routines.

So what’s the big deal? For a start, often the so-called obvious is worth highlighting. After all, I hadn’t figured out habit stacking for myself, obvious as it may be.

More importantly, by giving habit stacking a name, the concept starts to solidify. It becomes a conscious thing. And that’s where the power lies: you begin to look for opportunities to create a stack. In other words, you can reverse engineer the habit you want to build. Now we’re talking my language!

When you think about it, there are so many triggers to stack a habit onto:

Waking up
Turning your light on
Drinking your soothing morning tea
Shouting abuse at your neighbour’s cat (not enough tea!)

The opportunities to build a habit stack are there. You just have to look for them.

Stacks Upon Stacks

Here’s another great thing about habit stacking — once you have a stack, you can keep adding habits to it. Habit stacking has a kind of recursive quality. Because of this, you can link together a number of tiny habits. When performed in sequence, these can add up to something huge.

Here’s a small habit that I recently added to my Bowl > Bottle stack. Once I’ve filled my bottle with water, I then go to my desk and — first thing — drink a glass of water. The stack has now become Bowl > Bottle > Drink. It’s a tiny addition, but it gets me started.

But this comes with a warning: Don’t overstack. Once you have too many things going on, the stack can feel like a checklist. The ‘habit’ element has gone and it’ll no longer be automatic. Chances are you’ll not do it.

Keep the stacks small, and they will flow.

Solid Foundation

To be a success, each habit stack needs to be built on a solid foundation. In other words, that initial trigger habit has to be automatic. If not, the whole thing falls down.

I learned this the hard way with my first attempt at creating a water drinking stack. The idea was to base my new water drinking habit on the Pomodoro technique. This is the timekeeping method I’ve been using which, in short, means working in 25 minute blocks. My plan was, after every other pomodoro — approximately once an hour — to get up and fill a glass of water.

This sounded great, but there was a tiny problem: most days I forgot to use the Pomodoro technique. Remember how I said I was bad at habit building? Well, the Pomodoro technique is one such example. The rest of the stack was always going to fail. I was never going to drink that water.

Washing my cereal bowl? Now that’s automatic, otherwise that bowl is staring me in the face all day, caking that cereal into cement. As a result, that water bottle is getting filled.

Keep The Habits Linked

Here's another reason that my Pomodoro > Water stack failed: The Pomodoro did not link — in any way — to the Water. So, even when I did remember to turn on that Pomodoro timer, I still forgot to fill that glass.

There should be a link between the two habits, such that the second habit practically jumps out of the first. These links can come in a variety of forms. For example:

Visual link — “Hey, there’s my phone charger, let’s plug my phone in” (Bed > Charger stack)
Themed link — “I’m feeling healthy after that run, better keep that up” (Run > Healthy Lunch)

This is where multiple stacking can come in handy. If there is no link between habits (a) and (b), then you can build a linking habit. This could have saved my Pomodoro > Water stack, if I had developed the habit of walking around after every pomodoro. Then, occasionally, that walk could have ended up at the water cooler, making the water bottle is easy to fill. I would have a Pomodoro > Walk > Water stack.

The Dark Side of Habit Stacking

As with any force for good, habit stacking has a dark side. Again, most of us already do this without realising. How often do you check your phone and instantly open up Twitter (or even Dev.to)? If so, you have a Phone > Twitter stack.

Ah ha — but there’s good news! Once you’re aware of it, you can change the stack. Perhaps you could flick to a photo of loved ones instead. Or someone you don’t like — then you’ll stop doing it!

There we have it. Habit Stacking, the one habit-building technique that’s worked for me.

If you’re looking to build a habit, give this a try. Just make sure the foundations are stable, and that the habits are linked. You’ll be a habit-building machine before you know it.

Do you have a favourite habit-building technique? I’d love to hear about it. (And will it stop me from eating fries?)

Books I Loved in 2019

MurrayVarey — Sun, 29 Dec 2019 23:13:30 +0000

I love a good reading list … possibly even more than actual reading itself. With that in my mind, here's my list of the books that I most enjoyed in 2019. In no particular order:

Atomic Habits by James Clear

I have recommended Atomic Habits to just about every human — and the occasional tame animal — I’ve met this year. James Clear’s book is full of practical advice on how, and why, to change your daily habits. And by ‘practical’ I mean I have actually used the advice in this book … which is so rare for this genre. Also rare for this genre: Atomic Habits is very well written.

Give and Take by Adam Grant

Nice folk can finish first, and Give And Take explains how. Crucially, author Adam Grant also explains how to avoid that all too common nice-person trap: becoming a doormat. After reading this book, I at least wanted to become more generous … even if my lazy nature seems to be winning out.

Hello World by Hannah Fry

A pop tech book on algorithms. With jokes. Where Hello World is light on technical details, it is strong on clearly describing how algorithms run our world. Hannah Fry's examples range from tragic to funny, all of which makes for an engaging read. Worth reading even if you’re an expert (which I’m not!), just to get ideas on how to express these concepts to the less informed (which I am!).

Show Your Work by Austin Kleon

Show Your Work is a beautiful book, both in terms of its message and its contents. Filled with fantastic artwork by Kleon himself, this book encourages you to share the mess that is your creative process. Show Your Work will help anyone who is reluctant to put themselves out there. Put another way: Show Your Work is the reason I stopped hiding in the shadows and joined Dev.to.

Born To Run by Christopher McDougall

Born To Run tells the story of the greatest long-distance race ever run, and the Mexican tribe that inspired it. The distances are mind-blowing — 100+ mile races — which makes you realise that we human beings aren’t quite the Wimpy Species that we’d been led to believe. Whether you’re a runner or not, Born To Run will make you want to grab for your sweat shirt and shorts and head outside. (And, yes, the Bruce Springsteen reference is intentional.)

The Spy and The Traitor by Ben Macintyre

The riveting depiction of the real-life story of Oleg Gordievsky — a Russian agent who was secretly working for MI6 during the Cold War. The last third of The Spy and The Traitor was the tensest reading experience I’ve ever had. I was shedding genuine stress tears by the end. Incredible stuff.

Rocket Men by Robert Kurson

Rocket Men tells the story of Apollo 8, the first crewed spacecraft to orbit the moon. What sets this book apart is the scene-setting. Two chapters in particular spring to mind: Kurson’s fantastic essay on the moon's significance throughout human history; and his review of the tumultuous year that was 1968. Ultimately, however, Rocket Men is about the astronauts — three men out for the adventure of all-time; three men with families who need them home.

Hilda by Luke Pearson

The only fiction on my list, and I’ve cheated a little — Hilda is a series of graphic novels, written primarily for kids. The eponymous Hilda is a courageous blue-haired girl who encounters all sorts of wonderful things on her adventures — teleporting gnomes, a sarcastic man made of wood, bureaucratic (and invisible) elves, etc. Hilda is wistful in the best kind of way. Particularly good for young children — our 5-year-old loves it.

2020 Reading Resolutions

Looking at my list, I’m ashamed to note that there is only one female author -- unfortunately, that's probably a fair reflection on the male-to-female ratio I read this year. I’m slightly less ashamed (but still ashamed) to note that there are no real technical books. Both of these I intend to fix next year. Also for next year: more fiction. Because, hey, you’ve got to let your hair down once in a while.

What's Been Your Biggest "Why Didn't Someone Tell Me" Discovery?

MurrayVarey — Thu, 19 Dec 2019 23:21:11 +0000

Have you ever made a discovery that blew your mind (in a good way)? Something that quickly solved a nagging problem, or perhaps something that you'd been doing wrong for years?

Tech and/or non-tech answers are all good.

Do You Volunteer?

MurrayVarey — Thu, 12 Dec 2019 17:53:57 +0000

I'm interested in giving back more. Do you volunteer in your free time at all -- either tech or non-tech related? If so, what do you do? Would you recommend it?

*Open Source counts -- particularly if it's a noteworthy project.

Can you Recommend a Good Pop-Tech Book?

MurrayVarey — Thu, 05 Dec 2019 22:16:58 +0000

I'm interested in tech books that are aimed at a more general, non-technical audience. Which book would you recommend to, say, a curious friend?

Which Single Resource Has Most Affected How You Code?

MurrayVarey — Wed, 20 Nov 2019 21:37:01 +0000

There are so many programming resources available. With that said, is there a single one that had the biggest effect on your code?

For me, it would be Practical Refactoring by Llewellyn Falco and Woody Zuill.

On the face of it, this video should be extremely dry -- it's literally just a couple of guys refactoring code for two hours. In spite of that, those two hours shook me to my legacy-coding core. Refactoring has since become vital to my work and (dare I say it) fun!

So how about you? Be it book, blog, video, or whatever -- which single resource has most affected how you code?