Thinking Like a Programmer: Turning a Vague Request Into Working Code

TL;DR

• Turn vague product requests into precise clarifying questions and plain-language steps before touching code.
• Break logic into small, single-purpose functions, test edge cases (nulls, time zones, paid boundaries), and avoid embedding clock calls inside business logic.
• Master practical day-one debugging skills: isolating stack traces, setting breakpoints, using watch expressions, and effective error searching.

Level: Beginner · Prerequisites: A basic .NET developer environment installed and a willingness to ask questions before coding · Reading time: 10 min

The product owner stops by your desk: “Can you send a reminder to customers whose invoices are overdue?” She leaves. You open the editor and stare at an empty file. Where does the code even start? What is an invoice in this system? What does overdue mean? Email or SMS?

Many beginners start typing anyway. Two hours later there is a loop, a half-written email template, and a growing feeling that the thing being built is not the thing that was asked for. The problem is not your C#. The problem is that the request was never turned into something precise enough to code.

This article walks through that translation with a real example, ends with a console app you can run, and then covers the three skills that make the difference on day one: reading an error, using the debugger, and searching for the right thing.

What you will be able to do after this

• Turn a vague sentence into a list of clarifying questions and a plain-language plan
• Break the plan into small C# functions that each do one thing
• Handle the edge cases the request did not mention (missing dates, paid invoices, time zones)
• Read a stack trace and find the line that matters
• Use breakpoints, step over, and the watch window to see what your code actually does

Ask before you type

A request like “remind customers with overdue invoices” hides at least five decisions. Write them down and ask. Here are the questions and the answers the product owner gave:

Ten minutes of questions saved a day of rework. Notice that “one email per customer” changes the shape of the code: you need to group invoices by customer, not send one message per invoice.

Write the steps in plain language

Before any C#, write the algorithm as sentences a non-programmer could check:

1. Take today’s date (in the company’s time zone).
2. Take all invoices.
3. Keep the ones that are not paid, have a due date, and whose due date is more than three days ago.
4. Group them by customer.
5. For each customer, build one message listing the invoices and the total.
6. Send the messages.

Each line becomes one function or one LINQ call. If a line is hard to write as a sentence, it will be hard to write as code; ask more questions.

Turn each step into a small function

Create a console app and paste the code below into Program.cs. It is complete: it uses an in-memory list instead of a database so you can run it right now. DateOnly is used because an invoice is due on a day, not at a time.

1
2

dotnet new console -n Store.Reminders
cd Store.Reminders

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62

using System.Globalization;

var today = new DateOnly(2026, 10, 12);

var invoices = new List<Invoice>
{
    new(1001, "Ayşe Yılmaz", "ayse@example.com", 1250.00m, new DateOnly(2026, 9, 20), PaidOn: null),
    new(1002, "Mehmet Kaya", "mehmet@example.com", 480.50m, new DateOnly(2026, 10, 1), PaidOn: new DateOnly(2026, 10, 3)),
    new(1003, "Zeynep Demir", "zeynep@example.com", 3200.00m, new DateOnly(2026, 10, 20), PaidOn: null),
    new(1004, "Can Öztürk", "can@example.com", 99.90m, DueDate: null, PaidOn: null),
    new(1005, "Ayşe Yılmaz", "ayse@example.com", 700.00m, new DateOnly(2026, 10, 8), PaidOn: null),
};

var overdue = FindOverdue(invoices, today, graceDays: 3);

foreach (var customerInvoices in overdue.GroupBy(i => i.CustomerEmail))
{
    var message = BuildReminder(customerInvoices.Key, customerInvoices.ToList(), today);
    Console.WriteLine(message);
    Console.WriteLine(new string('-', 40));
}

// Step 3 of the plan: unpaid, has a due date, due date older than the grace period
static List<Invoice> FindOverdue(IEnumerable<Invoice> invoices, DateOnly today, int graceDays)
{
    var cutoff = today.AddDays(-graceDays);

    return invoices
        .Where(i => i.PaidOn is null)
        .Where(i => i.DueDate is not null && i.DueDate.Value < cutoff)
        .OrderBy(i => i.DueDate)
        .ToList();
}

// Step 5 of the plan: one message per customer
static string BuildReminder(string email, List<Invoice> invoices, DateOnly today)
{
    var tr = CultureInfo.GetCultureInfo("tr-TR");
    var total = invoices.Sum(i => i.Amount);

    var lines = invoices.Select(i =>
    {
        var due = i.DueDate!.Value; // FindOverdue guarantees a due date
        var daysLate = today.DayNumber - due.DayNumber;
        return $"  #{i.Number}: {i.Amount.ToString("N2", tr)} TL due {due:yyyy-MM-dd} ({daysLate} days late)";
    });

    return $"""
        To: {email}
        Subject: {invoices.Count} overdue invoice(s), total {total.ToString("N2", tr)} TL

        {string.Join(Environment.NewLine, lines)}
        """;
}

record Invoice(
    int Number,
    string CustomerName,
    string CustomerEmail,
    decimal Amount,
    DateOnly? DueDate,
    DateOnly? PaidOn);

Run it with dotnet run:

1
2
3
4
5
6

To: ayse@example.com
Subject: 2 overdue invoice(s), total 1.950,00 TL

  #1001: 1.250,00 TL due 2026-09-20 (22 days late)
  #1005: 700,00 TL due 2026-10-08 (4 days late)
----------------------------------------

Map the code back to the plan. FindOverdue is step 3. It receives the list, today’s date, and the grace period as parameters; it never reads the clock itself, which is what makes it testable: you can pass any “today”. GroupBy is step 4. BuildReminder is step 5. Step 6, sending, is deliberately missing; it will be an email service later, and the first version proves the logic without touching a mail server.

Each function is small enough to explain in one sentence. That is the test for whether you have split the problem enough.

Handle the edge cases the request did not mention

The sample data already contains the traps:

• Invoice 1002 was paid late. PaidOn is null filters it out. Without that line, a customer who already paid gets a reminder, and you get an angry phone call.
• Invoice 1004 has no due date. DueDate is not null skips it. Without it, DueDate.Value throws InvalidOperationException at runtime, usually on the one record you did not test with.
• Invoice 1005 is four days late, just past the three-day grace period. Boundary values are where off-by-one bugs live. Change today to 2026-10-11 and confirm 1005 disappears from the output.

“Today” is the subtle one. DateTime.Now on a server in a Frankfurt data centre is not today in Istanbul at 01:00. For now, compute today in the company’s time zone and pass it in:

1
2

var istanbul = TimeZoneInfo.FindSystemTimeZoneById("Europe/Istanbul");
var today = DateOnly.FromDateTime(TimeZoneInfo.ConvertTimeFromUtc(DateTime.UtcNow, istanbul));

Time zones get their own article later in the series. The habit to keep is that business functions receive today as a parameter and never call the clock themselves.

Test with tiny data, then iterate

The five-invoice list is the test. Each invoice exists to prove one rule: one is plainly overdue, one is paid, one is in the future, one has no due date, one sits on the boundary. When you later move the data to SQL Server and the sending to an email service, FindOverdue and BuildReminder do not change, and the same five records become your first unit tests.

Then iterate. The product owner reads the message, asks for the customer’s name in a greeting line, and you add one parameter to BuildReminder. Small functions make small changes.

Reading an error without panicking

Suppose a colleague removes the i.DueDate is not null && part of the filter. The next run prints something like this (your line numbers and the compiler-generated names will differ):

1
2
3
4
5
6
7

Unhandled exception. System.InvalidOperationException: Nullable object must have a value.
   at System.Nullable`1.get_Value()
   at Program.<>c__DisplayClass0_0.<<Main>$>b__1(Invoice i) in C:\src\Store.Reminders\Program.cs:line 30
   at System.Linq.Enumerable.WhereEnumerableIterator`1.MoveNext()
   at System.Linq.Enumerable.ToList[TSource](IEnumerable`1 source)
   at Program.<<Main>$>g__FindOverdue|0_0(IEnumerable`1 invoices, DateOnly today, Int32 graceDays) in C:\src\Store.Reminders\Program.cs:line 28
   at Program.<Main>$(String[] args) in C:\src\Store.Reminders\Program.cs:line 14

Read it in this order:

1. The first line is the exception type and message. “Nullable object must have a value” means something called .Value on a null.
2. The lines starting with at are the stack trace, newest call first. The top frame is inside .NET itself. Skip every frame that is not in your code.
3. The first frame with a path to your file is the one to open: Program.cs:line 30. That is the lambda inside Where, and that is where the fix goes.
4. Lines that mention System.Linq or System.Collections are plumbing between your frames. They tell you the path the call took, not where the bug is.

Using the debugger instead of Console.WriteLine

• Set a breakpoint by clicking the margin next to var cutoff = ... (or press F9 on that line). Press F5. Execution stops there, and hovering over any variable shows its value.
• Step over (F10) runs the current line and stops at the next one. Step into (F11) goes inside a method call. Step out (Shift+F11) finishes the current method and stops in the caller.
• The Watch window lets you type cutoff or invoices.Count and keeps the value updated after every step. The Locals window shows everything in scope without typing.
• A conditional breakpoint stops only when something is true. Right-click the breakpoint inside the Where lambda, choose Conditions, and enter i.Number == 1004. Now the debugger stops on the invoice you care about instead of 4,000 times.

VS Code with the C# Dev Kit uses the same keys and the same windows under slightly different names.

Searching for an error the right way

• Copy the exception type and the message, not your variable names: InvalidOperationException "Nullable object must have a value".
• Add the technology: C#, EF Core, or ASP.NET Core, plus the version if you suspect behaviour changed between versions.
• Prefer learn.microsoft.com, the library’s GitHub issues, and Stack Overflow answers with recent dates.
• Read the question before the answer. Half the time the asker’s situation differs from yours in the one detail that matters.
• When an AI assistant suggests code, run it against the five-invoice data set before trusting it.

Who you work with

• The business analyst (or product owner) writes the request and the acceptance criteria. They expect you to ask questions early, in writing, and to say when something is ambiguous rather than guess and deliver the wrong thing confidently.
• The tester (QA, quality assurance) checks the result against the acceptance criteria and hunts for edge cases. They expect a note on what changed, how to reproduce it, and which cases you already covered. Give them the five-invoice list; they will add five more.
• Other developers review your code and maintain it later. They expect small functions, names that say what things are, and a pull request they can read in ten minutes.

Common mistakes

• Starting to code before the request is precise. You build the wrong thing well. Write the questions table first and get answers in writing.
• Reading the clock inside business logic. DateTime.Now inside FindOverdue makes it untestable and time zone dependent. Pass today in as a parameter.
• Using the null-forgiving operator to silence a nullable warning instead of filtering. The runtime exception arrives on production data. Filter with is not null and let the compiler stop warning on its own.
• One giant method that selects, formats, and sends. You cannot test the selection without sending emails. Split by plan step.
• Testing only the happy path. Include a paid invoice, a missing date, a future date, and a boundary record in the first data set.
• Searching with your own variable names or file paths in the query. Nobody else has Store.Reminders. Search the message.
• Reading only the first line of a stack trace. The line number of your bug is a few lines down.

Checklist

• Clarifying questions and their answers written down before coding
• Plan written as numbered plain-language steps
• One function per step, each explainable in a sentence
• today and other external inputs passed as parameters
• Test data includes null, paid, future, and boundary cases
• Expected output written down before running
• Stack trace read down to the first frame in your own file
• Breakpoint and Watch window, not Console.WriteLine, used to inspect state

What’s next

The next article, “Git for Daily Work: Branches, Pull Requests, and Fixing Mistakes”, puts this program under version control and shows how to share it without overwriting anyone’s work. After that, Part 2 starts with “C# Types in Practice: Value vs Reference, decimal vs double, and Nullable”, which explains why the amounts above are decimal and the dates are DateOnly?.

Tags: csharp, dotnet, programming, debugging, beginners