DEV Community: Kieran Venison

Who Remembers Having to Check if You Could Use a CSS Feature?

Kieran Venison — Sun, 06 Jul 2025 23:15:00 +0000

Ah, caniuse.com. My old flame. My partner through the dark ages of Internet Explorer 11. The friend I visited before every bold declaration of display: grid;. The loyal confidant who would gently whisper, “Not yet, friend. Not in Safari.”

But something strange happened recently.

I was knee-deep in a new project, slinging Tailwind classes like a cowboy in a typographic shootout, when it hit me:

I can't remember the last time I checked if I could use a CSS feature.

Tailwind had quietly stolen that part of my workflow. Stolen it and buried it six feet under a grave marked "RIP Vendor Prefixes". And honestly? I didn’t even send flowers.

A Love Letter to `caniuse.com`

Remember the ritual?

You spot a fancy new CSS property on CSS-Tricks.
Your brain lights up like a Christmas tree.
You open a new tab with trembling fingers.
You type: caniuse.com
You pray.
You weep.

I used to schedule my ambition around browser support.

“Can I use position: sticky?” Not unless you enjoy watching IE11 ruin your life and your layout.

Then Tailwind Came Along

Now? I write sticky top-0 and just assume it’ll work.

Not because I’m cocky (okay, maybe a little), but because I trust that the Tailwind team has already done the legwork.

Tailwind, PostCSS, Autoprefixer, and friends have become this benevolent cabal of CSS sorcerers that quietly smooth over the messy parts of the web.

They don’t ask for thanks. They just let you build things that don’t spontaneously combust in Edge.

Honestly, I don’t even remember what browser version we’re supporting anymore.

That used to be printed on the wall. Now it’s more like a vague vibe.

“Modern enough, probably.”

Are We Getting Lazy?

Maybe. But also, maybe we’ve earned it?

After years of getting gaslit by float, after wrestling with flexbox bugs that only existed in Firefox 68, after prefixing everything like we were trying to cast CSS spells—we deserve this era of ignorant bliss.

Somewhere, someone is still checking caniuse.com.

Some poor soul trying to support a Smart TV browser in a prison system in rural Nebraska.

But not me. Not anymore.

In Summary

Do I miss caniuse.com?

A little. Like you miss an ex that taught you a lot but also made you question your sanity.

But now? Now I just write grid grid-cols-3 gap-6 and move on with my life.

And that, my friends, is progress.

PS: If you still use float, we need to talk.

And by "talk", I mean "stage an intervention".

Deep Dive into CSS :has Selector

Kieran Venison — Wed, 17 Jan 2024 09:25:50 +0000

In the ever-evolving landscape of web development, CSS continues to offer powerful tools that significantly enhance the capability of web designers and developers. A prime example of this progress is the introduction of the :has selector. Part of the CSS Selectors Level 4 specification, :has brings a new paradigm to CSS, allowing developers to select and style elements in a more contextual and conditional manner.

Technical Overview of :has

The :has selector is a relational pseudo-class that matches elements based on the presence of specified descendants. Unlike traditional selectors, :has looks ahead in the DOM structure, enabling parent selectors based on child or descendant elements.

Syntax

The syntax of the :has selector is as follows:

element:has(selector) {
  /* styles */
}

The selector inside :has() can be a combination of any valid CSS selector, including class, ID, attribute, pseudo-class, and pseudo-element selectors.

Use Cases and Examples

Responsive Design

.card {
  display: grid;
  grid-template-columns: 1fr;
  gap: 10px;
  border: 1px solid #ccc;
  padding: 10px;
}

/* Adjust the layout of a card if it contains an image */
.card:has(> img) {
  grid-template-columns: 1fr 2fr;
}

<div class="card">
  <img src="path_to_image.jpg" alt="Image Description" />
  <div>
    <h3>Card Title</h3>
    <p>Some content here...</p>
  </div>
</div>

<!-- Example without an image -->
<div class="card">
  <div>
    <h3>Another Card Title</h3>
    <p>Some other content here...</p>
  </div>
</div>

This example demonstrates the ability of :has to create more responsive and adaptive design, especially useful in scenarios like card layouts where the presence of an image can dictate the layout structure.

Typicallky before :has we would have to implement more selector rules and say something like class="card card--two-column" but now instead of adapting out html markup and our css to cater for the varied content we only have to update our css and it can essentially ifgure out what the content is and apply the appropriate styling!

Interactive Content

.menu-item {
  background-color: white;
  padding: 10px;
  border: 1px solid black;
}

/* Style a menu item differently if it contains a submenu */
.menu-item:has(.submenu) {
  background-color: lightcoral;
}

.submenu {
  display: none;
  padding: 5px;
  border: 1px solid grey;
}

.menu-item:hover .submenu {
  display: block;
}

<ul>
  <li class="menu-item">Home</li>
  <li class="menu-item">About</li>
  <li class="menu-item">
    Services
    <ul class="submenu">
      <li>Web Design</li>
      <li>Web Development</li>
    </ul>
  </li>
  <li class="menu-item">Contact</li>
</ul>

The :has selector can significantly simplify the styling of complex navigation menus, particularly when dealing with nested or dynamic content.

Similar to the previous example before :has we would have to apply another modifier to menu-item to achieve this.

I have faced issues in the past where I read files from the file system and dynamically generate the navigation. I have had to add logic to the top level <li class="menu-item"> to check if it contains a nested ul and then if it does apply another class making it <li class="menu-item menu-item--with-children">. Using this example you can skip writing all the logic to do this and save computing that value with javascript, a nice efficiency win, and a marked improvement on readability for your html markup!

Form Field Validation

/* Highlight a field with invalid input */
input:invalid:has(+ .error-message) {
  border-color: red;
}

<form>
  <input type="email" placeholder="Enter your email" required />
  <span class="error-message">Please enter a valid email address.</span>
  <br />
  <button type="submit">Submit</button>
</form>

The combination of :has with other pseudo-classes like :invalid can enhance form validation feedback, improving user experience.

Typically, looking at react for this example we would have had to invalidate the field and conditionally apply a class to the input or wrap it in another dive and conditionall aplly a class to that. meaining more DOM soup, here we dont need any of that.

The only dynamic thing now would be showing the error, and if that error is visible, we have a appripriately styled input.

Browser Compatibility and Modern Web Practices

As of 2024, the :has selector enjoys support across major modern browsers, including the latest versions of Chrome, Firefox, Safari, and Edge. The growing trend towards modern web practices and the phasing out of legacy browsers like Internet Explorer has paved the way for the adoption of advanced CSS features.

Emphasising the Shift from Internet Explorer

With the end of Internet Explorer's lifecycle, web developers are no longer constrained by its limitations. This transition allows the full utilisation of modern CSS capabilities, such as the :has selector, which are unsupported in Internet Explorer.

Technical Considerations

Performance Implications

While the :has selector opens new avenues in CSS, it's essential to consider its impact on rendering performance. Since :has is more complex than traditional selectors, it can introduce performance overhead, especially when used extensively or with complex descendant selectors. Developers should balance the use of :has with performance best practices.

But I'm going to take a stab in the dark here and say that this is more than likely going to be much quicker than writing javascript to achieve the same effect!

Cascading and Specificity

The :has selector follows the standard rules of cascading and specificity in CSS. Its specificity is calculated based on the compound selectors within the :has() function. Understanding this is crucial for avoiding unexpected styling conflicts.

Final caveat

ALWAYS check your own browser stats! I have generalised a lot here about the support. Yes it may be fully supported in all modern browsers, but, is that what your users use? before adopting anything make sure that it is supported by your predefined thresholds of support! check out Can I Use for more info on the support!

Conclusion

The CSS :has selector marks a significant milestone in the evolution of CSS, offering developers more sophisticated tools for styling web pages. Its ability to select parent elements based on child conditions is a powerful addition to the CSS toolkit. With broad browser support and the shift away from legacy browsers, the :has selector is poised to become a staple in modern web design. As with any advanced feature, it should be used judiciously, with a mindful approach to performance and specificity.

Hackathon to Build a Game in 3 Hours

Kieran Venison — Fri, 12 Jan 2024 08:49:12 +0000

Hackathons are super fun. To date, I have done two other hackathons, the now-defunct Hack Manchester event. In which you had 24 hours non-stop to build something in a team of 6 to a theme provided by the sponsor. So when I was made aware that the company away day was going to be a hackathon, I was super excited. But it had some quirks I had never experienced before:

It was building a game - new territory for me
It was built in React - Yes in react, not in Unity or even using the Canvas (I will expand on this shortly)
I was the only developer on the team of 5
I had never met any of the people and started at the company 5 days prior to the event
We ONLY had 3-4 hours of coding time

So how did it go, and what would I do differently?

Brief

Before I continue, I will state that the challenge had a theme. The theme was around building a game for children currently in the healthcare system, something they can play to help reduce anxiety whilst in hospital or undergoing treatment of some kind because, as a TL:DR; there have been many studies showing that children who have an adverse event whilst in a hospital (such as being restrained to be sedated) have a noticeably longer recovery period. So the criteria were simple:

It could:

Be Educational
Be Something to distract them from the situation they are in
Target age brackets of 2-5, 5-13, 13+ or all of them

We also had to develop offline material to support the game because not everyone in the healthcare system has access to the technology required to play the games, so that was an additional piece of criteria we had to meet which also abided by the above principles: educate, distract, and fit one or more of the age brackets.

Planning

Once we had heard the brief, we had to plan.

We had ample time to plan. During the day, we all brought board games and some console games. We sat around and switched around different stations playing a variety of games to try and trigger a thought process or ideas we could use with our mini-games.

After playing some games, we split into our teams. The teams typically consisted of 5-6 people. As this was an entire company, it ended up making some interesting teams, so my team ended up looking like this:

A Developer - myself
Senior Designer
Lead Talent Manager
Senior Finance Manager
NHS Healthcare Manager

This was by far the most peculiar team setup I had ever been a part of when doing a hackathon (typically it's primarily devs and maybe a test resource and a product person). But being a company event, we wanted the entire business to partake in this and experience what a hackathon is like and the kind of chaos and collaboration around it.

The first thing we did in our team As individuals was Crazy 8's. I will link to an article to explain it more here but in short, we got a piece of A4 paper and folded it so we had 8 rectangle seams on the page. Then in each rectangle, we wrote a brief description for a unique mini-game. Once the time was up (around 10 minutes in total, so you have to be quick) we had a few minutes to skim over them and pick the one which we thought was the best.

Once we had chosen one of our 8 short game descriptions, we flipped the sheet and spent a further 10 minutes sketching out the potential screens of that game to get a visual idea of how it would play and to demo back to our team.

Once this final round of self-planning was done, we stuck our ideas to a team whiteboard, and each pitched our idea to the team.

Deciding which project to run

So as I mentioned at the start of the article, this is built in React. And the reason is that one of the Lead Engineers had a passion project that he had been working on at the time, A react-based game engine. The theory is that this game doesn't require the same large paradigm shift away from react technologies that front-end developers are used to using over to something like C# in Unity. And it was just something fun to try out. Why not! It's open source, so you can have a nosey yourself!.

Being developed by a single person, who has kids and a full-time job means we are all using an alpha version of this and the docs are not completed fully and it's very much in its infancy, so we had to be careful how much of a game we decide we want to build, (at least if we want to present something)!

So how did we decide? We dot voted

2 votes each
You cannot vote for your own game

I can't lie here so I will say some of the ideas scared me; one of them was VR/AR related, which was super cool, but an engine built on react and in its infancy and being a sole developer meant none of my votes are going here; it's basically a shotgun to the face if I pick this.

My Idea was a digital version of Operation. A game in which you have to carefully remove pieces of the character's body without touching the side and making the nose glow red. But instead of just removing the piece, you had to traverse through a short maze to get to the operation table without touching the wall of the maze with your finger or the piece would fly back to the body. And in all honesty, while much simpler than the AR/VR one, it was still a big stretch in 3-4 hours. So I was kind of hoping people didn't like the sound of it.

Two more games cropped up with a similar theme of designing a character/animal and getting accessories for them and then guiding them through a treatment, such as applying a plaster, or explaining to them what's in a medical room and these started being 2d, which was a sigh of relief and actually decent ideas as well.

And last but not least, the idea we went with. A much simpler idea, a Where's Wally clone. The idea was simple:

A series of scenes each containing something/things you have to find
you tap the item to find and it disappears
Once you have tapped the item/or all the times in the scene the next scene appears
you fly through the scenes as quickly as possible to achieve a high score
if you miss the target you lose 10% of the points you have earned
Your high score was a calculation based on the overall time taken, your points and accuracy.

This game was simple, a flat 2d game with clickable objects a few unique screens which I could probably implement a generic way of adding more screens and then a simple end screen, time and score. A nice distracting game which can be for all the ages ranges if we change the complexity of the search!

Building the game

Time to sit down and crack on.

I'm not going to share large snippets of code in this article because this is not a programming article as such, but I just want to share the ways in which I massively overcomplicated such a small project.

The idea was simple. The designer sends me some screen mockups and says here is the hidden thing and then I (Using the overreact/js engine) draw a grid, I went for a 100 x 100 grid. I then find the cell of the grid where the hidden item is and make that cell an invisible target. So to do this I could simply have an array of screen objects each containing a URL to the image and the cell to which the hidden item is in like so:

const screens = [
  {
    url: './assets/screens/desert-1.png'
    cell: 6
  }
  {
    url: './assets/screens/desert-2.png'
    cell: 65
  }
  {
    url: './assets/screens/desert-3.png'
    cell: 90
  }
]

In a hackathon, you go into panic mode, you sit down and fire code at the wall, and it is ugly. It doesn't have to be the right solution, it just has to work, you're on limited time. so I implemented this, got the screens in, drew them to the page using the BitmapAsset component from the engine, hit a few blockers and bugs along the way then realized an issue.

Not all the hidden items align with our perfect 10x10 grid system. In some places, they overlap, how do you map a circle to a square etc, etc. So I kept the existing code as was and extended it, in a super hacky way like so:

const screens = [
  {
    url: './assets/screens/desert-1.png'
    cell: 6,
    cells: [5,6,7,15,16,17]
  }
  {
    url: './assets/screens/desert-2.png'
    cell: 65,
    cells: [65,66,67]
  }
  {
    url: './assets/screens/desert-3.png'
    cell: 90,
    cells: [80,81,90,91]
  }
]

The above allowed me to say if they hit a cell and screen[x].cells.includes(cellHit) then they have found the hidden object! Move to the next screen.

The cell concept kind of looked like this image where the active cells (which would obviously be invisible) are highlighted green:

But by this point, I had loads of broken score and timer logic in so it was already a mess, so doing basic things became tricky on top of the mountain of, well... shit.

But we ended up with 9 screens you could traverse through and click a range of cells to progress

Time was running out. We did a few bits to prettify it, adding an end screen to display the score and a start screen with a background image and a start button. But time was running so slim that we "cheated" the start screen, We used a full-screen image of the UI and selected the start cells to overlay the start button.

"If it looks stupid but it works, it ain't stupid"

So all finished just in time, the messiest code I have written in years, but you can play the game, traverse through the screens and... it's actually pretty fun.

Given a couple more hours, and not having the sloppiest code known to man I wanted to implement things such as

Saving high scores
Randomising the screens
Randomising the hidden item position
Moving targets as a dexterity version

But after all of this complexity in drawing a grid and making cell ranges, I realised something, at the very end that made me laugh.

the simplicity of this game meant could build this in about 10 minutes if I had just made a drawable SVG to the screen and popped onClick on it! I did have access to the HTML DOM after all!

With that in mind, even though the time cap was only 3-4 hours it would have been wiser to spend 40 minutes of that time actually planning the build, I would have likely got to the same game in terms of end result and would likely have faced other issues from doing a different approach but I strongly think I would have come to a better structured approach which would be much more extensible and polished than this one.

It wasn't just a game

At the same time, the game was going on I almost forgot the team was working on multiple things, the designer was constantly firing assets to me and we had a mini collab back and forth and as we developed the game and the rest of the team fired us ideas for the screen and worked on the offline assets for the game.

The offline game was as simple a concept as the game itself. A series of handout sheets with items you could find on related to healthcare as an educational challenge and the concept of a mural-style wallpaper you could put in children's waiting areas with a variety of things they could look for to distract them from the situation they are in! an amazing, yet so simple concept. They even made a series of sketches and drawings and fastened them together and rolled it out during the demo back to the business to explain the concept which was super cool to see as I had been heads down in my bubble for the last 3 hours!

The end result

A game that works 🤯
A game that is vastly overcomplicated
Spent some time using a fun engine!
Got to experience a proper cross-functional hackathon team
Had a laugh, at my own expense
Got to see some viable projects that could benefit the initial brief

Tailwind, My Altered Opinion

Kieran Venison — Sun, 31 Dec 2023 22:10:26 +0000

When Tailwind first emerged on the web development scene, I found myself firmly rooted in my comfort zone, relying on familiar practices and tools. As someone who wasn't an avid user of many frameworks, I typically stuck to a minimalistic approach, often implementing a reset like Meyerweb or resorting to the well-established Bootstrap when the need arose. Tailwind, with its extensive list of classes, initially struck me as overwhelming and cluttered—an apparent departure from the simplicity I had grown accustomed to. Perhaps it was a reluctance to embrace change or an attachment to my existing workflow that fueled my initial skepticism. However, as time passed, so did my perspective. Join me as I unravel the factors that prompted a shift in my opinions and ultimately led me to reconsider this dynamic framework.

First Opinion

When Tailwind first entered the web development scene, I found myself deeply entrenched in the practice of crafting everything from scratch. Bootstrap, at most, was a concession for minor components, particularly its grid system. Despite the availability of newer layout tools like Grid and Flex, I clung to Bootstrap's grid system, feeling a sense of control over my code. I was a practitioner of the BEM CSS methodology, believing in its ability to maintain cleanliness and organisation in my class names.

However, the arrival of Tailwind felt like a bombardment of class names, an assault on the meticulous structure I had painstakingly built. The HTML files seemed to burst at the seams with a myriad of class names, a sight that was particularly disconcerting if you adhered to ESLint rules restricting line width to 120 characters or something similar. While I couldn't deny the visually stunning creations people achieved with Tailwind, I couldn't reconcile the idea of sacrificing the clarity of my HTML for such results. It felt as though the framework demanded a compromise that other tools didn't.

In my initial encounter, I conducted only a cursory trial, swiftly dismissing Tailwind for both personal and project use. My dismissal extended to fervent discussions with friends and colleagues, showcasing a degree of inflexibility that, in hindsight, reflected my limited development experiences at the time. Back then, my approach was rooted in the belief that if I didn't fully understand something or the reasons behind its design, it couldn't possibly be beneficial. Little did I realise that this stance marked a significant rookie mistake—one that, over time, I would come to reassess and rectify. Ah, the sting of hindsight.

When did I start realising it might be the right technology?

Admittedly, my initial resistance to Tailwind persisted for quite some time. I held onto my skepticism, unconvinced of its merits, and continued to voice my reservations against it. It wasn't until I noticed a growing trend—Tailwind becoming an integrated option in popular CLIs like Create React App (CRA) and NextJS, that I started to entertain the idea of giving it a second chance.

Around this time, a significant shift had occurred in my approach. I had broken free from Bootstrap's influence, no longer relying on it for my grid systems. Instead, I invested time in comprehending the nuances of Flex and Grid, allowing me to craft elegant and minimal code for my layouts. It felt liberating, aligning with my vision of authoring all my code independently, free from frameworks or constraint, or so I thought.

However, as I immersed myself in crafting everything from scratch, I couldn't ignore the shortcomings of my previous CSS approach. Each project I worked on exhibited common issues:

Boilerplate Overload: A surplus of repetitive, boilerplate code that felt like unnecessary baggage.
Isolated Understanding: Code that could only be truly deciphered by myself, creating hurdles for collaboration within a team.
Inconsistent Standards: Projects that failed to conform to what I considered my established (and undocumented) standards when another developer touched them.
Limited Contribution: Maintenance and updates were solely my responsibility, lacking the collective vigilance of a team to ensure accessibility and identify potential bugs.

These realisations prompted a reconsideration of my coding philosophy. Was complete autonomy truly the epitome of efficiency, or had I been overlooking the benefits of a more collaborative and standardised approach? The answers lay in exploring Tailwind with a renewed perspective.

How Do I Use It Now, and How Has My Opinion Changed

Over time, my perspective on Tailwind has undergone a significant transformation. While remnants of my initial reservations persist, I've embraced a hybrid approach, blending elements of the old and new. As evident on my personal website built with Next.js and Tailwind, I've managed to reduce my custom CSS to a mere 50 lines.

Comparing it to the V1 of my personal site, which boasted over a thousand lines of CSS, the efficiency of Tailwind is evident. The framework selectively pulls only the required CSS, eliminating the need for unnecessary helper classes during build. The result is a visually enhanced site with a substantially smaller footprint, fostering a developer-friendly environment. Collaboration becomes seamless, as other developers can glean insights into my styling setup by referencing the Tailwind config and documentation.

However, some aspects of my initial stance remain unaltered, notably my aversion to cluttered HTML with an abundance of class names. Despite the apparent visual chaos, I've come to appreciate the verbosity of Tailwind's approach, it may look overwhelming, but it provides immediate clarity on functionality. A compromise I've made is abstracting complex class combinations into CSS classes, employing the @apply keyword to maintain readability. This not only adheres to methodologies like BEM but also results in cleaner HTML structures.

In essence, Tailwind has become an indispensable tool in my web development arsenal, not just for its efficiency but also for the adaptability it offers. The evolution of my opinion mirrors the dynamic nature of the web development landscape, emphasising the importance of embracing change and reevaluating assumptions for continual growth.

Below is an example of employing the @apply lkeyword to abstract some of tailwinds larger class combinations into a css filer and removing it from your HTM/JSX

Before

return (
  <Link
    href={`blog/${post.slug}`}
    className="hover:underline grid border border-primary border-t-0 border-l-2 border-r-0 border-b-0 pl-4 md:border-none md:pl-0 md:block"
  >
    <span className="text-primary md:mr-2">
      {prettyDate(new Date(post.date))}
    </span>
    {post.title}
  </Link>
);

After

return (
  <Link href={`blog/${post.slug}`} className={styles.link}>
    <span className={styles.link__date}>{prettyDate(new Date(post.date))}</span>
    {post.title}
  </Link>
);

.link {
  @apply hover:underline grid border border-primary border-t-0 border-l-2 border-r-0 border-b-0 pl-4 md:border-none md:pl-0 md:block;
}

.link__date {
  @apply text-primary md:mr-2;
}

Conclusion

In conclusion, my journey with Tailwind has seen a notable shift in perspective. Initially resistant to its extensive class naming, I reconsidered its value as major tools like CRA and Next.js integrated it. Breaking away from Bootstrap and crafting custom layouts allowed me to appreciate Tailwind's efficiency in minimising CSS. While still disliking cluttered HTML, I've embraced Tailwind's verbosity for its immediate clarity. Adopting a hybrid approach, I now use Tailwind for its adaptability, reducing custom CSS and fostering a more developer-friendly environment. The evolution of my opinion highlights the importance of embracing change in the ever-dynamic realm of web development.

Supercharge your morning routine

Kieran Venison — Sat, 06 Feb 2021 05:50:14 +0000

Intro

In the last 2 months I have started trying to grow on Twitter, created a YouTube account and actively post videos. I started learning serverless framework, changed jobs, worked on my side projects and still have time to do the things I enjoy, but how have I done it? I supercharged my morning routine.

Its not just the morning

It's funny how I call this the morning routine when the evening routine plays such a critical part in the making the morning work.

Before we can talk about the morning routine we need to talk about the evening routine and more importantly, sleep! I recently watched Matthew Walkers MasterClass on sleep.

In this masterclass he covers the ins and outs of sleep and why it's so important and how to do it right. And I realised, like a lot of people, I had been neglecting my sleep by being very inconsistent. I used to wake for work at 6/6.30 and go to bed anywhere between 10 and 12. Then at weekends I would wake up at 9 and go to bed anywhere between 11 - 1am. A lot of people are the same, they have a schedule through the week then it goes out of the window at weekend.

Weekend is when people "catch up" on their sleep debt (which actually isn't effective at all). I found that on Sunday evening going to sleep for work on Monday was always my worst nights sleep, I was much more restless than any other night of the week. And it was all to do with my sleep consistency.

Fixing my sleep

Fixing sleep consistency. The first step towards powering up my morning routine was fixing my sleep consistency. To do this I now follow a strict evening plan:

No caffeine after midday - Caffeine has a half life of approximately 8 hours, so if I have a cup of coffee at 4pm its like waking up at midnight to drink half a cup of coffee, When you think of it like this its pretty clear to imagine the impact it has on your sleep
no screens after 9pm, stop that evil blue light keeping you up. Ideally this could be earlier but this seems to be working for now.
In bed at 9.30pm and reading until a cutoff of 10, then its sleeping mask on, I find reading naturally helps me wind down.

Consistency is key

The next bit is setting a consistent morning time. So I wake up at 5am every morning, it was very very hard at first. Naturally you may not be a morning person, so don't try and force yourself to do this if its not in your bodies best interest. just set a consistent time that suits you.

The key thing here is consistency, bed at the same time, wake up at the same time. This means weekends too. I follow the same evening patterns and the same morning patterns as much as I possibly can.

The morning routine

Now the bit that has made me so much more productive and given me time to do a lot more thing. Building your morning routine!

I wake up, and just get up. It's hard sometimes and you want to hit snooze or lay just that extra minute.... resist. I leave my clothes by the side of the bed the evening before so I can step out of bed, grab my clothes go to the bathroom and get ready.

Do things to make it easier for yourself, change your heating timing to come on before you wake up so you are not tempted to stay in bed whilst the house warms up!

Once I'm dressed and ready to go I come downstairs have a quick glass of water then get the dog ready and go out for a walk. Before I had the the dog I would just go out for a walk anyway. This is amazing (especially at 5am). Its so quiet, just a nice peaceful walk to wake you up and make sure your active before you start your day, it really clears your mind. Usually this brings me to around 5.30/5.40 when I get back home.

When I get back home I can spend some time planning out my day, but first I make a nice cup of coffee and a bit of breakfast. To plan my day I use todoist. And I wrap up my days plan in there. usually its a simple list with categories and subtasks

Once that's done I will complete any of the tasks I can right away so I can forget about them for the rest of the day, such as taking the bins out and throwing some washing in, or writing a script for a YouTube video. And then I do the rest through the day when I find the time.

The good thing with planning things out before the clock has even hit 6am means that I never suffer that late rushed to work feeling where everything is chaos. Every day I sit down at my desk to start working I know what I need to get completed that day.

Now you may spend the rest of your morning before shooting off to work executing the plan you have made above. I tend to create the plan, do a few tasks off it in the morning and then spend some time learning something.

At this point you have had food and drink, had a walk and planned out your day, so by now, your wide awake. Good time to pick up some new skills, I usually spend 30ish minutes on PluralSight or FrontendMasters just looking into some new tech. And its proven that if you nail down the consistent sleep stuff we talked about earlier, this stuff will stick in your memory much much better!

And thats how I supercharged my morning routine:

Go to bed at the same time
Wake up at the same time
get some fresh air
have a coffee and some breakfast
plan the day
execute the plan
learn something

And that, in a nutshell, is how I managed to create an active YouTube channel, learn new technologies and work on my side projects whilst changing jobs.

What about you?

I would love to hear what you think of my advice! How do you supercharge your mornings?

Check out this post on my website!