I try to regularly learn a new programming language, the reason for this can best be summed up with this quote from the Pragmatic Programmer

Different languages solve the same problems in different ways. By learning several different approaches, you can help broaden your thinking and avoid getting stuck in a rut. Additionally, learning many languages is far easier now, thanks to the wealth of freely available software on the Internet.

This year, I decided to learn C# and, in extension, the .NET Framework. There were several reasons for this, but the primary motivation was to access a language that was similar to lower-level languages like C, C++, and Rust. Using C# as a stepping stone to move to these lower languages, but with the convenience of the high-level constructs and easier syntax.

I had not been particularly interested in learning C# as it was tied to Microsoft Windows, that is, until 2014, when Microsoft decided to open-source the project. In the ten years since that release, .NET has invested considerable effort in becoming a truly cross-platform platform.

Another reason is that my daily language is TypeScript, as I mentioned in previous posts. TypeScript’s lead architect is Anders Hejlsberg, the same lead architect as C#.

The last reason for learning C# is that it can be used by Godot and other game engines, as well as bindings to frameworks like SDL3 and Raylib. I have a keen interest in game development; having knowledge of the language would allow me to develop my own games, whether using or without those engines.

The How!

When you are an experienced developer, finding resources for a new language can be a challenge. This is because many language learning resources are designed with beginners in mind. This is brilliant, don’t get me wrong, getting people into software development grows the pool of programmers and innovation. The downside of this, as a senior developer, is that there is a significant amount of duplicated information. I am familiar with the fundamentals of programming, including data types, control flow, and object-oriented programming.

With this in mind, I used the following in order to learn C#.

C# 12 Pocket Reference

This is a book from O’Reilly, where many books attempt to provide the reader with both programming and language information for the language they are teaching; the Pocket Reference is simply that —a reference to the language. I make a point of reading a section of this book every day. This gives me an idea of what the C# language is capable of. What features and paradigms can I use when building software? It doesn’t go into detail about them, however, but for that, it is a compromise I can work with, as I can often find more detailed information from other sources. I use this book more as an index of the tools I have in the C# toolbox, rather than a user's guide to those tools, although it will contain all the simple concepts I need.

Jetbrains Rider

JetBrains Rider is an IDE from JetBrains designed for the .NET ecosystem, incorporating some of the best tools. These tools include ReSharper, dotPeek, dotCover, dotTrace, and dotMemory, all of which are available in a single IDE. If you are accustomed to JetBrains tooling, this setup will be very familiar to you. This makes it easy to get started with building projects, as all the tooling is made available in an easy-to-use and visual manner. Of course, all this can be done through the command line tooling provided by .NET with the dotnet command.

LINQ Pad

LINQ Pad is a tool designed as a playground for .NET and LINQ, which is a built-in SQL-like language in .NET. It supports the major .NET CLI languages, including Visual Basic, F#, and, of course, the one I am interested in, C#. The basic tool is free; unfortunately, the free version is missing NuGet (.NET version of tools like NPM) support, which limits its usefulness beyond basic use. I quickly upgraded my version to Developer to get the extras, including the NuGet support. This allows me to build small code blocks to experiment with ideas and concepts without needing to spin up a full .NET project.

Github Co-Pilot

This might be slightly controversial, but I have found Copilot really handy. I have been very disciplined when using it; however, I don’t want to vibe code in C#. I want to learn. I have a rule when adding code to a project that I don’t directly author, whether it comes from Stack Overflow, GitHub, a blog, Copilot, or anywhere else: I won't add it unless I understand it. This means that if I do use Copilot, I review what it's suggesting, try to understand why it is doing it, and consider what it is doing before adding it. This means that I do learn and improve my C# when using Copilot. The other thing I will use it for is a semi-smart search tool, so I will ask it things like “how do I check the type of a generic?”, “How do I load a mock from a file in an XUnit test?” or “How do I get a list of all environment variables?”.

Writing Code

The only way to learn a new language is to write it, and to write lots of it. If you don’t work with the language and the ecosystem (and the .NET ecosystem is massive), you won't learn and develop skills in that language. So, I write projects and ideas that have been floating around in my head, and I start building them in C# instead of a language with which I am more familiar. The same goes if I need a small tool or service; I will build it in C# instead of Typescript. Every line of code I write in C# or problem I solve teaches me something. I also write tests for everything; this is not only good practice but also helps build more familiarity with the language. To that end, I created a new template in GitHub to make spinning up projects even more effortless, allowing me to write more code.

What is next

I am just at the beginning of my journey learning C# and the .NET ecosystem. I find writing code in C# to be very nice, and the fact that I can run it pretty much anywhere is quite cool. I plan to keep learning C# for the time being. I want to build more project types, such as audio, GUI, api applications, as well as build games. I am hoping to add it to my toolbox for solving problems in the future, so expect more posts on my C# adventures.

Every good company should invest in its employees’ skills; your people are a resource, and just like any other resource, you must invest in them. Now, most companies understand this and put aside money for training. This training can take many forms, including instructor-led training, both in-person and online, self-paced training, and book-based training, all of which I have seen being deployed. This is great, allowing your staff to choose a training method that fits them and how they learn is the best way to achieve results.

However, a resource that often gets overlooked is your team. Your team will include individuals with diverse skillsets and experiences that can be valuable to others. The advantages of utilising this knowledge are many, and it can provide higher-quality results than other training methods with less investment.

One of the most apparent advantages is that it can reduce the bus factor if you have people with particular knowledge. Sharing this knowledge across the team means it is already known, should the worst happen. You may, however, encounter pushback from toxic individuals who see having knowledge only known to them as ensuring job security or want to gatekeep that knowledge. Unfortunately, you may have to address these behaviours with those individuals through your existing HR process first.

Another advantage of using the knowledge in the team is that they will have more domain knowledge. They know your business, its process, users, and tech stack. This means that things as simple as examples, as well as topics covered, are being tailored. This will give you higher-quality training and reduce the time to learn for participants. This is also good at forming a common language within your teams.

This training style isn’t always possible, possibly due to regulatory or legal requirements or because your team may not be comfortable leading training. As you can tell, if you follow me or have worked with me, I enjoy sharing my knowledge and expertise with others. Even though I found it very difficult to start doing that within a new team, it has helped my learning, and explaining something to someone else is a great way to validate your understanding of the topic.

Although I have covered the advantages of Learn Together™, it shouldn’t be the only training provided. You may have to look at other options if your team doesn’t know a specific area. Learn Together™ can also be a great starting point for topics, and then individual team members may want to learn more through more traditional training avenues. It can also help to look at cross-team training opportunities. A team may already have expertise in an area that another team needs.

How?

So, how do you use Learn Together™ in your organisation? Well, I can’t say for sure, I was lucky when I started it, I wanted to share my knowledge and expertise with the team, the team wanted to learn, and my manager was open to the idea.

I will review how we do Learn Together™ if anyone finds it useful. So a learn together session has no fixed length, and that more casual flexibility, I think, makes it work for the team. I will schedule a session once a sprint (our sprint cadence is two weeks), generally in the second week. One thing I make sure to emphasise is that these sessions are entirely optional. The idea is that team members can choose to attend sessions they find interesting or valuable. I typically book the session for at least 30 minutes but up to an hour. I don’t feel that anything longer than an hour-long session is helpful, as it causes fatigue in both the trainer and the students and can conflict with team priorities.

When running a session, I will try to keep it casual and use as many examples, workshops, and demos as possible to keep people engaged. As mentioned above, because I am aware of the business, its technology, process, and goals, I can keep these demos relevant, which makes them much more helpful to the team. These tips are more about how people want to learn, but I believe these methods are better suited to the Learn Together™ format, rather than lecturing or presentation-based learning. Not all topics will work with this format, so you may need to explore other methods depending on the subject.

After a session, I will write an overview of what was covered in our knowledge platform. This will provide a reference for those who attended and those who could not. It will also help me track what has been discussed when planning new sessions and topics, so they are not required to be covered again when building on previous sessions.

The most significant barrier to getting started is finding someone prepared to champion the Learn Together™ format. If that is you, that is great, but you may struggle if you are looking for someone else to do it. If you are not a manager, make sure to get manager buy-in; you will need to use up to an hour of the team’s time regularly, which is easier if the manager scheduling the team’s work is aware.

I have also found it essential to try to involve other team members as the trainer who may have more knowledge than you on a topic. This allows others to grow and shows you what it is like to be a student and a trainer. This will make it easier to tailor your teaching to your team and their needs.

In summary

• Be the champion, or find someone who will.

• Keep the sessions under an hour.

• Use demos, Workshops and examples.

• Keep it casual.

• Make sure people are aware it is optional.

• Try to do it regularly.

• Reinforce the learning with a write-up post-session.

• Involve other team members, especially if they are keen to get involved.

Typescript is a compile-time tool that adds a type system to JavaScript. Typescript does not affect runtime; all type information is discarded during the build/compile process.

Built on JavaScript, TypeScript inherits all of JavaScript's types. As JavaScript is loosely typed, JavaScript will try its best to do type conversion for you, using a process called coercion; therefore, JavaScript does have types, and these types form the foundation types in TypeScript.

Typescript uses a hierarchical type system, meaning one type can extend from another.

Types

The base types in the hierarchy are

Extendable

All these can have child types that extend from them

• String - any value that represents a string of characters

• Number - any number, both whole and decimal, from 0 to Number.MAX_VALUE

• Boolean - the values true or false

• Object - An object literal or anything that extends object literals. Note that Arrays in JavaScript are objects.

Not Extendable

These can not have any child types

• undefined - only contains the value undefined, this is a special type that means that a variable does not exist or has had its value

  explicitly set to undefined, or has not had a value set (implicitly set to undefined)

• null - only contains the value null, a special type that means a variable has been defined but has had its value explicitly set to null.

Typescript Types

JavaScript does not use these base types, so they are unavailable at runtime, only at compile time when using TypeScript. None of these types can be extended from

Never

This special type tells TypeScript that if code ever reaches this, something has gone wrong, i.e. you should never have a path to this type.

const runtimeError = (): never => {
    throw new Error("Something went wrong");
}

This is never used because if this function is called, it doesn’t return; therefore, we indicate using the never type.

You can not convert to never at all.

Unknown

This special type tells TypeScript that we don’t know what the type of this variable is, but not to worry about it and that we will clarify it later. To maintain type safety, you should deduce the correct type before using an unknown variable.

Any

This is the last of the special types in TypeScript; all types can be converted to any, and all types can be converted to a narrower type from any. This makes it very dangerous, as you discard type checking completely when using any. There is no type-safe way to use the any type, the closest is to treat it like unknown But if you forget that TypeScript, it will not detect it, unlike with unknown where it will.

Conversion

Now that we have a basic understanding of the type system, we can discuss how they get converted, sometimes called casting. TypeScript uses two strategies when converting: Type Narrowing, which goes down the type hierarchy tree from a broader type to a narrower one, and Type Broadening, which goes in the opposite direction, from a narrow type to a broader one.

Cross-Type Conversion

For completeness, cross-type conversion, going from one base type to another (i.e., from a string to a number), can not happen implicitly in TypeScript. You must always handle this explicitly using runtime functions such as parseInt.

Broadening

This is the easiest to understand, and the easiest for TypeScript to do. This happens implicitly because it doesn’t require type checking.

When you broaden a type, you discard the extra type information and cast the type to the new broader type. Because it relies on discarding Information, you can not implicitly return to the narrower type once broadening occurs.

Narrowing

Because narrowing requires more information, TypeScript can rarely do this implicitly; the only time it can is when the value of a variable is guaranteed at compile time, which means if a variable is of one of these types. string , number , boolean AND declared with const. Objects are not included because of how they work under the hood. An object is considered const long as its underlying reference ID never changes, regardless of whether its shape changes. Due to this, even freezing using Object.freeze an object won’t guarantee that it won’t change at runtime. The exception to this is a const array, but you have to follow specific rules to declare them.

Because of this, you will most often need to help TypeScript understand how to narrow a type.

As

When looking this up, you may come across the as keyword. The as A keyword allows you to instruct TypeScript that you know what is happening and want it to treat your broader type as the narrower type. This is not considered type safe because, as mentioned above, TypeScript only operates at compile time; therefore, it can only guarantee type safety at compile time. Using as it will result in possible runtime type mismatches being missed. The as keyword will also never allow you to change the type when no overlap exists. This is when the type you are converting to does not exist in the same inheritance chain; in that case, you are trying to cross-convert types.

Type Assertion Functions

This relatively new feature in TypeScript allows you to narrow the type and maintain type safety (when used correctly). Type Assertions bridge compile time and runtime, meaning they must be guaranteed at compile time. This allows TypeScript to use them when doing type narrowing. For them to be guaranteed at compile time, they must be declared with the function name() {} syntax not const a = () => {} or const a = function() {}. They must take at least one argument of the value you are checking, and should use the type unknown. They can take other arguments to help with asserting the type. They can not return a value and should only return if the variable matches the declared type. The type assertion function should throw if the variable does not meet the required type. This mimics the behaviour of assert in the Node standard library node:assert and other assertion libraries/languages. Due to the way they are defined, type assertion functions must be declared before use.

An example type assertion would look like

function assertAType (value: unknown): asserts value is <TYPE> {
}

The asserts value is <TYPE>is what makes this a type assertion, where <TYPE> is replaced with the type to which you want to assert the value conforms.

An example of this could be

import assert from "node:assert";
type Px = `${number}px`

function assertIsPx (value: unknown): asserts value is Px {
  assert.equal(typeof assert, "string", "Px should be a string");
  assert.ok(value.endsWith('px'), 'should end in pixal');
  assert.ok(parseInt(value, 10) !== Number.NaN, "should contain a number");
}

let width: string = "10px"; 
assertIsPx(width);
// width type has now been narrowed from "string" to "Px"
let height: string = "200";
assertIsPx(height);
// this would throw an error because height doesn't confirm to the type rules 
let depth: Px = "200px";
assertIsPx(depth);
// This would pass and no type narrowing is needed so it will remain "Px"

For type assertions to be valid, you must define the type rules in the assertion and ensure they cover everything the new type must have. This can be complex; the more complicated the type is, the simpler the assertion is. The above example is simple, and so is its assertion. This is because the following is valid, but pointless as it doesn’t do any type checking; however, if used like the assertion function above, it will mean any variable passed to value will become of type. Px As far as TypeScript is concerned, it doesn’t match the type rules.

function assertIs (value: unknown): asserts value is Px {}

Fun Fact

If you are wondering why you have to use function name() {} over const name = () => {} or const name = function () {}

This is because of the need to be guaranteed at compile time. function name() {} Declares a function; this function exists as soon as the runtime engine starts, and remains immutable until the runtime engine completes and exits.

On the other hand const name = () => {} and const name = function () {} Assign a reference to a function. This means that const name becomes type Function which in turn is a child type of object , as long as the object reference ID stored in const name doesn’t change it, doesn’t violate the immutability of const The result is that the name value can’t be guaranteed at compile time, so TypeScript can’t use it.

If you have read any of my other posts, you are likely aware that my primary coding stack is based on TypeScript. Working in modern JavaScript can be complex; a modern JavaScript project often involves numerous moving parts to be productive and comfortable. Setting up these moving parts can be a time-consuming process. I tend to create numerous projects, whether a library, a whole project, or an experiment; I want all my standard tooling. I therefore decided to make a GitHub template repository that I can use to generate new repositories when I want to work with TypeScript.

This post will walk through the template's stack and explain the rationale behind choosing each part. This doesn’t mean you have to use this technology, but for me, these are the best technologies currently available in 2025. The Readme covers the setup and other helpful information if you want to use the template.

We recently adopted this stack at work, which means it is also used professionally.

Node

To manage nodes, I use NVM. I have used it for a long time and am comfortable using it. I also like that you can switch node versions when entering a node project by detecting the nvmrc file. It is also well-supported by other tooling and VSCode, my primary IDE.

Package Manager

Nowadays, I almost exclusively use PNPM to manage my dependencies in Node projects. There are two main reasons for that.

The first is that PNPM provides excellent tooling for managing a monorepo through its workspace tooling. You can easily link packages under the repo, build and package code for deployment and scope commands to a package within a workspace.

The other significant benefit of PNPM is that it reduces the space required for your packages on a disk. We have all, by now, seen the meme of node_modules Having a density greater than that of a black hole, being able to reduce it is a massive benefit.

You can read more about the motivation behind PNPM and how it reduces install sizes on the PNPM Website.

Typescript

It shouldn’t come as a shock now, but the central part of my stack is Typescript. I use TypeScript because it makes JavaScript easier and safer to use. For anyone who hasn’t encountered TypeScript yet, it is essentially a superset of JavaScript, meaning that all valid JavaScript is also valid TypeScript. However, TypeScript supports type annotations. This adds safety to working with JavaScript, reducing bugs and edge cases. It also reduces the number of tests you write, as the TypeScript compiler can do the work.

Like many influential and essential tools, Typescript requires a commitment to learn how to use it effectively and maximise its benefits. However, it makes a big difference in building reliable and robust codebases that run anywhere JavaScript can.

Linting

ESLint

I use ESLint partly out of habit but primarily because it allows me the most flexibility when defining the code style I want. Although opinionated, pre-configured tooling is available to enforce a set of sensible defaults, I prefer to manage code style rules myself.

I bundled a shared configuration under the GitHub repository shared-typescript-configuration, which allows me to share my ESLint settings across projects. I then distribute these settings as an NPM module, which I can consume in the project. This is also how the template is set up, and it creates its own eslint.config.mjs in the root, exports the config from the node module.

import base from '@dotmh/eslint-config-ts';

export default [
  ...base,
  {
    ignores: ['dist/', '/coverage', 'node_modules/', '**/*.js', '**/*.mjs'],
  },
];

Prettier

Whereas ESLint primarily targets code smells and enforces good practices, Prettier enforces the actual physical style of the code, including aspects such as which quotes to use. I prefer Prettier for many of the same reasons I prefer ESLint; it allows me to control my code style. Both tools require a little time to set up and tune to your liking, but once done, they’re set.

Again, like with ESLint, I bundle my settings into an NPM module whose source comes from the same shared-typescript-configuration repository on GitHub.

Secret Lint

Secret Lint scans code for secrets and a Husky hook that triggers when anyone attempts to commit, thereby reducing the risk that a Secret will be included in the repository. Due to the way GitHub operates to facilitate collaboration, it is complicated to remove something once it is added to a repository. Secret scanning tools that work at the CI level or as a GitHub app are great, but they don’t prevent a secret from being introduced in the first place. This lack of prevention means that once these tools detect a secret being committed, you must rotate all your secrets, which is not a small amount of work.

Commit Lint

Commit lint instead of linting code; it lints the commit messages. I have it set up to enforce conventional commits. I prefer conventional commits because they provide a structure for writing clear and concise commit messages. I am terrible at writing commit messages, let alone meaningful commit messages, but with conventional commit messages as a guide, the situation is greatly improved. I also know myself and if nothing is enforcing me to use conventional commits I will end, when I am rushed, tired or excited falling back to my typical bullshit, hence the need for a linter.

Testing

Vitest

I was recently introduced to vitest by a friend and colleague as an alternative to Jest. It labels itself as a fast, Jest-compatible testing framework that integrates with Vite. This seemed ideal for me; until recently, Jest was my preferred testing framework, Vite is my preferred build tool, and it had native support for both TypeScript and code coverage reporting with Istanbul. Vitest also had good support for working within a monorepo, which I extensively utilise (although Jest may have had that support too, I never looked into it). The template mentioned in the article is set up as a monorepo. I used Vitest on a number of both backend and frontend projects, and found it easy to use, integrate and have a nice set of functions and keywords; I like the “describe”, “it” and “expect” way of writing tests.

Istanbul

Code coverage seems to have a lot of baggage in the developer world. I like it, as it is a valuable guide to making sure that I am writing code tests covering the functionality. I don’t think it is a metric that should have much enforcement. It should be a guide. There are several downsides to relying on code coverage because, like all metrics, it can lead to a false sense of security and wasted effort without understanding what it tells you. I use Istanbul out of habit; its HTML report is easy to use and read.

GitHub Actions

Continuous integration and continuous deployment are potent tools for software development. Although there has been some interesting discussion lately about whether it is worth using a service, it is still considered valid and a requirement by many organisations. I have used many CI systems, including JetBrains TeamCity, Semaphore and Circle CI. However, my favourite CI platform was GitLab CI. Its ease of use and deep integration with the code repositories made it pleasant to work with.

For several reasons, though, I am now mostly using GitHub, so when they launched GitHub Actions, I was interested in what it offered. GitHub Actions is more than just a plain CI/CD tool; it is an event-based system that can trigger actions based on a load of events in GitHub. This allows you to build powerful workflows using it. GitHub Actions has an ecosystem; you can use first- and third-party actions in your workflows. This allows for rapid workflow development, though it exposes you to supply chain attacks like any package-based ecosystem.

I chose to use GitHub Actions in my template for these reasons. This means users don’t have to sign up for third-party services. If they are using the GitHub template, then they are already on GitHub.

Dev Containers and GitHub Codespace

Docker changed the development world. With a single command, you can have a reproducible, lightweight runtime environment that matches production to run your app. Imagine having that for your development environment. Well, that is Dev Containers. Dev Containers integrate with VS Code and most JetBrains IDES, allowing you to work seamlessly within the dev container as if it were your file system while having all the tools you need in an environment close to your production environment.

I also like Dev Containers because I love to explore other languages and tools. They allow me to test and play with those without the overhead of installing them into my main machine. This benefits from testing in a virtual machine, but with the lightweight overhead of containers.

Github Codespaces builds on top of Dev Containers, allowing you to run a dev environment in the cloud that you can either attach to through a browser with VS Code, or directly in the VS Code app or JetBrains IDE through JetBrains Gateway. This is great if you want to work on a project without downloading it or using someone else’s or an underpowered machine. Codespaces cost money and aren’t the end-all solution for daily development, but can be really useful in certain situations.

I want to write a full post on dev containers soon, but if you wanna learn more, I have a repository that contains several dev containers that are also deployed as packages in GitHub, ready for use.

Bill Gates

I was conflicted about including Bill Gates. I think that Bill Gates has made both positive and negative contributions to the tech world. I do look up to Bill Gates while still accepting that he has made some damaging decisions in the past. The main reason I have him on my list is that his work at the beginning of the microcomputer revolution sparked my excitement and interest in technology. He wrote and ported Microsoft BASIC to a vast majority of early Microcomputers, such as the C64 and Amstrad. He was also an essential part of inventing the PC platform, with Microsoft DOS, and arguably helped promote the PC platform through further refinements to DOS and then Windows. Bill Gates also oversaw the release of the XBOX brand, Directx, and .net, which have been significant influences on me.

Read more on Wikipedia.

John Carmack

John Carmack is a much less divisive person to put on this list. In the early 90s, John Carmack was a massive contributor to the world of computer graphics, and more specifically, 3d graphics. John Carmack led innovations with Commander Keen that brought smooth scrolling to the PC, including Wolfenstein 3d, a pioneer in 3d graphics. Doom raised the bar again and significantly advanced the first-person shooter genre in popular culture. Then, Quake brought lightning to the computer graphics world, making 3d games look increasingly amazing. These are all fantastic things, but for me, however, it was Doom and Doom map editing that grew my interest in computing. The fact that he and the others at ID decided to open-source the game engine has not only contributed to my learning but also to the software industry as a whole.

If you want to learn more about John Carmack and the development of some of these seminal games, I recommend the book "Masters of Doom" by David Kushner.

Read more on Wikipedia.

Steve Wozniak

Born in the 1950s and present at the dawn of the computing era, Steve Wozniak was a pivotal figure in the early days of the computing industry. If Steve Jobs was the person who sold the personal computer to the world, then it was Steve Wozniak who designed that computer. At the birth of the microcomputer in the US, there was a trinity of pioneering micros: the TRS-80, the Commodore PET, and, of course, Apple’s Apple II, designed by Woz. I believe it's challenging to overstate Steve Wozniak's contributions to our modern technological world. The Apple II didn’t just revolutionise the computer; it went on to inspire millions of people to contribute to the field. Steve Wozniak went on to co-develop the Macintosh, another groundbreaking computer in its own right, which allowed Apple to continue innovating and popularising new technologies like the iPod, smartphone, and tablet. I think that I can safely say that Steve Wozniak is one of the giants whose shoulders I stand on today as a software developer.

Read more on Wikipedia.

Anders Hejlsberg

Unlike the others on the list, you may not be familiar with Anders Hejlsberg, but to me, he is one of the most significant individuals on this list. In my recent blog post, “Returning to Windows,” I mentioned Anders Hejlsberg, which may be the first time you've heard of him. I attended college in the early 2000s to study computer science, and during that time, two of the programming languages we used were Borland Turbo Pascal and Borland Delphi. Delphi is to Pascal what Visual Basic is to BASIC. These were the languages and technologies that I enjoyed and wanted to explore further; these are what kick-started my life as a software developer. Anders Hejlsberg was the lead creator of both. If it were only for that alone, Anders Hejlsberg would be a hero to me. However, later in my career, I started writing in Typescript. I adopted it as a language to write in early on and have been writing almost exclusively in TypeScript since 2021. This year, 2025, I started learning the .net Framework through C#, and as you may have guessed by now, Anders Hejlsberg was the lead architect for both.

Read more on Wikipedia.

Yukihiro Matsumoto

I have a habit of learning a new Language. When I am comfortable with my primary language, I try to learn something new. This provides me with insights into new ways of doing things and new ideas, as well as access to a new language and its associated tooling and ecosystem. The first language that I ever learnt, once I was comfortable with the web stack I was using (PHP, JavaScript, HTML, etc), was Ruby. Ruby showed me a whole new world. It was very object-oriented, which gave me a much better insight into that way of working, and it was the first language for me that wasn’t inspired by the C syntax. I went on an adventure, and for a few years, I pivoted my career to working with the Ruby programming language; I have recently put that knowledge to use again. I believe the practice of learning new languages is essential for building a more well-rounded development career, as it teaches you ways to solve different problems, introduces new tools, and, of course, provides a new skill that you can apply.

Read more on Wikipedia.

Ryan Dahl

Ryan Dahl was the person who made JavaScript popular everywhere and was the creator behind Node.js. He may have regretted it, but it changed modern web development and, by extension, modern software development. Before Node was invented, JavaScript was pretty much confined to the frontend and the browser. After Node, it has all changed, and now you can use Node everywhere. Electron allows you to create desktop applications, while React Native and Ionic enable you to build mobile applications. JavaScript is now a scripting language in other tools, like a game engine. I have mentioned before that I use TypeScript daily and have utilised it in all these contexts. I can’t underestimate the influence Ryan Dahl has had on my career and daily life.

Read more on Wikipedia.

Linus Torvalds

I am not sure if I need to tell you who Linus Torvalds is; he is the man who made Linux, and to this day, he is the lead developer and architect. The impact that Linux has had on the programming and computer worlds is immense. Apart from Desktop and Laptop computing, it would not be an exaggeration to say that Linux powers the world. Yes, other operating systems exist and do work in many fields, but Linux dominates. Linux powers the servers on which I deploy my code every day, the servers that run my services, the dishwasher that washes my dishes, the smart TV on which I watch my entertainment, and half of the devices on which I play my games. Linux changes the world by providing a well-made, secure, Unix-like, and, most importantly, free operating system.

Read more on Wikipedia.

Tim Berners-Lee

Another person whom I am not sure I need to introduce. The modern world's most powerful tool and arguably most important invention was, in a large part, the idea of Tim Berners-Lee. I have mentioned how others inspired me to code; it was the World Wide Web, where I started. I started by building my own web pages to allow me to share my game maps. I started with just plain HTML, and as I gradually added more functionality over time, I learned additional languages, including JavaScript, CSS, PHP, SQL, and eventually. NET. If it wasn’t for Tim Berners-Lee and his idea, I am certain I wouldn’t be where I am today. There was something magical about contributing to this fantastic invention. In 2025, we live in two worlds: one physical and one of information, and Tim Berners-Lee invented the language and technology that underpin that world. Yes, many have added to it over the years, but Tim was the catalyst that brought it into existence.

Read more on Wikipedia.

Honourable Mentions

All these individuals have had an impact on my career development and enhanced my skills in one way or another.

All these are LinkedIn links.

• Dylan Beattie - A Speaker and Developer who opened my eyes to so many interesting topics.

• Kevlin Henney - Another Speaker who has made me think about how to be a better developer

• William Munn - An Amazing developer, mentor and lead who drove me to write better code

• Mark Bold - My first lead after I became a professional developer, who taught me how to be a professional

Standing On The Shoulders Of Giants

The people listed above are the giants I stand on the shoulders of, but they are just the top level of giants. Under these people are other giants that they are standing on, and under them are more giants that they are standing on. This giant among giants goes back in time to the dawn of humanity. These giants also come from all walks of life, genders and races. Just because I have chosen these people to highlight in my personal story doesn’t mean that I disregard the contributions that came before them.

The first machines that I used were these primitive computers, with my first real experience being on a BBC Micro from Acorn. I am from the UK, and the Beeb, as it was affectionately known, was the de facto school computer, in no small part because it was sponsored by the British Broadcasting Corporation's Computer Literacy program. I also used other micros of the time, including the Commodore 64 and the Spectrum, as well as early incarnations of the IBM PC.

Due to the high cost of computer ownership, even though microcomputers had driven the price down, it was still a significant expenditure; a family would tend to have only one, which was shared, and we were much the same. We acquired an IBM-compatible PC relatively early, but it was a 386, and from then on, we had a PC. This meant that I grew up using the Microsoft family of operating systems, starting with MS-DOS and moving through Windows 3.11, 95, 98, NT 4.0, Me, 2000, and eventually XP.

However, in 2006, when deciding on my next upgrade, I began to consider a Mac. My interaction with the Apple world had been limited up until that point, as mentioned, in the UK, Apple wasn’t the default in schools, and at home, I was using a PC. I had used a Mac for one term in college, but that was about it. The thing was, I am a music lover, and during this time, a massive shift was happening in the music industry. Music was going digital, and the Apple iPod was leading the way. A few years earlier, I had joined the revolution, getting a fourth-generation iPod. This means Apple was now on my radar. My computing needs at this time weren’t complex. I was dabbling in coding, making music, and surfing the internet - all things I could continue to do on the Mac. In 2006, I purchased a white MacBook.

This started a 19-year love affair with the Mac platform. One of the most significant contributors to this was the recent career change. I had been building software as a hobbyist since my early teens, but in 2008, I took that passion and transitioned to working full-time as a professional Web Developer. My early career involved working with the LAMP (Linux, Apache, Mysql, and PHP) stack, which meant that OS X was an ideal platform for professional web development.

To understand why the Mac was well-suited for web development, it's helpful to have a little background on operating systems. By 2008, there were essentially two major families of operating systems used in desktop and laptop computing. These were Windows and Nix (a catch-all term for Unix and Linux). MacOS (as of version 10) falls into the Nix family, being based on Apple’s XNU Unix kernel, which incorporates large parts of the Freebsd kernel. As many open-source projects target the Linux ecosystem, and Unix been a close cousin of Linux, this means that much of this tooling also works on Macos. This close compatibility between Linux and Unix also means that my development environment closely matches the production environment, which, of course, is the LAMP stack, which is Linux. However, unlike Linux, MacOs was a commercially supported operating system, which meant that you had access to a lot of commercial software packages, such as the Adobe suite. These tools were heavily utilised in the world of web development, particularly in the mid-2000s, before the emergence of Sketch and Figma.

From 2006 onwards, I invested in the Mac Ecosystem, purchasing several MacBook Pros and also acquiring the iPhone and Apple TV. I was an Apple fanboy, often defending the ecosystem, and recommended it to others where it made sense. In 2025, it became clear that my 2019 MacBook Pro was nearing the end of its useful life as a primary machine, and it was time to update. Initially I was in two minds about which Mac to replace it with, I didn’t tend to use it as a laptop, most of the time it stayed docked to my desk, that along with the fact it suffered from over heating in summer meant that my thinking was between another MacBook Pro or a Mac Studio.

I visited the Apple website to configure a Mac Studio and a MacBook Pro. I always acknowledged that you pay a premium for Mac hardware. I was okay with that because I felt I was getting a premium product. This time, however, it was different. The multipliers of the cost of just getting a decent amount of RAM and storage seem so overpriced. This prompted me to explore alternatives, such as Linux or possibly Windows. If I could switch to standard hardware, it would reduce the cost and make it easier to customise my experience to best fit my needs, and it wouldn’t cost body parts to obtain.

This wouldn’t have even been a consideration back in 2008, but the world has undergone significant changes in the last 17 years. You don’t need your development machine to match production; Docker runs everywhere; you can spin up a Docker container and get the exact same environment that you are using in production. The most significant design tool in modern web and UI design is Figma, a browser-based tool that natively supports Windows, allowing it to run on almost any platform.

So, I'm not going to beat around the bush; you know from the title that I went with Windows, and more specifically, a custom-built PC running Windows 11 Pro. So, why Windows? Well, Windows and Microsoft are very different beasts from what they were in the past. Microsoft has invested heavily in being more open-source, with tooling such as Visual Studio Code being open-source and languages like TypeScript, as well as their primary .net platform, all being open-sourced. Windows also now features the Windows Subsystem for Linux (WSL), which allows you to interact with your computer for the most part as if it were running Linux. When that isn’t possible, PowerShell presents a much more powerful command-line interface than the old DOS prompt, with aliases for standard Linux commands. You can even install some of the tools I use every day in PowerShell, such as EZA and BAT. Windows can also run games, pretty much any PC game in the universe can run on Windows, whether you like it or not, Windows is the de facto standard when it comes to PC games.

There was also another reason that I decided to go with Windows, since about 2015, I have been a full-time JavaScript developer. Since about 2018, this has meant primarily writing TypeScript. I love working with TypeScript so much that I even created a template for building new TypeScript projects. I use TypeScript almost exclusively, both at work and on my side projects. Every so often, though, typically when I am pretty advanced in a language, I like to learn a new one; this keeps life interesting and also shows me new ways of doing things, new ideas, and patterns that I can apply to my primary language. This year, I started learning C#. I chose C# because it is a general-purpose language that can be used to develop a wide range of software. It was also designed by Anders Hejlsberg, the primary designer and developer of TypeScript.

The final reason for going with Windows was for Music production. I create music as a hobby, mostly using software these days, and my key tool in this is Steinberg Cubase. I know some alternatives run on Linux-based operating systems, but this is just a hobby, and I am not interested in learning new software so that I don’t have to use Windows. I have also invested in Cubase, as well as instruments, effects, and other plugins that work with it.

The great thing about custom-building my machine is that I can decide what I put on it. If I wanna try Linux, then that is possible. Gaming on Linux is continually improving. Steam and the Steam Deck have made Linux a pretty good platform for gaming. I may try daily driving Linux in the future, though I opted for an Nvidia video card, which may make it harder to do so. For now, I am a happy Windows user.

I have been interested in the tech sector for over 30 years, since I was a child and have worked full-time in it for about 17 years. I have witnessed many trends emerge and fade, from the widespread adoption of the web through the rise of the smartphone and Web 2.0 to the crypto boom and the advent of voice assistants, but apart from perhaps the dot-com bubble, I haven’t seen anything on the same scale as AI.

Over the last few years, every major and minor tech company has attempted to incorporate AI into its products and offerings, regardless of whether it makes sense or not. I don’t think there is a service you can sign up for that doesn’t feature AI as a key component. Hardware companies are incorporating AI into product names, and giants like Microsoft, Apple, and Google are integrating it into the core of their products and services.

I don’t need to tell you these things. If you are reading this, you likely understand the significant disruption that AI has caused in recent years. However, I think this one will fizzle out in time, like the trends that came before it. AI is undeniably an impressive technology. I use GitHub Copilot myself, and I don’t think the concept will disappear, but I think the hype will. I expect that AI will experience a peak similar to the dot-com bubble did in the early 2000s.

The web remains a key part of our lives 25 years later, but being online is now the norm for a business, not a unique selling point, and that is where I see AI heading. I think we peaked too early with AI; while the technology is impressive, it has deep mistrust.

Firstly, the information that AI provides can’t be trusted, as evidenced by high-profile incidents. AI hallucinates (that is, it returns incorrect information as fact) regularly, and honestly, this problem only worsens. When you have to do the work to fact-check the answer you are getting from AI, is it benefiting you? The lack of trust in AI’s output is a significant problem for AI companies, as it causes AI to be perceived as a novelty rather than a helpful tool.

Another significant issue that AI must address is legal concerns. The major AI models from big and small companies have likely been at least partly trained on data sourced illegally or whose legality is in a grey area. Generative image AI has faced massive backlash from artists and the public for stealing artists’ work. These issues surrounding legality deter professional users and corporations, which, as the highest revenue-generating users, could cause long-term harm to AI-focused companies.

In addition to the legal concerns, AI will also face regulatory challenges. Many high-profile tech, academic, and legislative leaders have expressed concerns about the potential effects of unregulated AI use on society. These concerns mainly stem from the use of generative AI. As AI improves at creating realistic video, audio, and images, it will become increasingly more complex to distinguish between real and fake content. This poses a significant risk to society, as AI-generated content could be easily used to manipulate people and seed civil unrest. These concerns and challenges suggest that AI will likely face further regulation in the future, similar to the regulation of the web.

Even with my concerns about the AI hype and the challenges it faces as it grows from a novelty to mainstream adoption and deployment, I do think, like with the web and the rise of smartphones, we are standing at the beginning of a monumental shift in how, as a species, we interact with our technology.

One risk I have not mentioned in this article is the direct financial risk. This is mainly because it is hard to quantify. Using trained models at this time holds a lower financial risk. Companies keen on establishing a user base for their models often allow use, especially for experimentation and evaluation, at a very low cost. However, developing and training a model is an expensive investment. You require high-end hardware, which comes with substantial capital costs and operating expenses. AI consumes vast quantities of energy, which, in addition to being costly, also presents environmental challenges. In the current climate crisis, this can’t and shouldn’t be overlooked.

If you are excited about AI's prospects, I encourage you to exercise caution and weigh the risks as you move forward. A significant amount of money is invested in AI, but, as mentioned in this article, I believe it is primarily driven by hype. If AI can provide tangible benefits to your business, product, and/or users, then it is worth exploring. However, as with all things, trying to find a problem that fits the solution is not sustainable in the long term.