Getting Through a Technical Book You Actually Finish

A technical book becomes easier to finish when it helps answer a question you care about. Read with a small experiment beside you, rather than treating every page as something to memorize.

Choose a Question Before a Chapter

Start with a problem that has appeared in your work. You might want to understand duplicate rows, transaction boundaries, or a surprising execution plan. Write the question in one sentence before opening the book.

Use the contents and index to locate the relevant explanation. Read prerequisite sections when the topic depends on them. Reading out of order is useful when it remains a deliberate path rather than random browsing.

Decide what understanding would let you do differently. A concrete outcome gives the session a stopping point. It also prevents an interesting chapter from becoming an endless collection of unrelated bookmarks.

Record the Environment Behind the Example

A SQL Server example belongs to a version, compatibility level, and set of assumptions. Older books can explain durable concepts while showing behavior that has changed. Keep both possibilities open.

SELECT SERVERPROPERTY('ProductVersion') AS product_version,
       SERVERPROPERTY('Edition') AS edition;
SELECT name, compatibility_level, collation_name
FROM sys.databases
WHERE database_id = DB_ID();

Save this context with your experiment. Check the official reference when the book's syntax or behavior differs from your environment. A mismatch can reveal a changed feature rather than a mistake in your typing.

Use a disposable database or temporary objects for exercises. Read the complete script before running it. An educational example can still create persistent objects or change settings.

Type a Small Example and Predict the Result

Typing forces you to notice details that disappear while reading. Before execution, write a prediction about rows, NULL values, or ordering. Then compare the actual result with that prediction.

CREATE TABLE #ReadingExample
(
    ItemId int PRIMARY KEY,
    Category varchar(10) NULL,
    Amount decimal(10,2) NULL
);
INSERT #ReadingExample VALUES
(1,'A',10.00),(2,'A',NULL),(3,NULL,20.00);
SELECT COUNT(*) AS all_rows,
       COUNT(Amount) AS rows_with_amount,
       SUM(Amount) AS total_amount
FROM #ReadingExample;

This example provides a compact question about aggregate behavior and missing values. Explain each result in your own words after running it. Copying the output without an explanation does not establish understanding.

Keep the dataset small enough to inspect every row. Large sample databases can be useful later, but they can hide the first principle. Begin with the smallest case that exposes the concept.

Change One Thing

After reproducing the example, change one input or condition. Add a duplicate, introduce NULL, remove a matching row, or change the ordering. Predict the effect before running the altered statement.

SELECT ItemId, Category, Amount
FROM #ReadingExample
WHERE Amount <> 10.00
ORDER BY ItemId;
SELECT ItemId, Category, Amount
FROM #ReadingExample
WHERE Amount <> 10.00 OR Amount IS NULL
ORDER BY ItemId;

The difference invites an explanation of SQL's treatment of unknown comparisons. It also shows why a familiar-looking predicate can omit a row. One small variation can teach more than another page of highlighting.

When performance is the topic, separate conceptual examples from representative measurements. A tiny table can explain an operator without predicting production cost. Record that boundary in the note.

Write a Note That Survives the Week

Use a short format: question, explanation, runnable example, and limitations. Include the book edition and chapter or page reference. Add the environment details needed to repeat the experiment.

SELECT N'How do NULL values affect filtering?' AS question,
       N'Use IS NULL when missing values belong in the result.' AS lesson,
       N'Temporary table example in the same session.' AS setup,
       N'Check the business meaning of missing values.' AS limitation;

This query illustrates the note's fields without creating a permanent note system. Store the actual note in your normal local reference folder. Use a filename that describes the problem rather than only the chapter number.

Do not rewrite the entire chapter. Preserve the part you can explain and reuse, along with the source reference. A concise original explanation is easier to review than a copied passage.

Finish With a Defined Learning Result

Set a modest reading session with one question and one experiment. Stop when you can explain the result and identify its limits. Leave a clear next question for the following session.

Some books deserve a complete sequential read, especially when later chapters build a connected design. Others serve better as references. Finishing should mean completing the learning purpose you chose, not merely moving the bookmark.

Revisit one earlier note before starting a new topic. Recreate the example without looking at the explanation first. The useful knowledge is what remains available when the book is closed.

Reading is not the collection of highlighted pages, it is the practice of turning an explanation into understanding.

This post was rewritten from scratch in September 2026. The original, published on 2012-03-25, was a short announcement about something that no longer exists. The address is the same, the subject is now something worth keeping.

Published by Pinal Dave on SQLAuthority. More of my work at pinaldave.com.