Starting from .NET 8.0, we have new abstractions for time. We don’t need a custom ISystemClock interface. There’s one built-in. Let’s learn how to use the new TimeProvider class to write tests that use DateTime.Now.
.NET 8.0 added the TimeProvider class to abstract date and time. It has a virtual method GetUtcNow() that sets the current time inside tests. It also has a non-testable implementation for production code.
Back in the day, we wrote two tests to validate expired credit cards. And we wrote an ISystemClock interface to control time inside our tests. These are the tests we wrote:
usingFluentValidation;usingFluentValidation.TestHelper;namespaceTimeProviderTests;[TestClass]publicclassCreditCardValidationTests{[TestMethod]publicvoidCreditCard_ExpiredYear_ReturnsInvalid(){varwhen=newDateTime(2021,01,01);varclock=newFixedDateClock(when);varvalidator=newCreditCardValidator(clock);// ^^^^^// Look, ma! I'm going back in timevarcreditCard=newCreditCardBuilder().WithExpirationYear(DateTime.UtcNow.AddYears(-1).Year).Build();varresult=validator.TestValidate(creditCard);result.ShouldHaveAnyValidationError();}[TestMethod]publicvoidCreditCard_ExpiredMonth_ReturnsInvalid(){varwhen=newDateTime(2021,01,01);varclock=newFixedDateClock(when);varvalidator=newCreditCardValidator(clock);// ^^^^^// Look, ma! I'm going back in time againvarcreditCard=newCreditCardBuilder().WithExpirationMonth(DateTime.UtcNow.AddMonths(-1).Month).Build();varresult=validator.TestValidate(creditCard);result.ShouldHaveAnyValidationError();}}publicinterfaceISystemClock{DateTimeNow{get;}}publicclassFixedDateClock:ISystemClock{privatereadonlyDateTime_when;publicFixedDateClock(DateTimewhen){_when=when;}publicDateTimeNow=>_when;}publicclassCreditCardValidator:AbstractValidator<CreditCard>{publicCreditCardValidator(ISystemClocksystemClock){varnow=systemClock.Now;// Beep, beep, boop// Using now to validate credit card expiration year and month...}}
We wrote a FixedDateClock that extended ISystemClock to freeze time inside our tests. The thing is, we don’t need them with .NET 8.0.
1. Use TimeProvider instead of ISystemClock
Let’s get rid of our old ISystemClock by making our CreditCardValidator receive TimeProvider instead, like this:
publicclassCreditCardValidator:AbstractValidator<CreditCard>{// Before:// public CreditCardValidator(ISystemClock systemClock)// After:publicCreditCardValidator(TimeProvidersystemClock)// ^^^^^{varnow=systemClock.GetUtcNow();// or//var now = systemClock.GetLocalNow();// Beep, beep, boop// Rest of the code here...}}
The TimeProvider abstract class has the GetUtcNow() method to override the current UTC date and time. Also, it has the LocalTimeZone property to override the local timezone. With this timezone, GetLocalNow() returns the “frozen” UTC time as a local time.
If we’re working with Task, we can use the Delay() method to create a task that completes after, well, a delay. Let’s use the short delays in our tests to avoid making our tests slow. Nobody wants a slow test suite.
With the TimeProvider, we can control time inside our tests by injecting a fake. But for production code, let’s use TimeProvider.System. It uses DateTimeOffset.UtcNow under the hood.
We might be tempted to wrie a child class that extends TimeProvider. But, let’s hold our horses. There’s an option for that too.
Let’s rewrite our tests after that change in the signature of the CreditCardValidator.
First, let’s install the Microsoft.Extensions.TimeProvider.Testing NuGet package. It has a fake implementation of the time provider: FakeTimeProvider.
Here are our two tests using the FakeTimeProvider:
usingFluentValidation;usingFluentValidation.TestHelper;usingMicrosoft.Extensions.Time.Testing;namespaceTestingTimeProvider;[TestClass]publicclassCreditCardValidationTests{[TestMethod]publicvoidCreditCard_ExpiredYear_ReturnsInvalid(){// Before://var when = new DateTime(2021, 01, 01);//var clock = new FixedDateClock(when);varwhen=newDateTimeOffset(2021,01,01,0,0,0,TimeSpan.Zero);varclock=newFakeTimeProvider(when);// ^^^^^// Look, ma! No more ISystemClockvarvalidator=newCreditCardValidator(clock);// ^^^^^varcreditCard=newCreditCardBuilder().WithExpirationYear(DateTime.UtcNow.AddYears(-1).Year).Build();varresult=validator.TestValidate(creditCard);result.ShouldHaveAnyValidationError();}[TestMethod]publicvoidCreditCard_ExpiredMonth_ReturnsInvalid(){// Before://var when = new DateTime(2021, 01, 01);//var clock = new FixedDateClock(when);varwhen=newDateTimeOffset(2021,01,01,0,0,0,TimeSpan.Zero);varclock=newFakeTimeProvider(when);// ^^^^^varvalidator=newCreditCardValidator(clock);// ^^^^^// Look, ma! I'm going back in timevarcreditCard=newCreditCardBuilder().WithExpirationMonth(DateTime.UtcNow.AddMonths(-1).Month).Build();varresult=validator.TestValidate(creditCard);result.ShouldHaveAnyValidationError();}}
The FakeTimeProvider has two constructors. One without parameters sets the internal date and time to January 1st, 2000, at midnight. And another one that receives a DateTimeOffset. That was the one we used in our two tests.
The FakeTimeProvider has two helpful methods to change the internal date and time: SetUtcNow() and Advance(). SetUtcNow() receives a new DateTimeOffset and Advance(), a TimeSpan to add it to the internal date and time.
If we’re curious, this is the source code of TimeProvider and FakeTimeProvider from the official dotnet repository on GitHub.
If we take a closer look at our tests, we’re “controlling” the time inside the CreditCardValidator. But, we still have DateTime.UtcNow when creating a credit card. For that, we can introduce a class-level constant Now. But that’s an “exercise left to the reader.”
Voilà! That’s how to use the new .NET 8.0 abstraction to test time. We have the new TimeProvider and FakeTimeProvider. We don’t need our ISystemClock and FixedDateClock anymore.
Want to write readable and maintainable unit tests in C#? Join my course Mastering C# Unit Testing with Real-world Examples on Udemy and learn unit testing best practices while refactoring real unit tests from my past projects. No more tests for a Calculator class.
I applied for a role as a software engineer at a FAANG or MAGMA or insert-newest-acronym here.
And I failed.
I thought: “I have more than 10 years of experience. I’ve seen quite a lot.”
A “short coding assessment” got me off guard. 80 minutes and 3 exercises made me feel like an impostor. An uppercut and 10-second countdown.
I don’t want this post to be another “hiring is broken” and “life is unfair” post. So…
If I could go back in time, this is what I’d tell myself before that coding assesment:
1. Review data structures, especially those you don’t use often.
Take the time to review data structures. Lists, hash maps, queues, trees.
Trees, is this you?
I haven’t used trees since my data structure class back in university. And probably, I wouldn’t use them if I had passed the interview and joined.
But, surprise, surprise. That was one of the questions.
2. Practice using a timer and a coding editor without auto-completion
I know it’s unrealistic. These days, we have IDEs with autocompletion and even AI at our fingertips.
But MAGMAs insist on hiring using coding platforms without autocompletion. The old way.
Since practicing a skill should be as “real” as possible, close your IDE and practice using a bare-bones text editor. And with a timer on.
3. Read all questions first. I know!
Yeah, I wanted to be an A-student playing with the rules. I jumped right to the first question.
50 minutes in and I had barely an answer for the first question. I had to decide between solving only one question or moving on and trying to solve another one. One and a half questions are better than only one, I guess.
I could have nailed the second one first. It was way easier. And definitively, I could have solved the last two questions and skipped the first one. If only I had read all the questions first.
Read all the questions and start with the easy ones. Old advice that I forgot.
Voila! That’s what I’d tell myself before that coding assessment. Yeah, hiring is broken, but we have to go through gatekeepers. Or ditch our CVs and interviewing skills and build a place for ourselves.
Starting out or already on the coding journey? Join my free 7-day email course to refactor your software engineering career now – I distill 10+ years of career lessons into 7 short emails.
In the last two or three years, I read dozens of non-fiction books. The truth is I don’t remember reading some of them, even when I took notes. I don’t even remember their front cover or why I decided to read them.
I was reading to increase a book count. Pure FOMO. Without realizing it, I was trying to copy those YouTube videos: “I read <insert large number here> books, here’s what I learned.”
After that realization, I adapted the slip-box or Zettelkasten method, described in How to Take Smart Notes by Sönke Ahrens, and other reading techniques into my own reading system.
This is the six-step process I follow to read and retain more from non-fiction books:
Step 1: Intention
Start by asking why you want to read a book.
We don’t jump into a book with the same attitude if we’re just curious about a subject or want to answer a particular question.
That intention will set the tone for our reading. And based on that, we could decide if we want to read the book from cover to cover or jump into a particular section.
Step 2: Overview
Ask if the book you’re about to read can answer your questions or satisfy your curiosity.
For that, understand the purpose of the book and its content. Use reviews, summaries, or anything else to understand the overall book content.
Often book authors go on podcast tours to promote their books, and listening to those podcast episodes helps us understand what their books are about.
A good experiment to try is to use ChatGPT or Copilot for this step. We could use any of the two to generate an executive summary of a book, for example.
Step 3: Note
Create a new place for your notes, either a text file or a piece of paper.
For the new note, use the date and the book title as the note title. Then divide the note into two halves. The first half is for questions and connections, and the second half is for the actual notes.
Also, link to the new book note from a book index and a subject index. The book index is a note that links to all books you’ve read. And the subject index is a note that references all other notes related to a specific subject. These notes work like “index” notes.
My note structure and links between notes
Step 4: Question
Read the table of contents, introduction, and conclusion to look for the book’s structure and interesting topics.
Also, skim through the book to find anything that grabs your attention: boxes, graphs, and tables.
In the first half of your note, write questions you have about the subject and questions that arise after skimming the book.
If you decide not to read the book from cover to cover, in the first half of your note, create an index of the chapters and sections to read or the ones to skip. Keep this index for future reference.
I learned this idea of asking “pre-reading” questions from Jim Kwik’s Speed Reading program and the idea of a custom index from the post Surgical Reading: How to Read 12 Books at Once.
Step 5: Read
Then, read the book while taking note of interesting parts and quotes.
Use the second half of your notes to write down those interesting bits. Avoid copying and pasting passages from the book, except for quotes. Use your own words instead.
After every chapter, stop to recall the main ideas from that chapter.
If you find the answer to any of your questions from the “Question” step, go back to the first half of your note and write those answers there.
Step 6: Connections
While reading or after finishing a chapter, notice connections with other subjects. Ask yourself how that expands or contradicts anything else you’ve learned.
Use the first half of the note to write these connections.
If you’re familiar with the Zettelkasten method, to write your connections, we should use a separate set of notes: the permanent notes. For simplicity, I keep these connections in the same file but in the first half.
This way, the next time you open your note, you will find your connections and critique first.
Parting Thought
The key to retaining more is reading actively. Don’t just pass from page to page. Read with intention, not to grow a book count. Read for answers and connections.
The next time you’re about to jump into a new book, remember to set an intention and then capture and connect.
Reading more books isn’t the answer. Reading for retention and action is.
That announcement made the coding world run in circles, screaming in desperation. It also triggered an interesting conversation with a group of colleagues and ex-coworkers.
Here’s a summary of how a group of senior engineers viewed Devin and AI in general, and my own predictions for coding in the next 10 years.
If You Think You’re Out, You’re Out!
We all agreed that Devin and AI in general won’t take out jobs yet, but it will change the landscape for sure.
This is when the meme “AI needs well-written and unambiguous requirements, so we’re safe” is true.
One part of the group believed that software engineering, as we know it, would disappear in less than 10 years. They expected to see more layoffs and unemployment. They were also planning escape routes away from this industry.
If you’re reading this from the future, a bit of context about layoffs:
Around the 2020 pandemic, we enjoyed a boom in employment. We only needed “software engineer” as the title in our LinkedIn profiles to have dozens of recruiters offering “life-changing opportunities” every week.
But, in 2023 and 2024, we experienced massive layoffs. Either we were laid off or knew someone in our inner circle who was. It was a crazy time: one job listing, hundreds of applicants, and radio silence after sending a CV.
Most people claimed that AI took those jobs. Others claimed tech companies were so used to free money that went crazy hiring and then, when money wasn’t free anymore, they went crazy firing too. In any case, it was hard to get a new job in that season of layoffs.
Ok, end of that detour and back to the AI story.
While one part of the group was thinking of escaping routes, the other part believed the world would still need software engineers, at least, to oversee what AI does.
We wondered if AI needs human oversight, what about the working conditions for future software engineers? Maybe will they come from developing countries, with an extremely low wage and poor working conditions to fix the “oops” of AI software engineers? And if unfortunate software engineers were already under those conditions, wouldn’t all future software developers (at least the ones still standing) face the same fate?
Our conversation was divided into despair and change.
The World Will Need a Different Type of Coders
In 2034, knowing programming and coding by itself won’t be enough.
We will need to master a business domain or area of expertise and use programming in that context, mainly with AI as a tool.
Rather than being mundane code monkeys, our role will look like Product Managers. The coding part will be automated with AI. We will work more as requirement gatherers and writers and prompt engineers. Soft skills will be even more important than ever. Essentially, we all will be engineering managers overseeing a group of Devin’s.
We will see more Renaissance men and women, well-versed in different areas of knowledge, managing different AIs to achieve the goal of entire software teams.
In the meantime, if somebody else writes requirements and we, software engineers, merely translate those requirements into code, we’ll be out of business sooner rather than later.
Voilà! That’s how Software Engineering will look like in 2034: more human interaction and business understanding to identify requirements for AI software engineers. No more zero-value tasks like manual testing, code generation, and pointless meetings. Yeah, I’m looking at you, SCRUM daily meetings. AI will handle it all. Hopefully.
LINQ doesn’t get new features with each release of the .NET framework. It just simply works. This time, .NET 9 introduced two new LINQ methods: CountBy() and Index(). Let’s take a look at them.
1. CountBy
CountBy groups the elements of a collection by a key and counts the occurrences of each key. With CountBy, there’s no need to first group the elements of a collection to count its occurrences.
For example, let’s count all movies in our catalog by release year, of course, using CountBy(),
CountBy() returns a collection of KeyValuePair with the key in the first position and the count in the second one.
By the way, if that Console application doesn’t look like one, it’s because we’re using three recent C# features: the Top-level statements, records, and global using statements.
CountBy() has the same spirit of DistinctBy, MinBy, MaxBy, and other LINQ methods from .NET 6.0. With these methods, we apply an action direcly on a collection using a key selector. We don’t need to filter or group a collection first to apply that action.
If we take a look at the Index source code on GitHub, it’s a foreach loop with a counter in its body. Nothing fancy!
Voilà! Those are two new LINQ methods in .NET 9.0: CountBy() and Index(). It seems the .NET team is bringing to the standard library the methods we needed to roll ourselves before.
Want to write more expressive code for collections? Join my course, Getting Started with LINQ on Udemy and learn everything you need to know to start working productively with LINQ—in less than 2 hours.