10 things I learnt in 2024 to increase my developer productivity.

• It's been nearly a year since I stopped using an AI coding assistant.
• I discovered alternative ways to improve my coding performance.
• Key improvements include learning touch typing and using split keyboards.
• Code generation tools and customization have enhanced my productivity.
• Embracing a single programming language has streamlined my workflow.
• Building and using my own starter kits has made development more enjoyable.

Its been almost a full year now since I stopped using an AI assistant when it comes to writing code. I actually have a whole video as to why I stopped using one, but in case you haven't seen it the main reasons were to do with concerns about skill atrophy and that by using one it made me feel like I was doing copy and paste software development.

Ultimately I'm really happy with my decision to move away from using an AI coding assistant. However, there's no denying that AI does provide a productivity boost when it comes to certain tasks with writing code, with the most major one being how good it is at generating boilerplate.

Whilst this wasn't enough for me to consider reverting my decision to no longer use AI, it did cause me to start looking at other ways I could bridge that performance gap, which ended up causing me to discover a number of different ways to improve my performance when it comes to writing code.

Therefore, in order to round off the year I thought I would share 10 of the biggest things I've learned in 2024 that have not only helped me to bridge the gap from no longer using AI but have also helped me to improve my general performance when it comes to software development.

The first way that I improved my own developer productivity, and one that I would recommend to anyone looking to add a little speed boost to their own skills, is to learn to touch type. If you don't know how to do so already, for the longest time I pretty much maintained my own touch typing fork which involved my fingers jumping around the keyboard as fast as possible.

Whilst this approach sort of worked it wasn't exactly efficient and certainly wasn't accurate. Initially, I tried to learn to touch type using the Fantastic G Typist tool which is an interactive touch typing tutor for the terminal. However, despite my attempts to learn, it was always an incredibly painful process when trying to refactor my muscle memory and I would always end up reverting to my own unique style.

However, this all changed for me when I purchased a split keyboard as my own personal flavour of touch typing was no longer compatible. This acted as a sort of forcing function in order to push myself into relearning how to touch type and I'm really glad that I did as it's not only improved my own typing skills causing me to be both faster and more accurate, but it's also enabled me to use my next productivity boost.

Learning how to use a split keyboard—I actually first tried to learn how to use a split keyboard back in 2018 when I picked up the Kinesis Freestyle which I absolutely hated. So much so that I ended up returning it within a week. However, fast-forwarding onto the end of last year, I once again decided to give split keyboards a go and opted to try out the ZSA Moon Lander, which was actually recommended to me by one of my good friends who recently just got married. Congrats dude.

Learning to use a split keyboard is difficult no matter which model you choose, and as great as it is, the ZSA Moon Lander was certainly no exception, taking me around two weeks in order to become productive. However, in the end, the time investment from doing so ended up paying off in dividends.

This is because not only did it force me to learn good touch typing technique, but I've also found that using one provides much better ergonomics compared to traditional keyboards, and by having improved ergonomics it's allowed me to code harder, better, faster for longer.

In case you're interested, the keyboard that I'm currently using the most is the ZSA Voyager, which I absolutely love. This is because it forces you to think about custom keyboard layouts which has actually been the third major thing that I've learned this year.

I've actually done a couple of videos on this topic on Dreams of Code, starting by looking at the first custom keyboard change that I made back in 2016 which was when I modified my caps lock key to act as escape when tapped and left control when held. This year, however, I took my key map customization a step further and went down the rabbit hole of learning how to use home row mods which has managed to improve my overall productivity when it comes to using a keyboard.

I've actually done a whole dedicated video on home row mods. However, if you haven't watched it, the general idea is that it allows you to use the modifier keys of ctrl, shift, alt, and super which helps to both speed up typing performance as well as accuracy.

Whilst home row mods aren't for everyone, I do believe that anyone can find improvement by customizing their keyboard layouts in order to meet their own needs. In my case, one of the biggest things that I've found from having a custom keyboard layout, specifically home row mods, is that it allows me to better navigate my software development environment, enabling me to jump across windows, open up terminal shells or even just navigating my actual code.

In fact, whilst we're on this subject, this actually brings me on to the next thing that I learned in 2024: how to better optimise my development environment. When it comes to learning new things, I believe there's a bit of a bias towards learning new technologies such as programming languages or frameworks.

The reason that I believe that this bias exists is due to the fact that these skills are more likely going to be prioritized when it comes to hiring managers, which means there's an added weight in order to know these skills compared to just knowing your development environment. Despite this, however, I still think it's worthwhile spending time learning how to improve your environment as it's perhaps one of the most impactful ways you can really improve your own productivity.

Whether it's knowing how to navigate your file system, committing partial changes, handling merge conflicts in your code, or even just building and running your own software. As for how to improve your own development environment, this is going to come down to what your specific setup is.

For my own environment, I pretty much work exclusively inside of a Linux terminal using a terminal based text editor such as Novim and a multiplexer such as Tux. One of the biggest improvements I've made to my environment this year was the ability to navigate my file system in a much quicker way through the use of Z oxide.

In case you're unaware, zoxide is a sort of drop-in replacement for the CD command that makes it incredibly easy to navigate to any folder you've already visited inside of your file system without having to remember the full path. If you're interested in how it works, I actually have an entire video dedicated to it on my second channel Dreams of Autonomy.

By learning how to improve my own developer environment by integrating zoxide, it's helped increase my overall productivity when it comes to working in the terminal and subsequently when it comes to building software as well as xoxide.

One of the other big improvements that I've learned this year has been related to my text editor, specifically when it comes to writing my own custom snippets. Out of all of the things that I've learned this year, writing my own custom snippets is the one that I'm most excited about going into 2025.

But this is because I've started to dip my toes into what's possible when it comes to using snippets. And as it turns out, I think there's a lot of untapped potential. In case you're unaware, snippets are a feature found in most modern text editors that let you quickly generate boilerplate code by typing the snippets' name and selecting it from the autocomplete suggestions.

Using snippets can really help you to save time whenever it comes to writing code, especially when it comes to code that is often repeated, such as the infamous if error block when it comes to error handling in Go. In my case, I've not only been learning to use snippets more often when it comes to writing my own code but also been learning to create my own custom ones whenever I notice that I'm repeating the same lines of code over again.

For example, as I mentioned before, when it comes to writing Go code, error handling can often be tedious to write, so I've been pushing myself into making a few custom snippets in order for me to easily generate the various error handling code that I often encounter, such as generating the if error block that I mentioned before or the ability to wrap an error using the fmt.Errorf function.

As well as these, I've also pushed myself into learning how to create more advanced snippets such as one that I've created in order to print out an error message using the slog logger. The reason this one is more advanced is that it has some contextual awareness through the use of the tree-sitter package in Neovim, which allows me to pass my code as an AST to show what I mean.

If I go ahead and run my slog error snippet inside of a method of a type, it'll automatically pull out the receiver's name from the method's function signature and prefix it into the line of code. However, if I call the snippet in a normal function then this behaviour doesn't actually occur as it doesn't have a receiver to pull from.

This is all done using the following Neovim lua snippets pulling the relevant information out of the AST provided by tree-sitter for me. This is why I'm really excited to learn more about snippets in 2025 and I think this could be a viable option for bridging the gap when it comes to generating boilerplate. I'll definitely be doing a dedicated video on this in the future, as well as learning new things such as advanced snippets.

I've also spent a lot of time in 2024 relearning some of the things that I haven't done in a while when it comes to software development. In 2024, we're living in what I would consider the golden age of shipping fast as there are a number of tools and services to enable you to develop and deploy your code in a matter of hours, handling things such as authentication, payments and even the deployment of your application without you needing to worry about setting up any infrastructure.

All of this enables you to focus on building your actual product rather than worrying about the context that comes with it. This is in stark contrast to how it used to be 15 years ago, where it was much more common to roll your own authentication or render HTML on the server or to deploy your application onto a VPS server that you managed.

Whilst having all of these tools makes shipping much easier and more accessible, part of me did start to feel like I was losing some foundational knowledge when it came to building and shipping my own services. So throughout this year I decided to spend some time relearning how I used to build software ten years ago whilst also making sure to apply some modern concepts.

One particular thing that I've really focused on recently has been how to deploy applications to a VPS instead of preferring to use platforms such as Vercel, Netlify or Railway app. By relearning some of these more foundational concepts when it comes to building services, it has helped me to not only get a better understanding of my own code, but I believe it also helps to reduce my risk of skill atrophy that often comes when outsourcing to third-party services.

Perhaps most importantly, however, is that it encourages me to use my brain, which is important for exercising my thinking muscles. In fact, one way that you can ensure that your own thinking skills are kept up to date is to make use of a learning platform. Fortunately, that's where the sponsor of today's video comes in: Brilliant.org.

If you're looking to learn math, data, science or programming then brilliant.org can help. Brilliant is where you learn by doing with thousands of interactive lessons in math, data analysis, programming, and AI. Learning a little every day is one important habit you can make as it not only helps to keep your brain active but can also make you a better thinker.

By using Brilliant, you can achieve this in just minutes every day. The platform helps you to build critical thinking skills through problem-solving rather than just by memorization. So whilst you're building real knowledge on a specific topic you'll also improve your thinking skills.

If you're looking to advance your learning and software development in a simple and interactive way, Brilliant has you covered with a number of courses to help you get started. These include both the Thinking and Code, and Creative Coding courses which will help you to learn essential coding elements from loops and variables to nesting and conditionals.

So to try everything that Brilliant has to offer free for 30 days, visit brilliant.org/dreamsofcode or by scanning the QR code on screen or clicking the link in the description down below. By doing so you'll also get 20% off Brilliant's annual premium subscription. A big thank you to Brilliant for sponsoring this video.

The next big thing that I've learned this year is to embrace the use of code generation tools. This one is always something I was a little skeptical of in the past as I've often found that generated code can sometimes be a pain to maintain. However, since discovering the fantastic SQL C project, I've really warmed up to the idea of using code generation in my own projects.

In case you're unfamiliar with how SQL C works, I do have a whole dedicated video on it that I did a couple of months ago. However, the general gist is that it allows you to easily generate code that matches the repository design pattern from defined SQL queries and does so in a way that considers your existing database schema.

For me, SQL C has been a huge time saver and I've been using it with every project since discovering it. One project that I've recently been using it with has actually been my new course platform which I plan on releasing with my first course in 2025, something I'm really excited about.

In fact, the process of building this course platform has taught me a few other things with perhaps the most notable one being to reprioritize automation. This is something I've been a fan of for a number of years. However, since becoming a full-time content creator and software developer, I've mostly been writing code to solve my own problems, although that has started to change because of this.

However, it means that I fell short of my usual standard when it comes to automation. Instead, I pretent entered the world of manual processes, especially when it came to rebuilding my code whenever developing locally, refreshing my web browser whenever I made a change to my frontends, or manually SSHing in and redeploying my application when deploying on a VPS. Fortunately, I've managed to find my way back into the light and have started reapplying automation whenever I can to speed up my process.

For example, when it comes to deploying my code, I now make use of both Docker stack and Docker context to ensure that I'm able to deploy my VPS on a CI/CD pipeline without needing to manually SSH in. As for automating my local development experience when it comes to my course platform, I've been making use of both the air packaging goal as well as the ability to perform hot reloading when it comes to working with Temple which is what I've been using for rendering HTML.

This has sort of given me a Next.js-like experience when it comes to building my frontend but with the added benefit of using Go, which is actually another thing that I've learned to embrace in 2024.

Having only one preferred language or framework, this is perhaps going to be the most controversial take in this video and tends to be at odds with the general idea of picking the best tool for the job. However, personally, I found this to be a much better approach for my own productivity.

To explain why, it all began earlier this year when I was starting to build out a new SaaS tool, one that I actually use in my own video production workflow. Actually, I started to do so on Stream and ran into perhaps what is a very common issue when it comes to front-end software development: which framework to use. Much to the dismay of Chat, I spent a lot of time deliberating over each of the potential frameworks I was considering as they all had their own pros and cons.

For me, this is actually one of the first times that I've really experienced such strong choice paralysis when it comes to software development and it's something I didn't really want to experience ever again when starting a new project. So, I decided for the rest of 2024 to only pick one language and make use of it as the default language and framework for all of my future projects, only ever deviating if the language itself had a technical limitation that meant it couldn't be used.

As for which language to choose, well, I had one last decision I needed to make which was to choose between either Go or Rust, which are perhaps my two favourite modern languages. In the end, I decided to choose Go, which is probably the language I've used the most over the past five years, but I think I would have been happy using either one.

In fact, I want to try and do the same experience at some point throughout 2025 when it comes to Rust, perhaps adding it to a core language toolbelt that I use for various different tasks. However, since picking Go, it's become the main language that I've used for nearly every task since, which has not only removed choice paralysis for me at least when it comes to building software, but it has also allowed me to spend time really dedicated to diving deep into the language's features.

This means I've gained a better understanding of the language to solve some of the more niche problems I've typically encountered, such as using the embed package to solve some issues I had when it came to deployments, or being able to make full use of the newer features of the language such as the HTTP Advanced Routing feature released earlier in 2024.

Personally, I'm really glad that I've dedicated time into using a single language and in doing so it's actually encouraged me to build a framework in order to become more productive when using it. This was something inspired by a lot of the enthusiasm for Laravel and how the framework allows developers to become productive as quickly as possible.

Which actually brings me onto my tenth and final lesson of 2024: learning to both build and use my own starter kits. This is perhaps the most recent thing that I've learned this year. In my case, rather than purchasing or forking an open-source starter kit, I've instead been building out my own suite of code in order to build up a decent template for my preferred tech stack.

The goal of this starter kit is for me to be able to begin a project at the start of the day and have it up and running by the end of the evening, complete with payments, authentication, configuration, emails, HTML rendering, and even being fully deployed. By building this kit it's not only allowed me to be more productive with my chosen language but has made shipping an idea a much more enjoyable experience—something that I want to keep on with in 2025.

If you're interested in what my starter kit looks like then let me know in the comments down below and I'll put some time into figuring out how I can make it available for other people to use.

In any case, that wraps up the 10 things that I've learned in 2024 in order to improve my productivity without relying on AI. With that, this will probably be my last video of 2024, so I hope you all have a great new year and I'll see you in the next one.