Like many others I speak to in tech (and other fields) I have struggled with imposter syndrome massively at different points in my career (and life in general). I think this is all too common in software because there is no checklist/certificate/exam that proves that you are, in a binary fashion, ‘good enough’, … which is at odds with other professions (you either are or aren’t a qualified Doctor, or a chartered Accountant etc).

At times, with other inter-related things, imposter syndrome has compounded with other challenges of life and really hampered my mental health and happiness as a human. I was in a tough spot (‘a real pickle’ as my late Nan would have said) a while ago and, alongside some other reasons, I was really struggling with my mental health and sense of worth. Desperate to find a technique to get a handle on it, I read Dr Jessamy Hibbard’s book and the main takeaway for me was all about cold, hard, evidence leads proof!.

For life in general, I found the exercise of ‘write down literally everything you have ever achieved in life’ to be really cathartic. This means every exam passed, saving for holidays, having the courage to try a new sport, painting a room in your house … everything! As per the suggestions, I did this over several days and weeks as different thoughts kept coming to me. That was a really useful reflective exercise.

For work specifically, the technique I use (which is similar to the above) is to evidence against our organisation’s competency framework. We have a skills matrix for all different levels of engineering and the behaviours expected at each level (as do most companies, … as should all companies, I believe). At the end of each week I spend 15 minutes writing evidence against each of the areas of the framework. Just a few bullet points each week. This is a private process and tool for me to reflect on, I don’t share it (although I wouldn’t have any problem sharing it).

The effect: looking back over a few months I can see looooooads of evidence of me doing different parts of the job across multiple weeks. Right in front of my eyes.

Surely if I am doing and achieving all of this across all areas of the ‘senior engineer’ job spec, … that means I am doing what a senior engineer would be expected to do … therefore I am a senior engineer! This helps quieten the voices in my head.

The other bonus of this is that it makes it easier to identify where I have ‘evidence gaps’ that I can use to tailor individual quarterly goals, and it’s also super useful for me to reflect on at the end of each quarter.

Conclusion

I hope you found this useful. How do you manage imposter syndrome? Feel free to message me on LinkedIn :)

I’ve been using Copilot to improve my productivity a lot in 2025. I’m always exploring how it can serve me best. I’ve written about it before here and lead sessions sharing my learnings across Howden’s engineering function.

I’m convinced the best engineers are going to be those that can play the orchestrator mode (shepherding AI to do the 80%) and the heart surgeon role (locate and dive into a very specific line of code to solve a nuanced and tricky issue - the 20%).

Here are some of my top tips so far:

1. Ctrl+V: Pasting in screenshots to the chat window - ‘A picture says 1000 words’ and all that. I constantly share screenshots with Copilot to give quick context to what I am trying to do. E.g. if I want it to debug a UI feature I will screenshot the browser, the open developer tools and ask it whats wrong. Just screengrab and paste it into the command. Another use case is when I don’t understand why VS code is behaving a certain way - I just screenshot the area of the screen instead of trying to describe the issue.

2. Add logs so we can debug this. - sometimes I have seen Copilot get stuck in loops when it’s trying to debug a particular issue. It suggests something, which doesn’t work, and then suggests something else, which doesn’t work … and then goes back to option 1 again! This is particularly acute when the bugs are due to race conditions, asynchronous behaviour and complex interactions in UIs. Copilot can rapidly add tonnes of Console.WriteLine() statements in seconds to help you spot what’s going on, quickly (or, better yet, to help it understand what’s going on! See notes on screenshots above).

3. Are we using the right pattern/approach? What would be idiomatic for [languageX] - Building off of 2 above, sometimes I have noticed Copilot getting confused and spinning into loops by adding more and more code that doesn’t solve the problem. As the human in control, in these scenarios I ask Copilot ‘hang on a minute, are we trying to solve this using the wrong pattern?’. I saw this most recently with an issue relating to keeping different areas of our UI in sync. After asking Copilot, it explained to me that the way we were using events wasn’t best practice and wasn’t idiomatic, and instead it would be more idiomatic in Blazor. note: this is where humans can add value and experience of senior engineers is valuable; I was able to refer to the way that React works with params (‘props’) and understand this issue that way.

4. Give it permission for all git commands - except push. I’ve saved loads of time by giving Copilot the ability to run most git commands (add, merge, pull, commit etc) but I have explicitly asked it not to push on my behalf. This lets me review each micro change it makes to make sure I understand and agree.

5. 'quiz me!' - you are responsible for your code, so to make sure I understand what’s being proposed I regularly ask Copilot ‘create a quiz with 3 questions about the core concepts we have covered so far’. This is particularly useful when using Copilot as a learning tool. When I am working on a side project to learn a new technology I lean on this heavily to get the best combination of ‘let’s build a real thing quickly so I can see how it works’ and ‘I want to make sure I understand the theory’. This can also be a fun way of getting started on a project to ‘warm up’ for a session of coding.

Conclusion

I hope you found this useful. How are you using Copilot? Feel free to message me on LinkedIn :)

1. User stories + TDD + CoPilot is a huge boost to speed while maintaining accuracy and understanding
2. Analysis of your codebase and recommendations for best practices can boost learning and generate documentation at the same time.
3. Easily increase unit test coverage of existing code (we increased by 5% in a month while adding more code)
4. copilot-instructions.md is a great place to evolve a useful and usable style guide that you can use to direct CoPilot.

Overview

Agent mode in Visual Studio CoPilot came out about 6 weeks ago, and I’ve been playing around with a lot in day-to-day work to see how it can improve my workflow.

1. ‘Agentic TDD’

This is a skill I have been actively working on and refining recently. It’s a kind of meta-programming, in a way.

I’ve long been a fan of using TDD (Test Driven Development) as a development practice for many reasons. The obvious ones are that by the time you are finished, you have tests written (instead of moving onto the next feature) and self-documenting code. But another reason, with my product management hat on, is that it constantly forces you to think about the problems you are solving while working on the solution (e.g. “I want a method that formats the date of birth field on the screen … so that users don’t have to calculate this themselves”), which I think keeps re-focussing you on what you are trying to achieve.

One of the challenges I have always found with TDD is how frustrating and long-winded it can be to set up the infrastructure and boilerplate needed for tests, especially if you are creating tests for a new class or file that doesn’t have any prior art. Anyone who has written unit tests in real production apps knows how fiddly and time-consuming it is to mock all of the dependencies needed for unit tests etc etc. We’ve all been there when you need 50+ lines of setup boilerplate … all for a method assertion that is one line of code. However, CoPilot changes that! It’s extremely good, though not perfect, at generating all of that setup and boilerplate.

This leans into the motto I’ve read about: “outsource your tasks, not your thinking” to CoPilot.

This has led me to change my workflow for most tasks to:

1. In the CoPilot chat window in my IDE (Visual Studio at the moment), share some context and User Story (context and Given/When/Then).
2. Ask CoPilot to generate a failing test for the first acceptance criteria.
3. Inspect the tests it generates and fix/tweak them. Often, I encourage CoPilot to generate extra scenarios, fix a few import errors, or subtly change what is being tested. Here is where humans, with experience and domain knowledge, can really add value. For instance, instead of just getting CoPilot to generate unit tests to calculate an insurance premium, nudge CoPilot to add realistic business scenarios based on cohorts/personas (“young drivers scenario where they will have higher premiums”), etc.
4. Ask CoPilot to fix the tests. Sometimes I literally just say “fix this” and it does it.
5. I have set up our CoPilot-instructions to ask CoPilot to build and run all unit tests after every change it makes. I inspect the results of the tests (usually they now pass).
6. Inspect CoPilot’s solution: often I have to make a few tweaks, but not much; I suppose when you break down most work items into very small pieces, everything is usually a just a solved problem really, so CoPilot finds this easy.

Another good habit alongside TDD that this encourages is writing down a proper user story, which, again, aligns everyone in the team around what it is you are really doing, and why.

I’ve been surprised by good this approach above is; CoPilot has often added really neat UI layouts and implementations that I wasn’t thinking of.

Also, I have added instructions about using TDD and my team’s preferences into our CoPilot-instructions.md file (more on this below). I have also added some notes about style and coding preferences in here, which seem to be getting used (most of the time). More on this below.

2. Living style guide

Whenever CoPilot doesn’t generate code or comments in a way that suits our team’s style (or best practice), pI update our coPilot-instructions.md file (which sits in our application solution alongside other documentation) with notes about how things should be done. I have found that this is evolving into a useful and usable ‘living’ style guide for our project.

A few months ago I led an initiative at work to author the first draft of our engineer department cross-team C#/Blazor style guide. It lives in a shared Wiki and doesn’t really get looked at (largely because it’s separated from our workflow). The style guide section of the CoPilot-instructions file is starting to replacing this, and at a certain point I will probably break it out and share it with other teams.

A flavour of of our copilot-instructions (redacted and sensitive information removed):

Context

### Business context
* We work for Howden Insurance, a global insurance broking company.
* The work we do is regulated by the FCA and other UK/Global institutions.
* <some notes here about how our users use our apps, how they feel when using their apps, how we want them to feel, what they are trying to achieve, what their personas are>

### Code style
* Always consider accessibility.
* Use best practice and latest C#/Blazor features. Try to use the same style and patterns that exist already in the codebase, and if these two things conflict, use the best practice approach but make this clear to me in comments where you have deviated from the usual style.

### Testing
* We use BUnit and NUnit for unit tests.

### Security
* To mitigate against the risk of XSS attacks, please do not use `MarkupString` or any other method that means user input won't be properly validated and sanitized before being displayed in the UI.
* Consider OWASP top 10 security risks when adding new features
...

3. Increasing unit test coverage

Building on the above, the habit I am getting into is whenever I touch a new area of our codebase, I review the unit test coverage and if it’s lacking, then use CoPilot to generate some tests before we add more (via TDD). This increases our coverage and increases my confidence that I haven’t broken anything.

You are probably thinking, “you should be doing this anyway,” and, yes, I completely agree. However, the difference now is that it takes CoPilot seconds to generate dozens of test cases for existing code that I can then tweak, review, and modify, instead of me having to write them all out by hand which, being realistic, isn’t always feasible given deadlines and the need to add good quality to the new work being introduced. This has been a 10x (or more) time saving for me and has led to us increasing our unit test coverage 5% in a month (despite adding loads of new lines of code).

Interestingly, there are a few times where we have decided to refactor some older, existing code to make it more testable, which has resulted in better code!

4. Analysis of your codebase

When I first joined the team I am in now, I hadn’t worked with Blazor, C# or .NET before. I wanted to understand the approach our app used for state management, and whether this was done consistently and followed best practices (especially compared to other projects I had worked on). It took a bit of nudging, lots of back and forth in the conversation with CoPilot (e.g. “please give some real examples”), but I got a great result. This now lives in our documentation for others to view, and it reinforces CoPilot to continue using these patterns (for consistency).

Similarly, I did a similar exercise for analysing our approach to security – what is our application’s approach to auth? Does it follow best practices?

I started by writing down a numbered list of my understanding of how authentication/authorization works with our application in terms of the user flow and what methods are called etc. I then asked CoPilot to review it, correct it, and provide me with snippets and file locations of where the configuration is. It wasn’t always right, but it got me 95% of the way.

A massive benefit of using CoPilot to co-author these documents is speed of learning and being able to produce useful and relevant documentation to add to the solution for others as well. A double win!

Conclusion

I hope you found this useful. How are you using CoPilot? Feel free to message me on LinkedIn :)

I’ve been really enjoying trying out the new Copilot AI capabilities that are have been (rapidly) made available in the past few months.

I’ve been using Copilot in agent mode with Visual Studio since it was made available recently. If you aren’t aware, this mode is designed to take prompts and commands from you and make real-time live code changes to your codebase in front of you, instead of just suggesting changes inside of the chat window (which is what we had with ‘chat’ mode)

A really neat trick I discovered last week is taking a screenshot of a wireframe (e.g. in Figma) and uploading the image as part an interaction with Copilot.

I had a screenshot of a wireframe of a table of information that we wanted to add to our UI. I specified that I wanted Copilot to produce the UI markup (I am using .NET’s Blazor and therefore the markup is in razor syntax) and all the relevant model bindings, and to follow examples of a few similar code files. It took some nudging, but it was pretty successful.

I was then really pleased when I continued to iterate on the initial static markup to enhance the table to make it dynamic; I wanted the contents of the table to appear depending on an option a user has selected elsewhere in the app (this was already built at this point).

You can read about other previews here.

(All views expressed are my own).

Overview

.NET 10 will be released in late 2025, but the previews are already being released (10.4 was released in May).

Below are my thoughts on what’s been announced and, in particular, what’s more relevant to those of us working with Blazor.

Full announcements: .NET 10 Preview 4 is now available! - .NET Blog

A more ‘meta’ point

This is more of a comment on the .NET release notes structure, but I often find myself naturally asking ‘what does this apply to?’ and ‘what previously existed?’ when looking at new features to contextualise them. I often turn to the CoPilot app to give me some more background. It would be useful if some of this information was included in the release notes from Microsoft themselves, IMO.

E.g. this was particularly useful:

tell me more about integration testing with Kestrel in .NET 10.4

what types of .NET application is this relevant to?

https://github.com/dotnet/core/blob/main/release-notes/10.0/preview/preview4/aspnetcore.md#use-webapplicationfactory-with-kestrel-for-integration-testing

Blazor WebAssembley runtime diagnostics

In .NET 10 Preview 4, Microsoft are introducing enhanced runtime diagnostics for Blazor WebAssembly apps, which include:

• Performance traces: You can now collect detailed performance profiling data.
• Memory dumps: Capture memory snapshots for in-depth analysis.
• Runtime metrics: Monitor runtime behavior such as memory usage.

These diagnostics are now built into the WebAssembly runtime, rather than relying solely on browser developer tools or external profiling setups. I haven’t yet explored these but I am keen to see what additional insights we can gain about our application to give our users a better experience.

Use WebApplicationFactory with Kestrel for integration testing

There is a new and improved way to create integration tests which allows for more realistic tests, which should bring more confidence.

This is particularly for applications have endpoints exposed from Blazor WASM hybrid apps.

Previously, using WebApplicationFactory to setup integration tests used an in-memory HTTP server called TestServer, but in 10.4 WebApplicationFactory can now be setup to use Kestrel which is the actual web server used in production by a .NET app.

Using Kestrel instead of TestServer in tests enables:

• End-to-end testing of real HTTP features (e.g., HTTPS, HTTP/2, WebSockets).
• Middleware and pipeline validation under real server conditions.
• Testing of custom server configurations (e.g., ports, certificates, limits).

Copied from some examples online, here is an example setup to give you a flavour of how this could work in your integration test setup:

var factory = new WebApplicationFactory<Program>()
    .WithWebHostBuilder(builder =>
    {
        builder.UseKestrel(); // Use real Kestrel server
        builder.ConfigureKestrel(options =>
        {
            options.ListenLocalhost(5001); // Customize as needed
        });
    });


factory.CreateClient() ...

More here

Why?

I wanted to increase my understanding of what Azure has to offer and how it works. I’ve been using Azure since joining (I’d only ever worked with AWS before) and I wanted to understand the landscape of Azure so I know where to look when I run into a problem. I was also curious to understand what I didn’t know.

I found the general ‘cloud concepts’ were useful (looking at availability zones, IaaS vs PaaS vs SaaS etc) and it was good to learn more about VMs at a high-level. However, I think I would have learnt more about the ‘product-specific’ things by clicking around the Azure portal and googling/asking CoPilot when I got stuck.

Thoughts on the exam

I have never taken an online exam remotely, and I was pleasantly surprised at how robust their integrity and ‘anti-cheat’ procedures were but also how frictionless and painless it was. Bearing in mind this process involved me having to take pictures of my Id, myself, my working area, a phone and video call with one of the exam invigilators to check my working area was free from notes etc. I was even reminded during the exam, via chat, not to speak out loud (I was reading questions out loud to myself, but I guess they thought I could be asking the questions out loud to someone in the next room?)

There is something to reflect on here about the user experience that I am working on in my team every day…

How I prepared

I prepared for it by going through the online learning path that’s offered my Microsoft. Its nice and bite-sized and had a few interactive exercises. I have also been using Azure in my daily work, but I haven’t spent much time setting up new things/debugging Azure which is really where you learn things.

I am fortunate that we get some ‘personal development time’ in our work calendars at Howden, which was good to get my head down and learn this stuff.

I spent about 2 hours following the Microsoft dedicated online course with some time googling and checking things out in the Azure portal. The exam was about 40 questions and only took 15-20 mins (with about 20 mins beforehand to login and checkin etc.)

Final thoughts

Would I recommend it?

Thats the key question! I would recommend it to people that are new to Azure and working in roles, like me, as a developer, where I am working with Azure services regularly but not necessarily setting things up services/config myself from scratch (something that an enabling cloud team would usually do). Even if you don’t do the exam I’d say it’s worth reading through the online course and doing some of the mock exams (which would only take you 2-3 hours of reading time).

Signed by Satya

Finally, with my ‘product development’ hat on, I absolutely loved that my digital certificate is signed by Satya Nadella. I thought that was a really nice feature that would have cost Microsoft virtually nothing to build.

You can read about other previews here: [2025-25-03-thoughts-on-dotnet-10_1-and_10_2-previews]

(All views expressed are my own).

If I have misunderstood something or you disagree with me I would love to chat 😃 #everydayaschoolday

Full announcement: .NET 10 Preview 3 is now available! - .NET Blog

Blazor and ASP.NET Core

Declarative model for persisting component state 💪

Who will this benefit: This is useful for any server-rendered components (i.e. any component that isn’t Interactive WebAssembly render mode.

What is this all about: Persisting component state means saving some data during prerendering and restoring it when the app becomes interactive (in the browser), so there is no need to refetch is and the user experience is sharper.

What’s the current approach: Currently, there is a lot of boilerplate needed to support this and it was quite manual and involved being careful with serialisation:

1. Inject PersistentComponentState into your component.
2. Register a callback to save state during prerendering.
3. Read the state back when the component is interactive.

With this new feature, you can just decorate a property with the [SupplyParameterFromPersistentComponentState] attribute.

// On the server, Forecasts is loaded and persisted.
// On the client, Blazor restores Forecasts automatically—no extra code needed.
@code {
    [SupplyParameterFromPersistentComponentState]
    public WeatherForecast[]? Forecasts { get; set; }

    protected override async Task OnInitializedAsync()
    {
        if (Forecasts is null)
        {
            Forecasts = await WeatherService.GetForecastAsync();
        }https://learn.microsoft.com/en-us/credentials/certifications/azure-fundamentals/?practice-assessment-type=certification
    }
}

Validation support in minimal APIs 🛡️

Who will this benefit: anyone that has APIs defined using minimal APIs.

What is this all about: Minimal APIs are a way to define HTTP API endpoints with very little boilerplate. You typically write them directly in your Program.cs or a similar startup file, using methods like app.MapGet, app.MapPost, etc. They are concise and great for small services or microservices.

    app.MapGet("/hello", () => "Hello World!");

Controllers (classes that inherit from ControllerBase or Controller) are more traditional. They are decorated methods with attributes like [HttpGet], [HttpPost], etc. This approach is more structured and is often used for larger applications.

    [ApiController]
    [Route("[controller]")]
    public class HelloController : ControllerBase
    {
        [HttpGet]
        public string Get() => "Hello World!";
    }

I personally prefer minimal APIs because I find them more lightweight with less boilerplate code. Minimal APIs also feels more like just writing more C# code and feels more ‘organic’ to me. I also like them because of how similar they feel to defining endpoints in Express (popular NodeJS server) which was where I first started.

Current approach: validation logic inside of the api body with business logic, not as a decorator.

using System.ComponentModel.DataAnnotations;

public class Person
{
    [Required]
    public string Name { get; set; } = default!;
    [Range(0, 120)]
    public int Age { get; set; }
}

app.MapPost("/people", (Person person) =>
{
    var validationResults = new List<ValidationResult>();
    var context = new ValidationContext(person);
    if (!Validator.TryValidateObject(person, context, validationResults, true))
    {
        return Results.ValidationProblem(validationResults
            .ToDictionary(
                v => v.MemberNames.FirstOrDefault() ?? "",
                v => new[] { v.ErrorMessage ?? "" }
            ));
    }

    return Results.Ok(person);
});

New approach:

app.MapPost("/products",
    ([EvenNumber(ErrorMessage = "Product ID must be even")] int productId, [Required] string name)
        => TypedResults.Ok(productId))
    .DisableValidation();

Validation support looks useful and is something I will bear in mind when we need consider adding more endpoints. This certainly makes it more attractive to use them with our app.

More info: core/release-notes/10.0/preview/preview3/aspnetcore.md at main · dotnet/core · GitHub

#C 14 new features in 10.3

Null-conditional assignment 🤫

This assigns a value to a property or field only if the containing instance exists. This is a neat way to reduce boilerplate and I’m already used to using nifty shortcuts for working with nullable properties with a more compact syntax (e.g. null conditionals) so making use of this syntax for nullable objects seems like a logical extension. I like this!

More here: core/release-notes/10.0/preview/preview3/csharp.md at main · dotnet/core · GitHub

Extension members ⛓️

Whats this all about: extension methods are a way of extending a C# class - basically defining methods in a separate file the main class definition. This is useful for extending third-party libraries (I have never actually had to do this) and also to make unit testing functionality easier (which is a pattern I have seen a fair bit).

What the current approach is: the end result is still the same, but the new extension blocks make code easier to read and mentally group things together:

public static class Extensions
{
    extension(IEnumerable<int> source)  // new!
    {
        public IEnumerable<int> WhereGreaterThan(int threshold)
            => source.Where(x => x > threshold);

        public bool IsEmpty
            => !source.Any();
    }
}

var list = new List<int> { 1, 2, 3, 4, 5 };
var large = list.WhereGreaterThan(3);
if (large.IsEmpty)
{
    Console.WriteLine("No large numbers");
}
else
{
    Console.WriteLine("Found large numbers");
}

Benefits of the new approach I think this makes extension functionality eaisier to manage, but a word of caution: I can see this potentially getting a bit out of control; my instinct is that the ‘supporting’ methods in a block should be small, lean and as simple as possible to avoid the extension methods becoming bloated and larger than the class they are meant to extend. E.g. the examples online are for little helpers like IsEmpty() which I think is appropriate, but I would want to keen an eye on this. Perhaps one for an internal C# style guide to define when a method in an extension block becomes ‘too big’ 🤔

Conclusion

Thanks for reading. I hope you found this interesting and/or useful! I certainly find this a useful way to learn and reflect on whats coming up, so that me and my team are prepared.

I’ve been following the preview releases (10.1 and 10.2 are here!). Below are my thoughts on what’s been announced and some of the points that are of more interest to me in my team working with Blazor hybrid WASM web apps.

If I have misunderstood something or you disagree with me I would love to chat 😃 #everydayaschoolday

(All views expressed are my own).

Overall thoughts on .NET 10 so far 🥅

A lack of clarity on the direction, mission and aims.

I’m not completely clear on what the vision is for .NET 10 to be honest. I’m only 6 months into my journey with .NET, so perhaps my expectations are not quite right. But I was expecting a clearer indication of what this release is aiming for - in the same way that new versions of the iPhone have a clear headline message (even if people feel that hardware innovation is becoming harder…). There are some general improvements across the .NET ecosystem and there are some new AI capabilities in the work if you are building your own AI agents, but I haven’t seen a clear headline that helps me see the direction where .NET is heading.

Anyway, let’s look at the relevant features in .NET 10.1 and 10.2 previews and my opinionated comments (in italics).

C# 14 🦭

1. Field backed properties - using the new field keyword means the compiler will automatically generate the backing field. A nice bit of syntactic sugar, but it’s a minor improvement. It also means newer classes could look a bit different to older style classes and reduce readability across the codebase.
2. Implicit ‘Span’ conversions - Spans are wrappers around buffers. Not relevant to what I the projects I am working on, as this is a bit too low level.
3. Unbound generic support for nameof - nameof(List<>) now evaluates to List, but before wouldn’t have worked. Not sure of the situation where you would need this offhand, but useful to know.
4. Types no longer required with parameter modifiers. When using e.g. the out param modifier in a lambda you previously had to specify the type of variable, but not any longer.

Before: TryParse<int> parse1 = (text, int out result) => Int32.TryParse(text, out result);

in C# 14 you won’t need to specify that result is an int: TryParse<int> parse1 = (text, out result) => Int32.TryParse(text, out result);

I think this is useful for readability when there is a verbose type that is returned, as long as the variable is suitably named so the reader can infer that the variable is probably a number/string/date etc when scanning the lambda.

1. Partial constructors - similar to how classes can already be defined over multiple files, constructors can now be as well. I’m not sure of the benefit of this; if you need to split your constructor over multiple files because the constructor is too large then this is a sign your constructor is too big, perhaps? It seems like a marginal improvement and I think this could lead to more confusion. Happy to be proved wrong.

Blazor🔥

1. New ReconnectModal available out of the box - useful for folks who are working with server-rendered Blazor projects.
2. NavigateTo method now doesnt scroll to top of page when same page nav - again, more relevant to server-rendered Blazor projects.
3. QuickGrid styling improvements - I don’t touch QuickGrid much so I would have to look in more whether this is relevant to our use cases in my team.
4. NavLink.Matchall tweaks - NavLink is a Blazor components that sets the ‘active’ CSS class when a link matches the URL. In .NET 10, links will retain the active class if the URL path matches but the query string or fragment change. This may not affect you, and I don’t believe it will affect us given the way we use NavLinks in our projects

Conclusion

Thanks for reading. I hope you found this interesting and/or useful! I certainly find this a useful way to learn and reflect on whats coming up, so that me and my team are prepared.

##Read more

• .NET 10 Preview 1 is now available! - .NET Blog What’s new in C# 14 | Microsoft Learn
• Subscribe to the .NET newsletter to get updates: Newsletter - .NET Blog

While I have remained close to the code and written some code in the past few years (mainly building prototypes etc.), I haven’t been coding full time for a while. Plus, I haven’t worked with C# or Blazor before, so I was going to have to sharpen up my programming skills and learn a new language/framework at the same time.

So, here are my first thoughts on C# and Blazor from an intensive 3 weeks of learning before starting my new role, and how these technologies compare to others I have worked with, in my opinion.

Please feel free to message me on LinkedIn with your thoughts, if I have misunderstood something, or if you have a different point of view 😀.

(All views expressed are my own).

My background

To set the scene: I’ve been in full-time software dev roles for over 6 years, starting in front-end web development roles (React, AngularJS and also on the backend with JavaScript/TypeScript). I have also worked with C++.

So I have experience learning new front-end frameworks and working with statically typed languages.

How I approached learning

In the last few weeks I went through this Blazor course on Udemy and this C# course on ZTM. I’ve taken notes using Notion and used Zorbi to automatically generate revision flashcard from Notion that I run through each morning. I have also been doing lots of the simpler katas on Codewars each morning to get my muscle memory used to the syntax and foundations of C# (where brackets need to go, filtering arrays, splitting strings etc.).

There is probably another blog post I could write reflecting on the difference between making time to learn new material and reinforcing existing knowledge in such a fast-moving industry like software engineering.

Structure

What immediately struck me was how structured C# is as a language, and .NET is as a framework/toolkit. This felt quite different to working with JavaScript which has some strange quirks and edges. For instance, JavaScript’s equality operators have lots of gotchas, working with null always feels weird and I’ve never quite found a library I’m happy with to work with dates.

The best analogy of how they feel to me is that JavaScript is a lifeform that has evolved in a petri dish thats been left out (like penicillin), whereas C# is a robot built in a factory in a systemtic and structured way. Neither is better or worse - just different. And I think it makes sense given JavaScript was famously initially created in 10 days to add interactivity to web pages and then grew into what is is today.

Also, I really like C#’s Linq as a centralised and consistent way of working with enumerable data structures and I have found that when doing my daily Codewars practices that I reach for these as my first port of call for filtering, appending etc.

Bouncing up against the walls

I always find it interesting to find the limitations of a front-end framework and how this is handled. I remember working with AngularJS as it was evolving in 2015/16 and components struggled to contain reusable logic gracefully, and so ‘component directives’ were introduced …but still had lots of workarounds (and I seem to remember what felt like hacks). React has Refs and introduced ‘Context’ to avoid props drilling and, of course, React introduced Hooks to overcome the challenges of sharing stateful logic between components.

With C#, so far, the main thing I have found is hooking into JavaScript to run alerts/confirmation pop-ups. I understand why this is necessary, but it does feel a bit ‘unclean’ having to rely on JavaScript to overcoming (what feels like) a C# shortcoming. The purist in me would want to only work in C# if possible. I haven’t yet made up my mind whether this feels like a code smell or not.

Scaffolding

I was pleasantly suprised by how easy it is to configure and manage Blazor apps. I remember the days of having to manually configure Webpack for front-end projects which was a complete nightmare. I know things like Vite and NextJS have moved things forwards but working with these JavaScript bundlers always feel a bit like hardwork. Perhaps it’s partly that C# and Blazor is all Microsoft instead of a created by the community/third parties. I think I prefer a clearer and more idiomatic way of doing things instead of a huge array of choice, at least at the moment.

What I am excited to explore next

I’ve enjoyed the journey so far - I quite like the humbling experience of feeling like a novice, despite feeling uncomfortable a lot of the time in doing so.

• I am looking forward to getting more into bUnit for testing Blazor UIs
• I’ve gotten really interested in property testing as a way of improving unit test coverage and want to play around with FsCheck a bit more
• I’m keen to start looking more into Reqnroll as a way of generating ‘executable specifications’ for Blazor apps

What are they

JavaScript has two categories of types: primitives and objects. Technically, null is both a primitive and an object, so the more accurate definition is of a primitive is: If it isn’t an object and has no methods then it’s a primitive (see here).

A few years ago the Symbol primitive was added to the language. I read about it at the time and remember getting the impression that it’s a bit of a niche corner of the language that most people won’t need to bother with most of the time. I think that’s still correct, but I happened to run into a situation recently where I needed to know what they were and how they worked in more detail.

Why use them?

They provide a way of generating unique identifiers.

Example of why they are useful

They seem to be used mainly for ‘hidden’ fields on objects. Although it is still possible to access them, the point is that their implementation makes it difficult to access. They aren’t found using for...in loops or by accessing Object.keys().

This is useful if you want to set flags that you don’t want developers to accidentally set. The example that comes up a lot online is to indicate whether a list is sorted or not. This is useful metadata that you don’t want someone to accidentally overrite.

Read down below to lern about how to access symbolic keys.

How to use them

What they feel like

As mentioned above, they are a primitive in the JavaScript language, but the way they are written and used makes them feel kind of like an object, but with some noticeable differences.

Creating new ones

For instance, you can’t need to use the new operator.

let sym1 = Symbol() // correct
let sym1 = new Symbol()  // TypeError

You can wrap them up in an object if you really want to, but it’s not straightforward:

let sym = Symbol('foo')
typeof sym      // "symbol"
let symObj = Object(sym)
typeof symObj   // "object

And I’m not sure yet why you would want to do this.

Uniqueness

Something else that is interesting that’s worth mentioning here is that each ‘symbol’ is unique:

// each of these is a different symbol
let sym1 = Symbol()
let sym2 = Symbol('foo')
let sym3 = Symbol('foo')

Symbol('foo') === Symbol('foo')  // false

Global keys

You can create symbols in such a way that they are globally available throughout your code base using Symbol.for(), which could be used really well or abused really well!

Accessing symbolic keys - indexing

This was where my original problem was. I was trying to access the value of the nested ‘path’ field in this object:

Request {
    size: 0,
    timeout: 0,
    follow: 20,
    compress: true,
    counter: 0,
    agent: undefined,
    [Symbol(Body internals)]: { body: null, disturbed: false, error: null },
    [Symbol(Request internals)]: {
        method: 'GET',
        redirect: 'follow',
        path: 'mypath'
        ...
    }
}

It turns out that doing request['Symbol(Request internals)'] doesn’t work.

I mentioned above that when symbols are used as keys in objects they can’t be accessed through ‘the standard’ methods.

To access them I had to use Object.getOwnPropertySymbols(request) which returns an array of symbols. To find the particular symbol I had to use a little helper which searches through the array and finds a particular element.

const sym = Object.getOwnPropertySymbols(data).find(s => String(s) === 'Symbol(Request internals)')
const path = request[sym].path

However, that approach doesn’t agree with TypeScript just quite yet (as at December 2020), so you will have to add @ts-ignore above where sym is used!

Accessing symbolic keys - methods

Sometimes you will get lucky and the object you are working with has some methods to access symbolic keys easily. I also had to access the ‘headers’ field in a request as part of this test and fortunately there is a method that just takes care of this nicely in this object. You can see more here.

More reading

• https://stackoverflow.com/questions/50060008/nodejs-parse-fetch-response-containing-object-symbolmap/50856907
• https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Symbol