A friend of mine sells phone cases through a small online shop. One evening, a post of hers picked up a few hundred comments in a couple of hours — questions, jokes, complaints, praise, all mixed together. She rang me and asked the only question she cared about: "Are people happy, or are they angry?" Reading three hundred comments one by one, at midnight, is nobody's idea of fun. That tired midnight question is exactly the moment this technology exists for.

The map of the idea: one verdict per text, two ways of reaching it, and the traps that still catch both.

The job is one verdict on a piece of text

Give the program a review, a comment, a support ticket, a tweet. It gives you back a label. The basic version has three labels: positive, negative, neutral. Finer versions hand back a score instead — 0.87 positive, say — or a row of stars from one to five.

Businesses buy this because of scale. Nobody can read a million reviews, but a dashboard can show the mood of those reviews rising or falling week by week. A hotel chain can spot that guests at one branch have turned sour about breakfast. A phone company can watch complaints spike the morning after an update. The verdict is rough, but it arrives fast and it covers everything.

It helps to think of it as a thermometer. A thermometer gives you one number for the whole room: warm, cold, fine. It cannot tell you who opened a window or why anyone is shivering. Sentiment analysis does the same thing for feeling. One number, quickly, roughly — and no explanation of why.

The first systems just counted weighted words

The earliest approach is the one you would probably invent yourself. Make two lists. Happy words: good, great, love, excellent. Sad words: bad, terrible, hate, awful. Then read the text, count which list wins, and declare the winner the mood.

Researchers built bigger versions of those lists, called lexicons, with thousands of words scored by strength — "excellent" might be worth three points and "awful" minus three. Then they added rules on top. A "not" standing before a word flips it. Capital letters and exclamation marks turn the volume up a little.

Here is the whole method, small enough to run in your head, in plain Python with nothing to install:

# A tiny sentiment scorer: count happy words, count unhappy words
positive = {"good", "great", "love", "happy", "best", "brilliant"}
negative = {"bad", "terrible", "hate", "awful", "worst", "boring"}

def sentiment(text):
    words = text.lower().replace(".", "").replace(",", "").split()
    score = 0
    for word in words:
        if word in positive:
            score += 1
        if word in negative:
            score -= 1
    if score > 0:
        return "positive"
    if score < 0:
        return "negative"
    return "neutral"

print(sentiment("The food was great and I love this place"))
print(sentiment("Great, another brilliant update that broke my phone"))

The first line behaves: two happy words, no sad ones, verdict positive. The second line falls flat on its face. It also comes back positive — and the sentence is a complaint. The counter found "great" and "brilliant" and stopped thinking. It never noticed "broke my phone", which is the actual news in that sentence, because "broke" is not on either list. And even if you added it, the score would still come out positive. A list cannot hear the tone that makes "great" mean its exact opposite.

Negation breaks it just as easily. Feed it "the battery is not bad at all" and it sees one sad word, "bad", and reports negative — about a sentence that is praising the battery. There is no rule in my little counter for the small word "not" standing guard in front. Real lexicon systems add that rule. Then sarcasm walks in and breaks the new rule. Patch, break, patch, break — that is the honest history of the word-list years.

Neural models learned the patterns instead of the lists

The newer approach stops handing the machine rules and starts handing it examples. Humans sit down and label a large pile of real text — this review is positive, that one is negative, this one is mixed — tens of thousands of pieces, sometimes far more. The model reads them all and adjusts itself until its verdicts mostly match the human ones.

Two ideas make this work. The first is embeddings: every word is turned into a list of numbers, placed in a kind of map where words used in similar ways sit near each other. "Good" and "great" end up as neighbours. "Good" and "awful" end up far apart. The second idea is that the model reads the whole sentence at once and lets the words affect each other. The word "bad" in "not bad" gets pulled by the "not" standing next to it, because in the training data, that pairing was praise again and again. Nobody wrote that rule down. The pattern was in the examples, and the model picked it up.

Here is that journey in a picture:

From raw text to a verdict: words become numbers, the whole sentence is weighed together, and the answer comes out as a score.

One more honest detail about those labels: they are human judgement calls, and humans disagree. Give the same sarcastic review to five people and you may get three verdicts. The people labelling the training data argue, settle it by vote, and move on — which means the model is trained to match the majority opinion of tired strangers, not some perfect truth about feelings. When a review sits right on the fence, the model has learned the fence exists. Its unsure scores on borderline text are not a bug. They are the most honest thing it produces.

The output deserves an honest mention too. A neural model does not really say "positive". It says something like "82 percent positive, 15 percent negative, 3 percent neutral" — how strongly the text resembles each kind it was trained on. The tidy label you see is just the biggest of those numbers with the rest thrown away. Good tools show you the score. The score is where the doubt lives, and the doubt is information.

The honest limits are not small

I like this technology, and I do not fully trust it. Both of those can be true, and keeping both in mind is how you use it well.

• Sarcasm still wins too often. "Wonderful, only the third crash today" is praise-shaped and complaint-filled. Models catch more sarcasm than they used to, but a dry, deadpan sentence with no angry words in it will fool them regularly.
• Mixed feelings get flattened. "The camera is superb and the battery is a joke" holds two verdicts at once. A basic system must pick one label, and whichever it picks, half the truth is lost. Fancier systems score each aspect separately, but the plain headline verdict still hides the split.
• Words change sides by topic. "Cheap" is praise for a phone and a complaint about a hotel room. "Unpredictable" is a compliment for a film plot and a warning about a steering wheel. A model trained mostly on hotel reviews will make confident mistakes on car reviews, because in its world those words only ever meant one thing.
• Low-resource languages get a worse tool. Most labelled training text is English. For languages with far less of it — Myanmar among them — the same methods work noticeably worse. Often the text is quietly translated into English first, and feelings leak out on the way: the wording survives, the sting or the warmth does not always.

None of this makes the tool useless. It makes it a compass rather than a judge. Let it read the million comments and tell you where the mood is moving. Then go and read the twenty angriest ones yourself, slowly, the way my friend eventually did. The machine counts the weather. The understanding is still your job.

Takeaways

• Sentiment analysis gives one verdict — positive, negative, neutral, or a score — for a piece of text, by matching it against patterns of how feelings are usually written.
• The old way counted words from scored lists, with rules patched on top; negation and sarcasm broke it again and again.
• The neural way learns from large piles of human-labelled examples, using embeddings and whole-sentence context, so patterns like "not bad" are learned instead of legislated.
• The output is a probability, not a fact — the size of the score is the size of the doubt.
• Sarcasm, mixed feelings, topic-specific words, and low-resource languages all still cause real errors, so treat the result as a compass, not a judge.

Same word, two verdicts: "cheap" changes its feeling with the thing it describes, and no word list can save you from that.

References and further reading

• Sentiment analysis — Wikipedia
• Word embedding — Wikipedia
• BERT: Pre-training of Deep Bidirectional Transformers for Language Understanding — Devlin et al., arXiv:1810.04805
• Sequence classification — Hugging Face Transformers documentation

— Min SiThu Software Engineer & Tech Content Creator https://minsithu.org

A few weeks ago I pasted a long article written in Myanmar into a chatbot and asked for a summary. It stopped and told me the text was too long. I was puzzled — the article did not feel that long. So I ran the same piece through a rough translation, pasted in the English version, and asked again. This time it fit with room to spare. Same article, same meaning, same chatbot. Only the language had changed, and somehow the Myanmar version had taken up far more room. That small, annoying moment is what this article is about.

Think of the model's memory as one sheet of paper on a desk. Everything you say, and everything it answers, has to fit on that sheet. English gets to write on the sheet in shorthand — a few marks stand for a whole word. Myanmar has to spell everything out letter by letter, in full. The same idea, written the long way, fills the page much sooner. The rest of this article is just explaining why the spelling-out happens.

Five reasons Myanmar text gets chopped so much finer than English.

A tokenizer learns its chopping habits from English

Before a model can read anything, a tokenizer cuts your text into pieces called tokens, and each piece becomes a number. The model never sees your sentence. It sees the numbers. So piece size matters: big pieces mean few numbers, tiny pieces mean many.

How does the tokenizer decide where to cut? Most modern models learn the cuts from data, using a method called byte pair encoding. During training, the system scans a huge pile of text and keeps merging whichever pair of pieces appears side by side most often. Frequent neighbours become one bigger piece. Rare neighbours never get merged, and stay small.

Here is the catch. That huge pile of text is mostly English, because most of the easily collected text on the internet is English. So the merges the tokenizer learns are English merges:

• Common English words like "the" survive as a single token
• Slightly rarer words split into two friendly halves, like a root plus an ending
• Myanmar combinations appear so rarely in the pile that almost no merges are learned for them
• With no merges to use, the tokenizer falls back to cutting smaller and smaller — often down to single characters, and for some shapes, down to the raw bytes underneath

The tokenizer is not being unfair on purpose — its habits were formed on English, and Myanmar never got enough practice time.

Myanmar script offers no easy places to cut

Even a fair-minded tokenizer would struggle with Myanmar, because the script itself hides the cut lines.

English is generous to machines. Words arrive separated by spaces, and one letter is stored as one unit. Myanmar plays by different rules:

• There are no spaces between words. A Myanmar sentence is written as a flowing line of syllables. The spaces you do see usually mark off a phrase or a pause, more like a comma than a word boundary. A machine looking for words cannot just split on spaces the way it does with English.
• Consonants stack. In many words, one consonant sits below another, written with a special mark that kills the vowel of the letter above. What your eye reads as one tidy syllable is stored as several separate pieces of code.
• Marks combine. Vowels and tones are often not letters at all, but small marks written above, below, before, or after a consonant. They are stored as their own code points, so one visible character on the screen can be three or four units in the file.
• The same syllable can be typed in different orders. Some marks are typed before the letter they sit beside on screen, so two files can look identical but be built differently underneath.

Your eyes glide over all of this without noticing. You read syllables, not code points. A tokenizer counts code points, and for Myanmar there are simply many more of them per idea.

Count the pieces yourself

You do not need a language model to feel the difference. Plain Python and one short phrase are enough. Here are two ways of saying the same thing — "the Myanmar language" — counted three different ways:

english = "the Myanmar language"
myanmar = "မြန်မာဘာသာ စကား"

print("English:", len(english), "characters,", len(english.split()), "words")
print("Myanmar:", len(myanmar), "characters,", len(myanmar.split()), "space-separated parts")
print("English in bytes:", len(english.encode("utf-8")))
print("Myanmar in bytes:", len(myanmar.encode("utf-8")))

Run it and you get something curious:

English: 20 characters, 3 words
Myanmar: 15 characters, 2 space-separated parts
English in bytes: 20
Myanmar in bytes: 43

At first glance Myanmar looks shorter — 15 characters against 20. But look at what Python is really counting. Those 15 "characters" include silent helper marks: the little killer mark that stacks a consonant, the vowel signs, the tone mark. They are not letters you could say out loud on their own. And the "2 parts" from splitting on spaces is a polite lie, because the phrase holds several words; the space is a phrase break, not a word break.

The byte row is the one that matters for a tokenizer. English letters cost one byte each. Every Myanmar code point costs three bytes. When a tokenizer has no ready-made piece for a Myanmar combination, many tokenizers fall back towards bytes — and 43 bytes can mean several times as many tokens as the handful an English phrase needs. The numbers in this tiny example are exact; the token counts in real models vary, but the direction is always the same.

What happens to a Myanmar sentence on its way into a model.

More pieces means a higher bill and a shorter memory

This would be a cute technical detail if it stayed inside the tokenizer. It does not. It follows you into everyday use:

• The same sentence costs more. Many AI services charge by the token. A Myanmar paragraph that becomes several times more tokens than its English twin costs several times more to send and to answer — for the same content.
• The context window fills faster. Remember the sheet of paper on the desk. A long Myanmar document, spelled out piece by piece, covers the sheet sooner, so the model "forgets" the beginning of your conversation earlier, and long documents get refused or cut off — exactly what happened to my article summary.
• Answers can be slower. More tokens means more steps of work for the model, in and out.
• The model has seen less of the language. Myanmar makes up a small share of the text these models train on, so the model has had less practice reading it — and the few examples it did see were chopped into tiny pieces, which makes the patterns harder to spot.

None of this means the model is bad at Myanmar on purpose. It means the language starts the race several steps behind, at the very first step of the pipeline, before any intelligence is involved.

One language, two encodings

Myanmar also carries a piece of history that English never had to deal with. For years, the most common way to type Myanmar on phones and computers was a font system called Zawgyi. Zawgyi looked fine on screen, but it stored the text in its own private arrangement, different from the world standard, Unicode.

The result is that a large share of the Myanmar text on the internet exists twice over — once in Unicode order, once in Zawgyi order — and the two files can look identical to you while being completely different underneath. For a tokenizer, that is a quiet disaster:

• Training data for Myanmar is split between two rival spellings of the same language
• A tokenizer trained mostly on one encoding meets the other as a stranger
• Text copied from an old website may paste into a chatbot as a sequence the model has rarely seen, even though it reads perfectly well to you

The country has been moving to Unicode for years, and new text is increasingly standard. But the old text is still out there, still being copied, and still quietly confusing the machines.

The gap is closing, but slowly

I do not want to leave you with the idea that this is hopeless, because it is not. Newer tokenizers are trained on more balanced mixtures of languages. More Myanmar text is published in Unicode every year. And anyone who works with the language can help: type in Unicode rather than Zawgyi, and when a tool struggles with a long Myanmar document, split it into smaller pieces instead of assuming the tool is broken — it may simply have run out of sheet.

The deeper lesson travels well beyond Myanmar. A language model does not treat all languages equally, and the inequality does not start with the model's opinions or knowledge. It starts with the chopping — with how much of your sentence survives the first cut, and how much room it is allowed to take up. Next time a chatbot answers you better in English than in Myanmar, you will know one honest reason why, and it has nothing to do with how smart the model is.

Takeaways

• Tokenizers learn their cut lines from training text, and that text is mostly English, so English keeps big pieces and Myanmar gets tiny ones.
• Myanmar script hides word boundaries: no spaces between words, stacked consonants, and combining marks mean many more code points per idea.
• More pieces mean real consequences — higher token cost, a context window that fills sooner, slower answers, and less training practice for the model.
• The old Zawgyi encoding splits Myanmar data in two, so the model effectively sees even less of the language.
• Typing in Unicode and feeding long documents in smaller pieces are two small things that genuinely help.

The same meaning, carried in very different numbers of pieces.

References and further reading

• Myanmar script — Wikipedia
• Burmese language — Wikipedia
• Byte pair encoding — Wikipedia
• Zawgyi font — Wikipedia
• Tokenization — Wikipedia

— Min SiThu Software Engineer & Tech Content Creator https://minsithu.org

A friend of mine runs a small online shop. Last month she messaged me, a bit frustrated: "I want a chatbot that answers questions about my refund policy. Do I have to train my own model?" She had spent two evenings reading articles, and the same three words kept going around in circles — prompting, RAG, fine-tuning — as if they were three brands of the same product. They are not. They solve different problems, they cost very different amounts of time and money, and picking the wrong one is how people spend three weeks building something a well-written prompt would have handled in an afternoon.

Here is the picture that cleared it up for her. Think of the model as a capable cook who has just joined your kitchen. The cook is talented and has cooked all over the world, but knows nothing about your shop, your recipes, or how you like things done. Prompting is standing next to the cook and giving tonight's instructions out loud. RAG is handing the cook your recipe book and letting them look things up while they work. Fine-tuning is sending the cook away to train in your style for a month, so the skill lives in their hands and you no longer need to explain. Same cook, three very different kinds of help.

One model, three ways to teach it your material: tell it, let it read, or train it.

Prompting Changes Nothing Inside the Model

Prompting is the one you already know. You write instructions, you set the tone, you paste in the facts that matter, and sometimes you show an example or two of the answer you want. "You are the support assistant for my shop. Answer politely and briefly. Our refund policy is this…" — that is a prompt doing real work.

Nothing inside the model changes while you do this. The cook is exactly the same cook; you are just standing closer and explaining better. Everything the model knows for that conversation lives in the context, the text it can see right now. Close the chat, and it is all gone.

That sounds like a weakness, and sometimes it is. But look at what you get for it:

• It costs nothing to start and nothing to change — edit a sentence and the behaviour changes.
• It works with any model, including the big hosted ones you cannot retrain anyway.
• It is the fastest way to test an idea before building anything bigger.

Its limits are honest ones. The model can only use what fits in the context, so you cannot paste your whole company archive into every chat. Long instructions can get ignored or muddled. And if the model simply does not know a fact and you did not paste it, a good prompt will not save you — it will guess, politely and wrongly. Prompting steers knowledge the model already has, or knowledge you hand it in the moment. It does not add new knowledge on its own.

RAG Lets the Model Read Your Documents First

RAG stands for retrieval-augmented generation, which is a heavy name for a friendly idea: before the model answers, go and fetch the pages that matter, put those pages into the prompt, and let the model answer from them.

Back to the kitchen. Your cook does not carry every recipe in their head. When an order comes in, they walk to the shelf, pull out the right page, read it, and then cook. Your documents stay on the shelf, in your hands. The model itself is untouched — the same general model everyone else uses — but every answer is built on text you supplied a second earlier.

This is why RAG is the usual answer for questions about policies, manuals, product catalogues, contracts, and support tickets. The knowledge stays fresh in a way training never can: edit the refund policy document this morning, and the very next answer uses the new version. No retraining, no waiting. And when the model answers, it can point at the page it read, which makes its answers much easier to check.

RAG in five steps: ask, search your documents, build the prompt, let the model read, get an answer grounded in your pages.

Here is the whole idea in a few lines of Python — a tiny document list, a simple keyword search, and the found text placed into a prompt:

# RAG in miniature: search first, then ask with the found text included
documents = [
    "Refunds are given within 14 days of delivery.",
    "Delivery inside the city takes 2 to 3 working days.",
    "All electronics carry a one year warranty.",
]

def retrieve(question):
    words = question.lower().split()
    best = max(documents, key=lambda d: sum(w in d.lower() for w in words))
    return best

fact = retrieve("How long do I have to return an item?")
prompt = f"Answer using only this fact: {fact}\nQuestion: how long do I have to return an item?"
print(prompt)

Three things are happening in that little script, and they are the same three things in every real RAG system. First, the documents sit in a list, ready to be searched — in a real system this might be thousands of pages in a database. Second, retrieve scores each document by how many of the question's words appear in it and picks the best match; real systems usually compare meanings with embeddings instead of raw keywords, which is smarter, but the job is identical. Third, the winning text is pasted straight into the prompt, so the model answers from your words instead of from its memory. Search first, read second, answer third.

The costs are real but modest: you have to keep the document collection tidy, and the search step has to be decent, because a model reading the wrong page will give a confident answer about the wrong thing. Garbage page in, garbage answer out.

Fine-Tuning Changes the Model Itself

Fine-tuning is the heavy tool. You collect examples — often hundreds or thousands of them — showing the model the behaviour you want: questions paired with your ideal answers, text paired with the label it should get, messy input paired with the exact format you want back. Then you train the model on those examples, and its internal weights shift a little. The behaviour stops being an instruction it follows and becomes a habit it has.

This is the cook coming back from a month of training in your kitchen's style. You no longer stand there explaining that your shop answers briefly, warmly, and always mentions the warranty. They just cook that way now, every time, without being told.

That makes fine-tuning the right tool for behaviour and style:

• A tone or output format the model must hit every single time, not just when the prompt is perfect.
• A repeated, narrow job — classifying tickets, extracting fields from forms, tagging products — done the same way ten thousand times.
• Cases where the prompt would need to be enormous, because the examples carry the lesson better than instructions do.

What fine-tuning is bad at is facts. People imagine training a model on their price list so it "knows" the prices, and this is where the money gets wasted. Knowledge baked into weights is frozen on training day, hard to update, and unreliable — the model may still invent a price with total confidence, because you trained its habits, not its memory. It also costs the most of the three: preparing clean examples takes real human hours, the training run itself costs money or hardware, and every update means doing it again. Fine-tune for how the model behaves. Do not fine-tune to store what it should know.

They Are Not Rivals, and Good Systems Stack Them

Here is the part the comparison articles usually miss: these three are not competitors. They work at different layers, and most well-built systems use more than one at the same time.

The order I recommend to anyone starting out:

• Start with prompting. It is free, instant, and often enough. Write the instructions, paste the key facts, test with real questions.
• Add RAG when the answers need your facts — documents, policies, catalogues, anything that changes or anything the model must quote accurately.
• Fine-tune only when behaviour is the problem: the format keeps slipping, the tone is wrong, or the same narrow job runs all day and needs to be fast and consistent.

My friend's shop never needed training at all. Her chatbot today is a plain model, a clear prompt, and RAG over her policy and delivery pages. When she changes the refund window next month, she will edit one document, and the chatbot will know. If she later wants every reply to sound exactly like her, short and warm and in her phrasing, that is when fine-tuning earns its place — on top of the other two, not instead of them.

Takeaways

• Prompting changes what you say to the model: instructions and examples in the context, nothing inside the model changes, cheapest and fastest to adjust.
• RAG changes what the model reads: your documents are searched at question time and pasted into the prompt, so answers stay fresh and can be checked against the source.
• Fine-tuning changes the model itself: training on examples moves behaviour and style into the weights, which costs the most and freezes knowledge at training time.
• Use fine-tuning for behaviour, RAG for facts, and prompting for everything you have not proven you need yet.
• The three stack: most good systems combine a clear prompt, retrieval over live documents, and fine-tuning only where habit matters more than instructions.

Prompting, RAG, and fine-tuning compared: what changes, what it costs, and how fresh the knowledge stays.

References and further reading

• Prompt engineering — Wikipedia
• Retrieval-augmented generation — Wikipedia
• Fine-tuning (deep learning) — Wikipedia
• Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks — Lewis et al., arXiv:2005.11401
• Fine-tuning — OpenAI API documentation

— Min SiThu Software Engineer & Tech Content Creator https://minsithu.org

A small scene from my own desk. I once asked a model to finish the line "The cat sat on the" ten times, with the setting turned low, and it answered "mat" ten times in a row. Then I turned the setting up and asked again. This time I got "mat", "floor", "windowsill", and once, memorably, "keyboard". Nothing inside the model had changed between those two runs. It knew the same words, and it believed in them in exactly the same order. The only thing I had moved was how far it was allowed to stray from its first choice.

The whole article on one card: one dial, sitting between the model's scores and the word it finally picks.

The model scores every possible next word

A language model writes one word at a time — strictly, one token at a time, where a token is a word or a piece of a word. Before it writes each one, it looks at everything so far and does something most people never see: it gives a score to every word it knows. These raw scores have a name, logits, and you can think of them as the model's gut feeling, written down as numbers. "Mat" gets a high score. "Floor" gets a lower one. "Banana" gets a score so low it is almost a joke.

Scores are awkward to work with, so a function called softmax turns them into chances — clean percentages that add up to exactly 100. After "The cat sat on the", the chances might look like this: "mat" 63 percent, "floor" 23 percent, "sofa" about 9 percent, "roof" 5 percent, and a long tail of stranger words sharing the crumbs. That list is the model's honest opinion about what comes next.

Then comes the step this whole article is about: picking. The model does not have to take the top word. In normal use it samples — it picks at random, but not fairly. Each word's chance of being picked is exactly its percentage. "Mat", at 63 percent, gets picked most of the time. "Roof", at 5, sneaks in once in a while, and the sentence wanders off somewhere you did not expect. Temperature is the setting that reshapes those percentages just before the pick.

Temperature stretches or squeezes the chances

Here is the whole mechanism, and it is smaller than people expect. Before softmax runs, every score is divided by the temperature. That is it. One division. But division changes the shape of the result in a way worth understanding.

Dividing by a small number, like 0.5, makes every score bigger — and, more importantly, makes the gaps between scores wider. The favourite pulls further ahead of the pack. After softmax, its chance grows and everyone else's shrinks. Dividing by a big number, like 2, squeezes the scores together. The gaps narrow, the underdogs catch up, and words the model only half believed in suddenly get a fair hearing. A temperature of exactly 1 leaves the scores untouched: the model's raw opinion, unedited.

It works a lot like ordering noodles and choosing your chilli level. Mild, and the bowl tastes the way it always tastes — safe, familiar, a little plain. Extra hot, and the same bowl becomes an adventure: exciting, surprising, and once in a while a genuine mistake. The cook did not change. The noodles did not change. Only the level you asked for changed.

Here is the flow in a picture, because this is the part worth fixing in your head:

Four steps happen before every single word a model writes. Temperature lives in step two.

And here is the same idea as a few lines of Python, so you can watch the chances move yourself:

import numpy as np

def softmax(logits, temperature):
    scaled = np.array(logits) / temperature  # temperature lives in this one line
    scaled = scaled - scaled.max()           # keep the numbers small and safe
    exp = np.exp(scaled)
    return exp / exp.sum()

scores = [3.0, 2.0, 1.0, 0.5]  # mat, floor, sofa, roof

for t in (0.5, 1.0, 2.0):
    print(t, np.round(softmax(scores, t), 3))

Run it and three lines come back. At temperature 0.5, "mat" climbs from 63 percent to about 86, and "roof" nearly vanishes at less than 1 percent. At 1.0, nothing changes — 63, 23, 9, 5, the model's own opinion. At 2.0, "mat" falls to 44 percent while "roof" rises to 13. Same scores in, three very different sets of chances out. The subtraction in the middle line is only housekeeping — it stops the exponentials from growing into numbers too big for the computer to hold — but the division in the first line is the entire dial.

Temperature zero means always take the favourite

Push the idea to its limit and you get temperature 0. Dividing by a number that tiny would stretch the gaps so far that the favourite takes everything — so in practice, systems treat 0 as a simple rule: forget the random pick, always take the highest-scoring word. This is called greedy decoding.

Greedy has real virtues. Ask the same question twice and you get the same answer twice, which is exactly what you want when a program is pulling a date out of an invoice or filling in a form. But greedy text also goes flat fast. A model that always takes its safest word starts repeating itself — the same phrase, the same sentence shape, sometimes the same sentence, in a loop. Safe is not the same as good. It is just safe.

Top-k and top-p trim the menu instead

Temperature has two companion settings, and they solve a nearby problem: sometimes you do not want to reshape the chances, you want to remove the silly options entirely. Top-k keeps only the k best-scoring words — say the top 40 — and throws the rest away before the pick. Top-p, also called nucleus sampling, keeps the smallest group of words whose chances add up to some share, like 90 percent, and cuts the rest. On a confident turn, that group might be three words. On an open turn, it might be three hundred.

In practice the three settings work as a team. Top-k and top-p decide who is allowed into the room. Temperature decides how boldly the model chooses among the ones inside.

Which setting for which job

So what should you actually use? The honest answer is that it depends on what a wrong word costs you. Some rough settings that work well in daily use:

• Code, maths, and anything you will run or submit: 0 to 0.3. You want the model's first answer, the same way every time.
• Facts, summaries, and pulling details out of a document: 0.2 to 0.5. A little freedom, no adventures.
• Everyday chat, emails, and drafts: 0.6 to 0.8. Natural variety without wandering off.
• Stories, poems, names, and brainstorming: 0.9 to 1.2. This is where the surprises you actually want live.
• Above 1.3 or so: expect drift, invented words, and broken grammar. Fun to play with, risky to ship.

One more thing worth knowing: the dial is applied again at every single word. A short answer barely feels it. A long answer feels it hundreds of times, and small chances compound — which is why a warm setting can start a story sensibly and be somewhere quite strange by page two.

One warning matters more than the numbers. Temperature cannot fix a model that does not know something. Turning the heat up does not create knowledge — it just makes the guessing bolder. A wrong fact at low temperature is a wrong fact stated plainly. The same wrong fact at high temperature is a wrong fact wearing a costume. If the answer matters, the fix is better information in the prompt and checking afterwards, not a luckier dial.

Here is the whole dial in one picture — the same four words from the code above, at two settings of the range:

Same model, same sentence, same scores. The only thing that moved is the temperature.

Takeaways

• A model scores every possible next word, softmax turns the scores into chances, and sampling picks one — temperature reshapes the chances in between.
• Low temperature widens the gaps: the favourite wins almost always, so text is steady, factual, and sometimes repetitive.
• High temperature levels the field: unlikely words get their turn, so text is varied, creative, and riskier.
• Temperature 0 is greedy decoding — always take the top word, no randomness, no surprises.
• Top-k and top-p trim which words may be picked at all; temperature decides how boldly the model picks among the survivors.
• Match the dial to the cost of a wrong word: cold for code and facts, warm for stories and ideas.

References and further reading

• Softmax function — Wikipedia
• Boltzmann distribution — Wikipedia
• Generation — Hugging Face Transformers documentation
• Distilling the Knowledge in a Neural Network — Hinton, Vinyals and Dean, arXiv:1503.02531

— Min SiThu Software Engineer & Tech Content Creator https://minsithu.org

A few weeks ago I was deep into a long chat with a model, planning a small piece of software. Early on I had told it three things: my budget, the tools I wanted to use, and one firm rule — no paid services. An hour later, after dozens of messages back and forth, it cheerfully suggested a paid service. I stared at the screen. Had it not been listening? It had been listening. It had simply run out of room to keep my rule in view.

Think of the model as a person working at a small desk. Everything they are allowed to look at must fit on that desk: the instructions from their boss, the conversation so far, your newest note. The desk does not grow. When a new paper arrives and there is no space left, the oldest paper slides off the far edge and is gone. The worker is not careless and not forgetful by nature — the desk is just small. A context window is that desk, and most of the strange behaviour of chatbots makes sense once you see the desk clearly.

The context window in five ideas: tokens, falling out, cost, and working with the limit.

The Window Is Measured in Tokens, Not Words

The size of the desk is not counted in words or pages. It is counted in tokens. A token is a chunk of text — sometimes a whole word, sometimes half a word, sometimes a single character or a space. Models do not read letters the way we do; they read these chunks, and every chunk takes up one slot on the desk.

For English, one token is roughly three quarters of a word, so a window of 128,000 tokens holds very roughly 96,000 words — a medium novel. That sounds enormous, and it is, compared to the few hundred tokens early models could hold. But the counting matters, because everything is billed by the token: the space a text occupies, the time a reply takes, and usually the price you pay.

You can count tokens yourself in a few lines of Python. The library below is the real counter used with OpenAI-style models, so the number it gives is the number the model itself would see:

import tiktoken

enc = tiktoken.get_encoding("cl100k_base")
text = "The context window is everything the model can see right now."
tokens = enc.encode(text)
print(len(tokens), "tokens")
print(tokens)

Run it and you get 12 tokens for that one sentence, followed by the list of token numbers themselves. Try a long word like "antidisestablishmentarianism" and you will see it split into six tokens — the model does not get it in one piece. Try text in another language and the count climbs faster, because the chunking was learned mostly from English. Same desk, but some languages take up more of it per sentence. Remember that; it comes back later.

What Actually Sits Inside the Window

Here is the part most people get wrong: the window does not hold only your latest message. Every time the model replies, the whole desk is laid out again in front of it. A typical window holds four things, in this order:

• The system prompt — standing instructions set by the app or developer before you ever type, such as who the assistant is and how it should behave.
• The chat history — every earlier message, yours and the model's, in order, from the start of the conversation.
• Your new message — the thing you just typed, plus anything you pasted or attached with it.
• Room for the reply — the answer itself is written token by token inside the same window, so space must be left for it.

Everything the model can see, laid out in order, every single turn.

This is why a pasted document changes everything. Paste a 40-page report into the chat and you have not handed the model a file to keep — you have covered most of its desk with that report. It can answer questions about the report beautifully, because the report is right there in view. Start a new chat tomorrow and the report is gone, because nothing was ever stored. The window is working space, not a filing cabinet.

It also explains a subtle habit: models are usually best at the start of a conversation and at the very recent end. The middle of a very long chat is the part of the desk furthest from the worker's eyes.

When the Window Fills, the Oldest Text Falls Out

A conversation cannot grow forever, because the desk cannot. When the total text reaches the limit, something has to give. In most chat apps, the oldest messages are quietly dropped — truncated — to make room for the new ones. Some apps instead summarise the early part and keep the summary, which is gentler but still a lossy copy of what you actually said.

And this is the honest answer to the most common complaint about chatbots: "it forgot what I told it." Usually the model did not forget in the human sense. Your instruction slid off the desk. From the model's side there is no warning bell and no gap in its memory — the text is simply not in front of it, so it answers as if it was never said. My "no paid services" rule was not ignored out of rudeness. By the time the paid suggestion appeared, the rule had fallen off the edge an hour earlier.

A few signs that your window is filling up:

• The model contradicts a decision you both made early in the chat.
• Names, numbers, or rules you set at the start come back changed or missing.
• The model asks a question you already answered near the beginning.
• Long pasted documents stop being quoted accurately, especially their early pages.

When you see those signs, the fix is boring and effective: restate the important facts. Put the paper back on the desk.

A Bigger Window Is Not a Free Lunch

If a small desk causes trouble, why not give every model a huge one? Windows have indeed grown fast — from a few thousand tokens to a million or more in some models. But a bigger window costs real things:

• Money and time: every token in the window is processed on every reply, so a long window means each answer is slower and more expensive to produce.
• Attention dilution: the model spreads its attention across everything in view. The more text on the desk, the easier it is for one important line to be lost among a thousand unimportant ones.
• The middle problem: research has shown that models use information at the very start and the very end of a long window well, and information buried in the middle much less reliably — even when it technically fits.

So a million-token window is not a million-token memory you can trust blindly. It is a bigger desk with the same worker. The fact that a document fits inside the window means the model can see it, not that it will use it well. Knowing that difference will save you from the most common disappointment with long documents: "but I gave you the whole file." You did. It just could not keep all of it in sharp focus at once.

Working With the Limit Instead of Against It

Once you see the desk, a few practical habits follow naturally, and they are the same habits the professionals use when they build with these models:

• Keep the important facts near the end. Restate your goal, your rules, and your key numbers in your latest message instead of assuming the model still holds them from an hour ago.
• Summarise as you go. In a long session, ask the model to write a short summary of decisions so far, then start a fresh chat with that summary at the top. You have replaced a falling pile of papers with one tidy page.
• Feed documents in chunks. Rather than pasting an entire book, work through it section by section, discussing each part while it is fully in view.
• Let a system fetch only what is needed. This is the idea behind RAG — instead of covering the desk with a whole library, software searches the library first and places only the few relevant pages on the desk for each question.

None of this is a trick or a hack. It is just tidying the desk so the worker can see what matters.

The context window is the simplest idea in this whole field, and I keep coming back to it because it explains so much: the forgetting, the confidence, the strange strength at the start of a chat and the drift at the end of one. The model is not a mind with a memory. It is a very capable reader with a desk of a fixed size — and your job, as the person using it, is to decide what stays on that desk.

Takeaways

• A context window is all the text a model can see at once, measured in tokens, not words.
• It holds the system prompt, the whole chat history, your new message, and room for the reply.
• When it fills, the oldest text is dropped or summarised — that is why models "forget" mid-conversation.
• Bigger windows cost more, answer slower, and spread attention thinner, especially in the middle.
• Work with the limit: restate key facts, summarise long chats, chunk documents, and fetch only what is needed.

When the window fills, new text pushes in from the right and the oldest text leaves from the left.

References and further reading

• Context window — Wikipedia
• Context windows — Anthropic Claude documentation
• Lost in the Middle: How Language Models Use Long Contexts — Liu et al., arXiv:2307.03172
• Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks — Lewis et al., arXiv:2005.11401

— Min SiThu Software Engineer & Tech Content Creator https://minsithu.org

Short version: start small, build something, then go deep — and let each book do the one job it is best at.

Here is a small scene from real life. When I was starting out, I bought the thickest machine learning book I could find, because thick felt serious. I opened it on page one, hit a wall of maths by page twelve, and the book became a very expensive paperweight for six months. The mistake was not the book. The mistake was reading the books in the wrong order. A book is a tool, and a tool used at the wrong moment is just a heavy object.

So here they are, in the order I wish someone had given them to me.

1. The Hundred-Page Machine Learning Book, by Andriy Burkov

Cover © Andriy Burkov — via Open Library

Start here. This book does what its title promises: the whole field, in about a hundred pages, written for someone who already programs but has never touched machine learning. No thousand-page tour, no chapter that takes a week. You can read it in a weekend and walk away knowing what supervised and unsupervised learning actually mean, how a model is trained and tested, and which words people keep using at meetups.

What it actually teaches you: the map. You will not be an expert after this book, and it never pretends you will be. You will know what the territory looks like, which is exactly what you need before you pick a direction. It is also cheap, short, and honest about its limits — three qualities rare in technical books.

2. Hands-On Machine Learning with Scikit-Learn, Keras, and TensorFlow, by Aurélien Géron

Cover © O'Reilly Media — via Open Library

This is the book for the moment you want to build something. Where the first book gave you the map, this one hands you the tools and says "let us build." Every chapter ends with a working model you can run yourself — a classifier, a regressor, a neural network — and the code is the star, not the theory. Géron explains just enough maths to make the code make sense, then gets out of the way.

What it actually teaches you: how to build. After this book you can take a real dataset, clean it, train a model, measure it honestly, and put it somewhere useful. For most working programmers, that skill is the whole job. This is the book I would hand to a friend who says "enough reading, I want to make one."

3. Machine Learning Yearning, by Andrew Ng

Cover © Andrew Ng / DeepLearning.AI — via DeepLearning.AI This one is free, and it is the most practical book on the list. Andrew Ng wrote it after years of leading machine learning teams, and it is not about algorithms at all — it is about decisions. How do you know whether your model needs more data or a better model? When is your test set lying to you? How do you split your time between collecting data and tuning the model?

What it actually teaches you: judgment. Two models can have the same code and very different results, and the difference is usually a decision the programmer made along the way. This book is a list of those decisions, with the reasoning behind each one. Read it after you have built your first few models, when you have felt the confusion it describes. Before that, it will read like advice for a problem you have not had yet.

4. Deep Learning, by Ian Goodfellow, Yoshua Bengio, and Aaron Courville

Cover © MIT Press — via Open Library

Now we go deep, in every sense. This is the textbook of deep learning, written by three of the people who built the field, and it is the book to read when you are ready to understand why neural networks work instead of just how to use them. It starts with the maths you need, builds up through the architectures, and ends with the research frontier.

What it actually teaches you: the theory underneath the tools. It is a hard book, and it should be read slowly, with a notebook, over months — not in a weekend. But if you want to move from using models to understanding them, and one day to inventing them, this is the road. The whole book is also free to read online, which is generous for a book this good.

5. Pattern Recognition and Machine Learning, by Christopher M. Bishop

Cover © Springer — via Open Library

The classic. Published in 2006, and still the reference that other books point to. Bishop writes with a patience that is rare in textbooks: every idea is introduced gently, built up carefully, and connected to the ideas around it. The maths is real, and it does not apologise — but it never shows off either.

What it actually teaches you: the foundations, properly. This is the book for the moment you want to understand machine learning as a subject, not a set of tricks. Keep it on your shelf, read it a chapter at a time, and come back to it whenever a new idea feels shaky. It is the kind of book that gets better the more you already know, which is the highest praise a textbook can earn.

Read them in this order, and skip nothing by accident

• The Hundred-Page Machine Learning Book — the map, read it first, in a weekend
• Hands-On Machine Learning — the building, run the code, make something real
• Machine Learning Yearning — the judgment, read it once your first models exist
• Deep Learning — the theory, slow and steady, with a notebook
• Pattern Recognition and Machine Learning — the foundation, keep it on the shelf for years

One warning, from someone who learned it the hard way: do not read all five at once. Read one, build something with it, and only then reach for the next. Books do not make you a machine learning engineer. Books plus projects do.

Takeaways:

• Start with the short map book before touching the thick textbooks
• The hands-on book is where you learn to actually build a working model
• Andrew Ng's free book teaches judgment — the decisions behind the code
• The deep learning textbook is for understanding why, read slowly over months
• Bishop's classic is the long-term reference to keep on the shelf

References and further reading

• The Hundred-Page Machine Learning Book — official site
• Machine Learning Yearning — mlyearning.org
• Deep Learning — official site
• Machine learning — Wikipedia
• Pattern Recognition and Machine Learning — Springer
• Book cover images: Open Library and DeepLearning.AI — credit lines under each cover

— Min SiThu Software Engineer & Tech Content Creator https://minsithu.org

Short version: a library is a tool you pick up; a framework is a boss that hires you for one job.

Here is a small scene from everyday life. Imagine you are cooking dinner at home. You reach into a drawer, take out a knife, chop an onion, and put the knife back. The knife never tells you what to cook. That is a library — a tool that waits to be used, does its one job well, and never asks questions about the meal.

Now imagine you walk into a restaurant kitchen as a new cook. The head chef has already decided the menu, the order of the dishes, and the pace of the night. Your job is to stand at one station and do your part when the chef calls for it. You still cook — but inside someone else's plan. That is a framework. It owns the flow of the evening, and you fill in the gaps it leaves for you.

Inversion of control, in plain words

Programmers have a fancy name for this difference: inversion of control. It sounds complicated, but you just read the whole idea. In normal code, your program is the chef and the library is the knife — control flows from you outward. In a framework, control is inverted: the framework is the chef, and your code is the cook at one station. The framework decides when your code runs, in what order, and with what data.

This is why learning a framework feels different from learning a library. A library takes an afternoon: read the docs, call a function, done. A framework takes a week, because you are not learning a tool — you are learning someone else's way of building an app. Where do the files go? How does a web request travel from the browser to your code and back? What is the framework already doing for you, silently, before your code even runs? You have to learn its habits before you can work inside them.

Here is the smallest version of the difference, in code. First, a library — you call it:

import requests

response = requests.get("https://api.example.com/users")
print(response.json())

You wrote the plan. You decided when to call the library, what to ask for, and what to do with the answer. The library did one job and went home. Now a framework — it calls you:

@app.route("/users")
def list_users():
    return {"users": ["Aye", "Min", "Zaw"]}

You did not write a program that starts, fetches, and prints. You wrote one small function, handed it to the framework, and the framework decides when it runs — when a browser asks for that address. Your code is the cook at the station. The framework is the kitchen.

The trade-off is real, and it cuts both ways

The verdict: neither is better — the right choice depends on whether you need one tool or a whole kitchen.

A framework buys you speed by making a thousand small decisions for you. That is wonderful when you are building a standard web app and you want the boring parts handled. It is painful when your app does not fit the framework's idea of how apps should work, and you spend days fighting its assumptions instead of writing your feature. A library never fights you, because it never assumes anything — but it also never helps you with the boring parts, because it was never hired for that.

The honest rule I use: start with libraries while you are learning, because they teach you how the pieces work. Reach for a framework when you are building something real and you want its structure, its safety nets, and its community — and accept that you are joining its kitchen, with its rules, on purpose.

How to choose without regretting it

A few practical questions make the choice easy. Am I building one feature or a whole application? One feature points to a library. A whole app points to a framework. Do I need to understand every piece, or do I want the boring parts handled? Understanding points to libraries; handled points to a framework. And the question people forget: how easy is it to leave? A library is easy to swap out — you stop calling it. A framework is a marriage. Leaving one means rewriting the app around a new kitchen, so choose one with a community that will still be there in five years.

In real life, you will use both, every day

Here is the part nobody tells beginners: the line between the two is not a wall, it is a sliding scale. React is famously a library — it only handles the user interface, and you stay in charge of the rest. Next.js is a framework built on top of React, and it takes charge of routing, rendering, and more. Django, the big Python web framework, is itself built out of libraries, and you can pull libraries into a Django project whenever you need a tool it does not provide.

So a working programmer's day is not "library day" or "framework day." It is a framework running the app, libraries doing the specialist jobs inside it, and your code filling the gaps the framework left for you. The question is never which one is better. The question is always: for this job, do I want a tool, or do I want a kitchen?

Takeaways:

• A library is a tool you call; a framework is a structure that calls your code — that is inversion of control
• Libraries are quick to learn and flexible; frameworks take longer but handle the boring parts for you
• Neither is better in general — the right one depends on what you are building
• Start with libraries while learning, reach for a framework when you want its structure on a real app
• Ask how easy it is to leave before you commit to a framework

References and further reading

• Software framework — Wikipedia
• Library (computing) — Wikipedia
• Inversion of control — Wikipedia

— Min SiThu Software Engineer & Tech Content Creator https://minsithu.org

Short version: recursion is a function that says "this is almost the same problem, just smaller — let me ask myself."

Here is a small scene from everyday life. Stand between two mirrors and look at the reflection of the reflection of the reflection, shrinking into the distance. Each mirror shows the same scene, just smaller, and the chain only ends because the mirrors are not perfect — the light fades out. A recursive function is like those mirrors, except the programmer controls where the chain ends. That ending point is the whole secret, and forgetting it is the whole danger.

Or take a simpler scene. You are looking for a word in a dictionary. You open it in the middle. Your word is earlier in the alphabet, so you look at the left half. You open that half in the middle. Your word is later, so you look at the right half of that half. Each step is the same action — open in the middle, pick a half — applied to a smaller and smaller book, until the book is one page and there is your word. That is recursion in plain clothes: the same step, a smaller problem, a clear end.

Every recursive function has two parts

If you take any recursive function apart, you will always find the same two pieces, and only two:

• The base case — the smallest version of the problem, where the answer is so obvious you just return it. No more calls. The mirrors stop here.
• The recursive case — the step that makes the problem a little smaller and calls the function again on that smaller version.

Miss the base case and you have a function that calls itself forever, like a mirror reflecting a mirror with no wall behind it. The program keeps piling up unfinished calls until the computer runs out of memory and crashes with a stack overflow — which is a technical way of saying "the mirrors ate the machine."

Here is the smallest version that works, counting down to zero:

def countdown(n):
    if n == 0:          # the base case: stop here
        print("Blast off!")
        return
    print(n)
    countdown(n - 1)    # the recursive case: a smaller problem

Run countdown(3) and you get 3, 2, 1, "Blast off!" The function prints 3, then asks itself to count down from 2, which prints 2 and asks for 1, which prints 1 and asks for 0 — and at 0 the base case answers instead of asking. Then each waiting call finishes in turn, like a stack of plates being lifted off one by one. That stack is real: the computer keeps a list of half-finished calls, and each one waits patiently for the one above it to return.

Trust the smaller problem

The hard part of recursion is not the code. The code is short. The hard part is believing it. When you write countdown(n - 1), you have to trust that the call will do its job, without tracing every step in your head. Beginners try to follow the whole chain at once and get dizzy. Experienced programmers do something lazier and smarter: they check the base case, check that the problem really gets smaller each time, and then trust the rest.

That trust pays off on problems where the loop version is painful. Walking through a folder that contains folders that contain folders. Searching a family tree. Sorting by splitting a list in half again and again. These problems are naturally recursive — they are made of smaller copies of themselves — and the recursive code reads like a description of the problem, not a wrestling match with it.

A good test: if you can describe your problem as "do this, then solve the same problem on a smaller piece," recursion is probably the right tool. If the problem has no smaller piece — if it is just a list you need to walk through once — a plain loop is simpler, and simpler wins.

The stack overflow, explained honestly

Every recursive call waits. That waiting has a cost, and the cost has a name: the call stack. Each unfinished call sits on the stack, holding its place, until the calls above it finish. A thousand calls deep is usually fine. A million calls deep, and the stack runs out of room — the program crashes, and the error message says "stack overflow" or "maximum recursion depth exceeded."

This is not a reason to fear recursion. It is a reason to check two things before you write it: does the problem genuinely get smaller on every call, and is the base case reachable? If both answers are yes, the chain ends. If either answer is no, you have an infinite mirror, and no computer on earth can run it.

A classic example: the factorial

The textbook example is the factorial — the product of all the numbers from 1 up to n. The factorial of 5 is 5 × 4 × 3 × 2 × 1, which is 120. Watch how naturally it falls into the two parts:

def factorial(n):
    if n == 0:          # the base case: 0! is 1, by definition
        return 1
    return n * factorial(n - 1)   # 5! is 5 times 4!

This code says in plain words what the maths says: the factorial of n is n times the factorial of n minus one, until you reach zero. That is the whole definition, written as code, with nothing extra. When a problem's definition is already recursive, the recursive code is usually the clearest code you can write — it reads like the definition itself, because it is the definition itself.

Takeaways:

• Recursion is a function calling itself on a smaller version of the same problem
• Every recursive function needs a base case — the smallest problem, answered directly — and a recursive case that shrinks the problem
• Trust the smaller call instead of tracing the whole chain in your head
• Recursion shines on problems made of smaller copies of themselves, like folders inside folders
• If the problem never gets smaller, the calls pile up until the stack overflows

References and further reading

• Recursion (computer science) — Wikipedia
• Recursion — Khan Academy
• Stack overflow — Wikipedia
• Factorial — Wikipedia

— Min SiThu Software Engineer & Tech Content Creator https://minsithu.org

Short version: your password is never kept on the shelf — only its one-way fingerprint is.

Here is a small scene from everyday life. Imagine you run a small shop, and customers leave their house keys with you for safekeeping. Keeping the real keys in a drawer would be risky — anyone who breaks in gets every key. So instead you take each key, press it into a block of clay, and keep only the clay impression. When a customer comes back and hands you a key, you press it into clay again and compare the two impressions. If they match, it is the same key. And if a thief steals your box of clay impressions, they have shapes they cannot turn back into keys. That is, almost exactly, how password storage works.

The clay impression is called a hash. The key is your password. And the rule that makes the whole thing safe is one-wayness: easy to go from password to hash, practically impossible to go back from hash to password.

A hash is a fingerprint, not a copy

A hash function takes any input — a word, a sentence, a whole book — and squeezes it into a fixed-length string of characters. The same input always produces the same hash. Change one letter and the hash changes completely, in a way that looks random. And the hash is always the same length, whether you hashed the word "cat" or the complete works of Shakespeare.

That last part is the clue to why it is one-way. A hash of 64 characters can only hold so much information, and it has already thrown most of the original away. Trying to recover a password from its hash is like trying to rebuild a cow from a hamburger. The information is gone. The only way back is guessing: try a password, hash it, and see if it matches. That is why attackers steal hashes and then run through lists of common passwords — "123456", "password", birthdays — hashing each one and hoping for a match.

Here is the smallest version that works, in Python:

import hashlib

password = "correct-horse-battery"
fingerprint = hashlib.sha256(password.encode()).hexdigest()
print(fingerprint)
# 8d2b6c4e9f1a7... a long string that says nothing about the password

This code takes the password, runs it through SHA-256, and prints the fingerprint. Notice what it does not do: it never saves the password itself. The fingerprint is all a website needs to check you later — hash what you type, compare the two fingerprints, and let you in only if they match.

The salt stops the copy-paste attack

There is one problem with plain hashing, and it is embarrassingly simple. If two people both choose "sunshine123", they get the same hash. And attackers keep giant ready-made lists — rainbow tables — of common passwords and their hashes, so they can look up a stolen hash in seconds instead of guessing for weeks.

The fix is called a salt, and it is exactly what it sounds like: a pinch of something random added to every password before hashing. The site generates a long random string for you when you sign up, mixes it with your password, and hashes the mixture. It stores the salt next to the hash, in plain sight — the salt is not secret. But now "sunshine123" hashes differently for every single person, because every person has a different salt. The attacker's ready-made list becomes useless. They would have to start guessing from scratch, for every user, one by one.

So the honest answer to "how does the site store my password" is: it stores a salt and a fingerprint. Neither one is your password, and neither one, alone or together, can be turned back into it.

Why slow is a feature, not a bug

Here is the part that surprises people. The best password systems are deliberately slow. Functions like bcrypt and Argon2 are designed to take a noticeable fraction of a second — a delay you never feel when you log in once, but an attacker feels ten million times over when they try to guess ten million passwords. A hash that takes a tenth of a second to compute lets you log in happily and lets an attacker try only ten passwords a second. A fast hash would let them try billions.

That is the whole philosophy of password storage in one line: make checking one password cheap for the honest user, and checking a million passwords ruinously expensive for the thief.

What this means for you, the person typing the password

All of this machinery protects you, but it has one weak spot, and it is you. The strongest hash in the world cannot save a password you reuse on twenty sites, because one careless site leaking its database hands attackers the key to all the rest. Three habits cover almost everything:

• Use a different password for every important site, and let a password manager remember them — your brain was never meant to hold fifty passwords
• Make passwords long rather than clever. Four random words beat one tricky word with a number on the end, and they are easier to remember
• Turn on two-factor authentication wherever it is offered, so a stolen password alone is never enough to get in

The site does its half of the job with hashes and salts. These three habits are your half, and together they are far stronger than either one alone.

Takeaways:

• Good sites never store your password — they store a one-way hash, a fingerprint that cannot be turned back
• The same password always gives the same hash, but one changed letter changes the hash completely
• A random salt is mixed in so identical passwords get different hashes, defeating ready-made lookup tables
• Slow hash functions like bcrypt make guessing millions of passwords far too expensive for attackers
• A stolen database of hashes is still a problem — but it is a problem, not a disaster

References and further reading

• Cryptographic hash function — Wikipedia
• Salt (cryptography) — Wikipedia
• Bcrypt — Wikipedia
• OWASP Password Storage Cheat Sheet

— Min SiThu Software Engineer & Tech Content Creator https://minsithu.org

Short version: an algorithm is a recipe a computer can follow without asking questions.

Here is a small scene from real life. Last week a friend asked me for directions to my place, and I sent her a voice message: "Take the second left after the big market, go straight until you see the blue gate, then it is the third building." She got lost anyway. Why? Because "the big market" meant one thing to me and another thing to her, and "go straight" was true for three streets and then quietly false at the fourth. My directions were an algorithm with a bug in it — steps that sounded clear to the person who wrote them, but were not clear enough to the person following them.

That is exactly what programming is. You are writing directions for a follower who never guesses, never fills in the gaps, and never forgives a vague step. The computer will do precisely what you wrote, and nothing you meant. So the whole skill of algorithms is learning to write steps that cannot be misunderstood.

A recipe is an algorithm you already know

You already use algorithms every day, long before you touch a keyboard. Think about how you make instant noodles. You boil water. You add the noodles. You wait three minutes. You add the seasoning. You stir. You eat. Six steps, one order, one result. If you stir before you add the water, you have dry noodles and a mess. If you wait thirty minutes instead of three, you have soup with a memory of noodles in it.

That is the first thing to understand about algorithms: the order is the algorithm. The same steps in a different order are a different recipe, and often a broken one. When programmers argue about algorithms, they are usually arguing about order — which step should come first, which step can be skipped, and which step is quietly doing all the real work.

The second thing is that an algorithm has to end. A recipe that says "keep stirring forever" is not a recipe, it is a trap. Every good algorithm has a clear finish line: a point where it can say "done, here is your answer" and stop. Programmers call this termination, but the idea is just common sense. If your steps never stop, you never get dinner.

Every algorithm has the same four parts

Strip any algorithm down and you will find the same four pieces hiding inside it, whether it sorts a million numbers or finds the cheapest flight:

• An input — what you start with. The raw ingredients, the list of numbers, the text someone typed.
• A set of steps — the actual work, each one small and exact enough that it cannot be misunderstood.
• An output — what you get at the end. The sorted list, the answer, the finished dish.
• A clear end — the moment it stops, so it never runs forever.

When something goes wrong with a program, one of these four is almost always the culprit. The input was not what you expected. A step was vague. The output was right for the wrong question. Or the program never stopped at all, and your laptop fan started sounding like a small jet. Learning to check these four, one by one, is most of debugging, honestly.

The same problem can have many recipes

Here is where it gets interesting. For most problems, there is not one algorithm — there are dozens, and they trade off against each other like different routes to the same place. One route is short but full of traffic. Another is long but smooth. A third is fast only when the roads are empty.

Sorting is the classic example. You have a list of numbers in a mess, and you want them in order. The simplest recipe is to walk along the list, compare each pair of neighbours, and swap any pair that is out of order, then walk the whole list again and again until nothing needs swapping. It works. A child could follow it. But for a million numbers, it is slow enough to make you old. A smarter recipe splits the list in half, sorts each half, and stitches them back together — more thinking up front, far less walking overall.

Here is the smallest version that works, the simple one, finding the biggest number in a list:

def find_biggest(numbers):
    biggest = numbers[0]
    for n in numbers:
        if n > biggest:
            biggest = n
    return biggest

That is a whole algorithm in six lines. Start by assuming the first number is the biggest, then check every other number against it, and keep whichever wins. It is a recipe you could explain to a friend in one sentence, and the computer follows it exactly the same way.

Notice what the code does not do: it never asks you what "biggest" means, it never gets bored halfway through a long list, and it never skips the last number because it is tired. That is the whole point of writing it down this way. The computer is a tireless follower of recipes, and the algorithm is the recipe.

Why programmers care so much about recipes

You might wonder why programmers make such a fuss about something that sounds like common sense. The answer is scale. Your noodle recipe feeds one person, once. A search algorithm runs billions of times a day, on lists with billions of entries, and the difference between a clever recipe and a clumsy one is the difference between an answer in a blink and an answer next Tuesday.

That is why algorithms are the first serious subject in computer science, and why job interviews still ask about them after all these years. Not because anyone sorts numbers by hand at work, but because the way you think about a recipe — breaking a big problem into small exact steps, checking the order, proving it ends — is the way you think about every program you will ever write. Get good at recipes and the rest of programming gets easier, quietly, in the background.

Takeaways:

• An algorithm is a recipe: exact steps in an exact order, turning an input into an output
• Order is the algorithm — the same steps in a different order are a different, often broken, recipe
• Every algorithm needs an input, steps, an output, and a clear finish line
• Most problems have many recipes, and the best one depends on how big the problem is
• Thinking in recipes is the core skill of programming, not a side topic

References and further reading

• Algorithm — Wikipedia
• Sorting algorithm — Wikipedia
• Algorithms — Khan Academy
• Introduction to algorithms — GeeksforGeeks

— Min SiThu Software Engineer & Tech Content Creator https://minsithu.org

Think of the owner of a small bakery, standing in the dark at five in the morning, deciding how many loaves to bake. Bake too many and the extras go stale on the shelf, money thrown away. Bake too few and she sells out by nine, turning away the very customers she wants to keep. So she thinks: Tuesdays are slow, rain brings people in for soup and bread, the school holidays change everything. She is forecasting. She has always been forecasting. Data just lets her do it with numbers instead of a feeling in her stomach.

Last time, in Part 4, we used SQL to pull honest numbers about what already happened — revenue, churn, conversion. Prediction starts exactly where those numbers stop.

A forecast is the past, stretched carefully forward

Every forecast, from the bakery's loaf count to a supermarket chain planning a million items, follows the same rough path:

• Gather the past — months or years of sales, visits, sign-ups, whatever you want to predict
• Find the pattern — the weekly rhythm, the seasonal climb, the slow trend hiding under the noise
• Build a model — a small piece of mathematics that captures that pattern in a form a computer can use
• Make the forecast — feed in what you know about next week or next month and let the model extend the pattern
• Check it against reality — when the real numbers arrive, compare, learn how wrong you were, and adjust

That last step is the one people skip in their imagination. A forecast is not made once and framed. It is made, measured, corrected, and made again, and it earns trust only by being checked.

The honest way to think about it is the weather forecast. A good weather service does not say “it will rain tomorrow.” It says there is a 70 percent chance of rain — and you decide whether to carry the umbrella. Business prediction works the same way. The model reads the sky it can see, which is the past, and hands you a probability, not a prophecy. The decision, and the umbrella, are still yours.

A churn warning is a smoke alarm, not a fortune teller

The second big use of prediction is spotting customers who are about to leave — churn, which we met as a metric in Part 4. A model cannot see the future, but it can notice the smoke: a customer who used to buy every week now buys every month, someone who stopped opening the emails, a subscriber whose usage quietly halved. One sign means little. Together, they form a pattern that appeared before, in the records of customers who did leave.

So the model gives each customer a risk score, and the business gets a short list: these fifty people look like they are drifting away. Then humans do the human part — a friendly call, a fix for the problem the customer never reported, sometimes just an honest “we noticed, is everything okay?” Winning a customer back after they have gone is expensive. A smoke alarm is cheap. That is the whole business case: prediction does not stop the fire, it buys you time to act before there is one.

Recommendations are predictions wearing a friendly face

The third use is the one you meet every day. “People who bought this also bought...” is a prediction: given what is in your basket and what thousands of similar shoppers did, you will probably want this too. Streaming services predicting which film you will finish, shops predicting which size you will keep instead of return — same machinery, friendlier clothes. The model is not reading your mind. It is betting, politely and with decent odds, that you resemble people who behaved like you before.

Risk is prediction doing guard duty

There is a fourth use, quieter than the others: predicting what might go wrong. A bank predicting which loan applications are likely to stop being repaid. A shop's payment system flagging a purchase that does not look like its owner. An insurer estimating how risky a new driver is. It is the same pattern again — past cases, a model, a score — pointed at trouble instead of opportunity. Done well, it protects honest customers as much as the business: the flag is an invitation to check, not a verdict, and a good system treats it that way.

A prediction is a probability, not a promise

Now the honest part, because this is where the sales talk usually starts. Prediction has real limits, and a good business keeps all of them in sight:

• Habits change — last year's pattern can quietly expire when tastes, prices, or the neighbourhood change
• Shocks arrive from outside the data — a road closes, a rival opens across the street, a sudden trend sends everyone somewhere new; no past record contains next month's surprise
• Bad data in, bad guesses out — a model trained on messy or old records will predict a world that no longer exists, confidently
• The forecast itself changes behaviour — stock up because the model said “busy”, and the day looks busy partly because you stocked up; the guess bends the reality it was guessing

None of this makes prediction useless. It makes it a tool with a label on it. Use it to plan, to prepare, to notice early — not to relax. The bakery owner still walks to the window in the morning and looks at the actual sky. The model is her second opinion, never her replacement.

Takeaways:

• Prediction points the same business data at the future: sales forecasts, churn warnings, recommendations
• Every forecast follows one path — past data, a pattern, a model, a guess, then an honest check against reality
• A churn model is a smoke alarm: it buys time to act while saving the customer is still cheap
• A prediction is a probability, not a promise — habits change, shocks happen, and bad data gives confident nonsense

References and further reading

• Forecasting — Wikipedia
• Predictive modeling — Wikipedia
• Customer attrition — Wikipedia
• Recommender system — Wikipedia

That closes our Data for Business series: data is collected, charts make it visible, SQL asks it questions, and prediction points it at tomorrow — four simple ideas, and a whole field standing on them.

See you in the next post.

— Min SiThu Software Engineer & Tech Content Creator https://minsithu.org

Picture the owner of a small coffee shop at the end of the month. She wants to know three things: Did we earn more than last month? Which drink sells best? And are the regulars still coming? A few years ago she would have counted receipts by hand for an evening. Today her sales system stores every order, and each of her questions is one query away — if she asks it precisely.

Last time, in Part 3 of this series, we looked at why a good chart beats a wall of numbers. But a chart can only show what somebody first asked for, and asking is where SQL comes in.

A metric is a question somebody decided to keep asking

A database on its own is just a very tidy store room. It holds orders, customers, payments, visits — millions of small facts, sitting quietly. None of those facts mean anything until somebody asks a question about them.

A metric is what you get when a business picks one question and agrees to keep asking it, the same way, every week or every month. “How much money came in?” asked once is curiosity. Asked every month, in exactly the same way, it becomes revenue trend — and a trend is something you can act on.

I think of the database as a shopkeeper with a perfect notebook. He remembers every sale ever made, down to the minute. But he only answers the question you actually ask, in the words you actually use. Ask “how did we do?” and he stares at you. Ask “what was the total of all orders in October?” and he gives you one clean number. SQL is simply the language that shopkeeper understands. The skill is not really the language. The skill is choosing good questions.

Five numbers almost every business watches

Strip away the fancy dashboards and most businesses, big or small, keep returning to the same handful of metrics:

• Revenue — the total money that came in over a period. Not profit, not cash in the bank, just the honest total of what customers paid.
• Conversion rate — out of everyone who visited or looked, how many actually bought. A shop with 1,000 visitors and 40 buyers converts at 4 percent.
• Average order value — the typical size of one purchase. Revenue divided by the number of orders. This is why shops suggest “one more small thing” at the counter.
• Churn rate — the share of customers who quietly stopped buying or cancelled in a period. Losing customers is normal; not knowing how many is the problem.
• Retention — churn's kinder twin: the share of customers who stayed. If churn is 5 percent, retention is 95 percent, and keeping a customer is usually cheaper than finding a new one.

Notice that each one is a small, precise question with a number for an answer. That is exactly the shape of a SQL query.

One question, one query

Here is the good news: you do not need to learn all of SQL to ask business questions. A few patterns cover most of what dashboards do every day.

Suppose the shopkeeper's notebook is a table called orders, with one row per purchase: the date, the customer, and the amount. The first question — how much did we earn each month? — becomes this:

SELECT
  DATE_TRUNC('month', order_date) AS month,
  SUM(amount) AS total_revenue
FROM orders
GROUP BY DATE_TRUNC('month', order_date)
ORDER BY month;

Read it as a sentence: take the orders, group them by month, add up the amount in each group, and list the months in order. That is the whole trick. Twelve rows come back, and you are looking at a year of revenue.

The second question every owner asks is who their best customers are:

SELECT
  customer_id,
  SUM(amount) AS total_spend
FROM orders
GROUP BY customer_id
ORDER BY total_spend DESC
LIMIT 10;

Same shape, different grouping: group by customer instead of by month, sort the biggest spenders first, and keep only the top ten. Those ten people are the ones a smart owner thanks personally.

A dashboard is just saved questions with a friendly face

When you open a business dashboard and see revenue climbing on a chart, churn glowing red, and conversion sitting in a green box, it is easy to imagine some large intelligence behind it. Mostly, it is this: somebody wrote a set of queries like the two above, saved them, and set them to run again every hour or every day. The chart is the answer, drawn. The number in the green box is a query that ran a minute ago.

That is why the quality of a dashboard is really the quality of its questions. If “revenue” quietly includes cancelled orders, the prettiest chart in the world is lying politely. The database always answers the question it was asked — so the real work is asking carefully, defining each metric once, and making sure everyone in the company means the same thing by the same word.

One habit is worth stealing from good analysts: before you trust a dashboard, answer one of its questions by hand, once. Count a single day's orders yourself, slowly, receipt by receipt, and compare your number with the one on the screen. If they match, you have earned some trust. If they do not, you have found the exact place where the definition and the data disagree — and finding that on a quiet Tuesday is much better than finding it in front of your boss at the end of the quarter.

Takeaways:

• A metric is a business question asked the same way, on purpose, again and again
• Revenue, conversion rate, average order value, churn and retention cover most of what businesses watch
• Most dashboard queries are one pattern: group the rows, add something up, sort the result
• A dashboard is saved questions with a friendly face — it is only as honest as its definitions

References and further reading

• SQL — Wikipedia
• Key performance indicator — Wikipedia
• Churn rate — Wikipedia
• Dashboard (business) — Wikipedia

Next time, in the final part of this series, we stop asking what already happened and try the harder trick: guessing what happens next.

See you in the next post.

— Min SiThu Software Engineer & Tech Content Creator https://minsithu.org

Picture a market stall owner at the end of a long month, looking at a notebook page of thirty daily totals and trying to spot which days were weak. The numbers are all there. The pattern is in there too, somewhere, hiding between the lines. Now picture the same thirty numbers drawn as thirty sticks of different heights standing on one line. The weak days step forward on their own. Nothing was added to the information. It just became visible — and visible, in a busy business, usually means acted on.

Last time, we walked through the four kinds of business analytics, from “what happened?” to “what should we do?” Every one of those four ends the same way: somebody has to look at the result and understand it, quickly, often in a meeting with ten other things competing for their attention. That last step — the understanding — is the chart's job.

A chart is to a table what a map is to a list of street names. The list can be complete, accurate, and still useless at a glance. The map shows you the shape of the whole city in one look, and nobody plans a journey by reading out coordinates. Businesses run on glanceable truth the same way journeys run on maps.

Your brain compares heights faster than it compares numbers

Reading a table is serial work. You hold one number in your head, hunt for the next one, compare, hold the result, hunt again. It is slow, it is tiring, and by row fifteen the earlier numbers have quietly left your memory.

Comparing lengths is different. Your eyes judge “taller” and “shorter” almost before you start thinking — it is one of the oldest things the visual system does. This is why the slow Tuesdays in our coffee shop story were a rumour while they lived in the notebook, and became a fact the moment they were drawn. The bar for Tuesday was visibly shorter. No arithmetic required. Arguments that survive in tables tend to die in charts, because a chart lets everyone in the room see the same thing at the same second.

Each chart has one honest job

Most chart trouble comes from asking a chart to do the wrong job. The three everyday charts each have one:

• Bar charts compare things. Sales by weekday, by branch, by product — separate items standing side by side, with the differences there to be seen. If your sentence starts with “which is bigger,” you want bars.
• Line charts show change over time. A line climbing or sagging across twelve weeks tells a story about direction that no list of twelve numbers can match. If your sentence starts with “how is it moving,” you want a line.
• Pie charts show parts of one whole. Where this month's money went, for example. Use them sparingly: past five or six slices, a pie becomes soup, and two slices of similar size are nearly impossible to compare by eye. When the exact slices matter, a simple bar chart quietly does the pie's job better.

That is genuinely most of chart craft. Pick the chart whose job matches your sentence, and you are most of the way to a chart that tells the truth quickly.

One small test helps before you draw anything: say your point out loud, in one plain sentence, first. “Tuesdays are our weakest day” is a bar chart waiting to happen. “Sales have climbed since March” is a line. If you cannot say the sentence, no chart will rescue you — the problem is the question, not the drawing.

The same numbers, twice

Here are our coffee shop's average daily sales by weekday — the same exploration from Part 1 of this series, exactly as the till reported it:

Read that table honestly and feel what happens: your eyes slide, the numbers blur into each other, and if I asked you which day was weakest you would have to go hunting. Now draw seven bars, one per day, heights matching those figures. Saturday towers. Friday stands tall beside it. And Tuesday — Tuesday is visibly, stubbornly shorter than its neighbours, a gap your eye catches before your brain has finished reading the labels.

Everything this series has done since — the diagnosis, the Tuesday roster change, the afternoon deal — began at the moment that gap became impossible to unsee. The table contained the decision the whole time. Only the chart released it.

A chart can lie without changing a single number

One warning before the short version, because charts are persuasive and persuasion cuts both ways. Take those same seven bars and start the vertical axis at 250 instead of zero. Tuesday's bar now looks about a quarter of Saturday's height — a collapse, a crisis — although not one number has changed. The scissors did that, not the data. A few honest habits protect your readers, and your own decisions:

• Start bar charts at zero, always
• Label the axes and the units — a number without a unit is a rumour
• Keep the chart flat; fancy tilted effects make the nearer bars look bigger than they are
• If a chart needs a paragraph of explanation, it is the wrong chart — redraw it simpler

The short version

• Charts translate numbers into shapes, and shapes are what eyes compare fastest
• Bar compares things, line shows change over time, pie shows parts of one whole — sparingly
• If a pattern matters, draw it: patterns hide in tables and announce themselves in charts
• Start bars at zero and label everything, because a chart can lie with completely true numbers
• The best chart in business is the one a busy person understands in five seconds

Next in this series: Part 4 — the handful of numbers a small business should actually watch every week, and how to keep them together on one page.

References and further reading

• Data visualization — Wikipedia
• Bar chart — Wikipedia
• Line chart — Wikipedia
• Pie chart — Wikipedia

See you in the next post.

— Min SiThu Software Engineer & Tech Content Creator https://minsithu.org

I sat in on a sales meeting once where the monthly figure was down eight percent, and the room split instantly. "It is the weather." "It is the new competitor on the corner." "It is the price rise, I warned you." Three stories, zero evidence, and the loudest voice nearly won the day. The fix was not a smarter person in that room. The fix was asking the questions in the right order — and that order is what this article is about.

Last time, we looked at data science: the loop that turns raw business numbers into decisions. Business analytics is the part of that loop a manager meets every single day — four kinds of questions, asked in a strict order, each one harder and more valuable than the one before it.

I picture the four kinds as one car journey. Descriptive analytics is the rear-view mirror: it tells you where you have been. Diagnostic analytics is lifting the bonnet when the engine starts to rattle: it finds out why. Predictive analytics is the GPS estimating your arrival time from the road ahead. And prescriptive analytics is the GPS speaking up — "take the next left, it saves you ten minutes." Same journey, four different kinds of help.

"What happened?" is where every honest answer starts

The first kind is descriptive analytics, and it asks the plainest question in business: what happened? Our coffee shop owner from Part 1 prints her month: sales by day, by item, by hour. No explanations yet, no theories — just the facts, laid out clearly enough that two people reading them see the same month.

Most business reporting in the world is exactly this, and there is no shame in that. It is boring in the way foundations are boring. You cannot fix a month you have not measured, and you cannot argue with a number everybody watched being counted.

"Why did it happen?" is where the money hides

The second kind is diagnostic analytics: why did it happen? This is where you slice the plain facts until the difference explains itself. Our shop owner already knows Tuesdays are slow. Diagnosis asks: slow all day, or slow after three? Slow for everything, or slow for hot drinks? She compares rainy Tuesdays with dry ones and the dip survives — weather is innocent. She compares school holidays and paydays. The dip, it turns out, follows the office tower next door, which sends its staff home early every Tuesday.

That is diagnosis: not a fancier chart, just patient comparing — this group against that group, this week against that week — until one difference refuses to go away. In the sales meeting I described, the same slicing would have ended the argument in ten minutes: the fall was in one region and one product line, which happened to be exactly where the price rise had landed.

"What will happen?" is a forecast, not a fortune

The third kind is predictive analytics: what is likely to happen next? It takes the patterns found by the first two kinds and stretches them forward. If iced drinks climb every year as the weather warms, the shop can estimate next month's demand before ordering stock. If weekend peaks have held steady for a year, Saturday's roster can be planned instead of guessed.

Be honest about what a prediction is. It is an estimate with a direction, not a promise with a date. It will be wrong in detail — the question is whether it is useful in direction. A forecast that says "Tuesdays will stay quiet and Saturdays will grow" can be wrong about every single number and still save real money.

"What should we do?" is the only step that pays

The fourth kind is prescriptive analytics, and it is the only one that directly changes anything: given what happened, why it happened, and what is likely next — what should we do? It combines the forecast with the real constraints of the business: staff cost money, milk expires, the shop seats forty people and not one more.

For our shop, the prescription writes itself by now: one fewer staff member on Tuesday afternoons, a Tuesday deal timed for the office crowd before they leave early, and a smaller Monday milk order. Notice that the output is not a number. It is a recommended action — something a person can do on Monday morning.

Most companies live on the first two steps, and that is fine

Here is the honest map of the four kinds, with the shop running through all of them:

The jump from step two to step three is where the tools and the maths get serious, and plenty of businesses stall there. My honest view: most small companies get most of the available value from steps one and two done properly. A clear monthly report and one patient "why" per month will beat an expensive prediction tool fed with messy numbers, every single time. Start where you are. Climb when the lower steps feel easy.

The short version

• Business analytics asks four questions in order: what happened, why, what will happen, what should we do
• Descriptive and diagnostic work is unglamorous — and it is where most of the value sits
• A prediction is an estimate with a direction, not a promise
• A prescriptive answer you cannot act on this month is trivia with better formatting
• The order matters: never prescribe before you have diagnosed

Next in this series: why charts matter — how one good graph can show in two seconds what a hundred rows of spreadsheet can hide for an hour.

References and further reading

• Business analytics — Wikipedia
• Data analysis — Wikipedia
• Predictive analytics — Wikipedia
• Prescriptive analytics — Wikipedia

See you in the next post.

— Min SiThu Software Engineer & Tech Content Creator https://minsithu.org

A friend of mine runs a small coffee shop near a busy train station. For two years she wrote every day's takings in a paper notebook: the date, cups sold, a note about the weather, nothing more. One evening she spread three notebooks across the counter and asked me a question she could not answer from memory: "Why are my Tuesdays always slow?" She already had the data. What she did not have yet was a way to make it answer her back.

That gap — between having numbers and getting answers — is exactly where data science lives. I think of it as a doctor for a business. A doctor does not guess: she measures your temperature, runs a test, compares the result with what she knows, and only then prescribes something. A data scientist does the same thing with sales figures instead of blood pressure. Measure first, diagnose second, decide third.

Three skills share one chair, and all three matter

Data science is not one skill. It is three skills sitting in the same chair:

• Statistics — the honest counting: averages, ranges, and knowing how much trust a pattern deserves before you bet money on it
• Code — the tool that lets you handle more numbers than a notebook can hold; a spreadsheet runs out of road, code does not
• Business sense — knowing which questions are worth money, because a pattern nobody can act on is just trivia

Remove any one of the three and the chair falls over. Statistics without business sense produces correct answers to questions nobody asked. Code without statistics produces wrong answers, delivered very fast. Business sense without data produces confidence without evidence — which is a polite word for guessing. The field exists because real decisions need all three at the same time.

The work runs in a loop, not a straight line

People imagine data science as a machine: data goes in one end, answers come out the other. In real life it is a loop of five steps, and you go around it many times.

• Collect — where the numbers come from: the till, the app, the delivery log, the form customers fill in
• Clean — the unglamorous bulk of the job: fixing typos, filling gaps, removing the same customer spelled three different ways
• Explore — simple looking before clever looking: totals, averages, busiest hours. Most useful answers are hiding at this step
• Model — when simple looking is not enough, build a small prediction: next month's demand, which regulars might quietly stop coming
• Decide — a person changes something. Then the loop starts again, because the change creates fresh numbers to learn from

Notice the order. Cleaning comes before exploring, and deciding comes last. Skipping the boring middle steps is how businesses end up with beautiful models built on broken numbers.

The job title is the least important part

One more thing worth saying plainly: in a big company, this loop is split across job titles — analysts, scientists, engineers — and the titles argue with each other at conferences. In a small business, the same person often runs the whole loop before lunch. That is fine. Data science is a way of working, not a department. If you collect honestly, clean patiently, and let the numbers change one real decision, you are doing it — whether your badge says owner, manager, or the person who also fixes the coffee machine. The expensive mistake is the opposite: buying tools and titles first, and hoping the habit arrives by itself. It does not. The habit is the whole job.

One small question shows the whole loop at work

Back to the coffee shop and its slow Tuesdays. Collecting was easy: the till could export a file with the date, the items, and the total for every sale. Cleaning took longer — two days were missing entirely (the shop had closed for a holiday, so we marked them instead of inventing numbers), and one regular appeared under three spellings of his name.

Exploring is where the answer showed up. Here is the whole exploration in a few lines of Python, using a popular library called pandas:

import pandas as pd

sales = pd.read_csv("sales.csv")
sales["date"] = pd.to_datetime(sales["date"])
sales["weekday"] = sales["date"].dt.day_name()
print(sales.groupby("weekday")["total"].mean())

It loads the file, reads the dates properly, works out which weekday each sale fell on, and prints one average per weekday — and there it was: Tuesday sat about thirty percent below every other day, in plain black and white.

The small model step was really just a check: was it the rain? We compared wet Tuesdays with dry Tuesdays and the dip survived both, so weather was innocent. The decision, in the end, was human and simple: one fewer staff member on Tuesdays, and a Tuesday-only pastry deal for the morning crowd. Six weeks later Tuesday was still her quietest day — but it was no longer a day that lost money.

A model nobody acts on is just an expensive opinion

That is the part I want you to keep. The deliverable of data science is not the model, and it is not the chart. It is a sentence a person can say on Monday morning: "So we will do this." The tools will keep changing — they change every year — but the loop does not: measure honestly, clean patiently, look before you leap to the clever stuff, and finish with a decision.

The short version

• Data science = statistics + code + business sense, aimed at a decision
• The work is a loop: collect, clean, explore, model, decide — then go around again
• Cleaning takes most of the time, and exploring finds most of the answers
• You do not need big data to start — one honest, notebook-sized question is enough
• If nothing changes after the analysis, the analysis was decoration

Next in this series: business analytics — the four kinds of questions you can ask your data, from "what happened?" to "what should we do?"

References and further reading

• Data science — Wikipedia
• Statistics — Wikipedia
• Business intelligence — Wikipedia
• pandas documentation

See you in the next post.

— Min SiThu Software Engineer & Tech Content Creator https://minsithu.org

Here is a small scene from my own week, more than once. I write an important email, read it over four or five times, and feel sure it is clean. Then a friend glances at it for ten seconds and says, "You wrote the wrong date." Ten seconds. The date was wrong from the first draft, and I had read straight past it every single time, because my eyes kept seeing the date I meant to write, not the one on the screen.

Code is exactly the same, only the stakes are higher. When you write code, you know what you intended, and that knowledge blinds you. You read your intention instead of your lines. A reviewer has no intention to be blinded by — they only have the lines. That is the whole trick, and it works because of a simple fact about people: your own eyes are the worst proofreaders you own.

A reviewer is not reading to judge you, they are reading to help the code

Beginners often imagine a reviewer sitting there with a red pen, hunting for reasons to say no. In a healthy team it looks very different. The reviewer is asking a short list of honest questions about the change in front of them:

• Does this code actually do what the author says it does?
• What happens with the strange inputs — empty, huge, missing, or just plain weird?
• Can the next person read this and understand it without asking the author?
• Are the names honest? Does a thing called total contain a total?
• Is there a test that would catch this if it broke later?
• Is any part more complicated than the problem deserves?

Notice what is not on that list: "Is this how I would have written it?" Good reviewers learn to let that question go. There are ten good ways to write most code. The reviewer's job is to check that this way is correct, clear, and safe — not that it matches their personal taste.

One review, from start to finish

So how does it actually run, day to day? Simpler than most people expect:

• You finish a small piece of work and open a pull request — your change, presented to the team with a short explanation of what it does and why
• A teammate reads the change in context, looking at the new lines beside the old ones, and asks questions or leaves comments where something is unclear or risky
• You reply, adjust what needs adjusting, and push the improved version
• When the reviewer is satisfied the change is safe and readable, they approve it, and the code joins the main program

That is all. No ceremony, no exam hall. Most reviews in a working team are a handful of comments on a small change, done within the day. The habit looks almost too small to matter — until you remember it happens on every change, every week, for years. Small checks, repeated forever, are how big programs stay trustworthy.

Comments are about the code, never about the coder

This is the part nobody teaches and everybody needs. Reviews go wrong when people forget which side of the screen the comment belongs to.

If you are receiving comments, try to hold on to one thought: the reviewer is describing the code, not scoring you as a person. "This function does three things at once" is a sentence about a function. It is not a sentence about your worth. The fastest way to grow as a programmer is to treat every comment as free information — sometimes the comment is wrong, and you explain why, calmly, and that is fine too. Defending your code line by line as if it were your honour helps nobody, least of all you.

If you are giving comments, the same rule from the other side. Ask instead of ordering: "What happens here if the list is empty?" teaches more than "This is wrong." Point at the code, suggest a direction, and say plainly when something is a small taste matter rather than a real problem. And when the code is good, say that too. A review that only ever lists faults trains people to dread reviews.

Small rules that make the whole thing painless

Over time, good teams settle into a few habits that keep reviews quick and kind:

• Keep changes small. A reviewer can hold a hundred changed lines in their head. A thousand is not a review, it is a second job — and big changes hide big mistakes.
• Explain the why in the description. What problem does this solve? The reviewer should not have to guess your reasons.
• Review quickly. A teammate waiting a full day for your eyes is a teammate not working. Same day is polite; within the hour is kind.
• Let machines handle the boring fights. Formatting and spacing can be checked by tools, so save human attention for questions of logic and clarity.
• Separate real problems from small preferences, and label them honestly, so the author knows what must change and what is optional.

None of these need talent. They are manners, and manners scale.

A team that reviews well ends up with more than safer code. Knowledge spreads — nobody is the only person who understands a corner of the system. Juniors absorb the habits of seniors just by reading their comments. And the code slowly becomes something the whole team owns, instead of a pile of private territories everyone is afraid to touch.

So let people read your code. Early, often, while the mistakes are still small and cheap. The wrong date in the email costs you an apology. The wrong line in the code can cost a whole weekend. Fresh eyes are the cheapest safety tool a programmer will ever have.

Takeaways:

• A review is fresh eyes on your code before it joins the program — cheap now, expensive later
• Reviewers check correctness, edge cases, and clarity, not whether the code matches their taste
• Comments describe the code, never the coder — receive them as information, give them as questions
• Small changes, a clear why, and a fast reply keep reviews painless for everyone

References and further reading

• Code review — Wikipedia
• Peer review — Wikipedia
• Pull request — Wikipedia
• Google's Code Review Developer Guide

See you in the next post.

— Min SiThu Software Engineer & Tech Content Creator https://minsithu.org

A few years ago I watched this happen with a real student, not a model. A younger cousin of mine had a maths exam coming. He got hold of the past papers and worked through them night after night until he could answer every single question perfectly. Full marks in practice, every time. Then the exam came. The questions covered the same topics, but the numbers were different and one question was asked from the other direction. He froze. He had not learned maths. He had learned the past papers.

That is overfitting, exactly. The model is my cousin. The past papers are the training data. The real exam is the new data the model meets once training is over. A model that overfits looks brilliant in practice and disappointing in the real world.

Memorizing answers is not the same as understanding

Think about the two ways a person can prepare for a test.

One student memorizes. He reads the model answers until he can repeat them from memory. Ask him the same question in the same words and he is fast and accurate. Change one number, or ask the idea in a different order, and he has nothing to say, because nothing underneath the answers was ever built.

The other student is slower in practice. She gets some questions wrong while she is learning. But she works out why each answer is what it is, so when a new question shows up wearing different clothes, she can still find her way to it.

A machine learning model can be either of these students. Given enough freedom, a model will take the easy road, much like a person would. If you let it grow complicated enough, it stops hunting for the real pattern in the data and starts memorizing the examples one by one. It can end up storing the training data almost the way a photo stores a scene — sharp on every detail it has seen, blind to everything it has not.

Training data is the practice paper, not the exam

This is the part beginners mix up most often, so let me say it slowly.

When we train a model, we show it examples with the answers attached: this photo contains a cat, this email is spam, this house sold for this price. The model adjusts itself until it can match those answers well. That collection of examples is the training data.

But the training data is not the point of the exercise. Nobody needs a model that can label photos it has already been shown the answers for. The model earns its keep on new data — photos, emails and houses it has never seen before. The whole job is to generalize: to take a pattern learned from old examples and apply it correctly to fresh ones.

Overfitting is what happens when the model spends its effort on the wrong target. Instead of learning the pattern, it learns the examples. The noise in the data — the accidents, the rare cases, the slightly wrong labels — gets treated as though it were part of the lesson. On the training data, the score keeps climbing. On new data, it falls off a chair. A model for spotting illness in scans, for instance, might quietly memorize the marks of one hospital's machines instead of the signs of the illness, and then stumble the first week it works anywhere else.

A perfect training score should make you suspicious

In school, a hundred percent is the dream. In machine learning, a training score that looks too perfect is often the first smell of trouble. Here are the signs I watch for:

• The model scores near perfectly on the training data but clearly worse on data it has never seen
• The gap between those two scores keeps growing the longer training goes on
• The model is very complicated — a huge number of little decisions — while the training data is small
• A tiny change in the input, the kind the real pattern would shrug off, flips the answer completely

No single sign proves overfitting on its own. Together, they tell a clear story: the model knows the practice paper by heart and has stopped learning the subject.

The fixes are not clever, and that is the point

The good news is that overfitting is one of the best understood problems in machine learning, and the standard fixes are plain, unglamorous things:

• Test on data the model never trained on. Keep a separate set of examples locked away during training and judge the model on those. It is the difference between marking your own homework and sitting a real exam.
• Give it more practice papers. More training data makes memorizing harder and the real pattern easier to find, because noise stops repeating while the pattern keeps showing up.
• Make the student simpler. A smaller, less complicated model cannot memorize as much, so it is forced to learn the broad pattern instead.
• Stop training earlier. There is often a point where the model has learned the lesson and everything after that is pure memorization. Catching that point is a real skill.

Notice what is missing from that list: cleverness. You do not fix overfitting with a smarter trick. You fix it by being honest about what the model has actually learned — and the honest test is always the same. Show it something new, and watch what happens.

So the next time a model brags with a perfect score, ask the only question that matters. Not "how well did you do on the examples you studied?" but "how well do you do on the ones you have never seen?" The first number is memory. The second number is learning.

Takeaways:

• Overfitting means memorizing the training data instead of learning the pattern inside it
• Training data is practice — the model's real job starts on new, unseen data
• A near-perfect training score beside a weak test score is the classic warning sign
• More data, a simpler model, earlier stopping, and an honest test set are the standard fixes

References and further reading

• Overfitting — Wikipedia
• Training, validation, and test data sets — Wikipedia
• Generalization error — Wikipedia
• Machine learning — Wikipedia

See you in the next post.

— Min SiThu Software Engineer & Tech Content Creator https://minsithu.org

This morning, on the train, I typed a news site's address into my phone half awake, and the page was simply there before the doors closed. I have done that thousands of times. It is only when you slow the moment down that you realise how much quiet work happened between my thumb pressing Enter and the headlines appearing.

First, the browser swaps the name you typed for a number it can use

Computers on the internet are reached by numbers called IP addresses — something like 142.250.72.14. Names like the ones you type exist for humans, because nobody can remember numbers for every site they visit. So the first job is translation, and it is handled by the Domain Name System, DNS.

DNS works like the contacts book on your phone. You know a person's name, but to call them, something has to find the number saved against that name. Your browser asks a DNS server, "What number belongs to this name?" and gets the number back. To keep things fast, the answer is remembered for a while — by your browser, your operating system, and often your internet provider — so the lookup does not repeat for every visit. When a site "is down" for you but fine for a friend, a stale remembered answer is often the quiet reason.

The whole journey, in one breath

With the number found, everything else follows in a fixed order:

• Your browser connects to the computer at that number and sends a request: "Give me this page"
• That computer — the server — finds or builds the page and sends back a response
• The response arrives as separate files, not as a finished page
• Your browser reads the files, asks for any missing pieces, and builds what you see

Every section below is just one of those steps, slowed down.

Then the browser knocks on the right computer's door

The computer holding the site is called a server, which is a grand name for an ordinary machine with one special habit: it sits awake all day, waiting to be asked for things. This two-sided arrangement — your browser asks, the server answers — is the client–server model, and nearly everything on the web is built on it.

Your browser's request is a short, plain-text message. It says which page it wants (the path after the site's name, like /sports or /weather), what kind of browser it is, and sometimes proof of who you are, so the site can show your account instead of a stranger's. The server reads the request, gathers what was asked for — often pulling fresh numbers out of a database — and sends a response back with a small status line attached: 200 means "here it is", and 404 means "that page does not exist", a number you have surely met before.

The answer that comes back is ingredients, not a finished page

What the server sends first is usually an HTML file. HTML is the structure: the headings, the paragraphs, the links, the places where images will sit. On its own it looks plain and unfinished. Two more kinds of files give it a finished face:

• CSS files describe how everything should look — colours, sizes, spacing, layout
• JavaScript files describe behaviour — what happens when you tap, scroll, search or type

The HTML points to these files, so reading it often triggers a second round of requests: the styles, the scripts, the photos, the fonts. A single page you open may quietly cause fifty small deliveries before it looks complete. This is also why a page sometimes shows its words first and dresses itself a moment later — the structure arrived before the decoration.

The little lock means the conversation is private

Look at the small lock icon beside the address. It means the site uses HTTPS, and your conversation with the server is encrypted — scrambled in a way that only your browser and that server can unscramble. On the journey between you and the server, your request passes through many hands: your router, your provider, networks in other countries. With plain HTTP, any of those hands could read along, or even change the page before it reached you.

HTTPS also answers a second question: is this server really the site it claims to be? Before trusting it, your browser checks a certificate — a digital ID card issued by a trusted authority — and it warns you loudly if the card looks wrong. That warning is one of the few browser messages you should never click past.

Finally, the browser builds the page on your screen

Receiving the files is not the end. Your browser now does the assembly work, in an order that is roughly this:

• It reads the HTML and builds a map of the page's structure in memory
• It applies the CSS, working out exactly where every box sits and what it looks like
• It runs the JavaScript, which may move things, load more content, or watch for your taps
• It paints the result onto your screen, pixel by pixel — and repaints whenever anything changes

This building work happens on your device, using your battery and your processor, which is why the same heavy page feels instant on a new laptop and sluggish on an old phone. The server sent the same ingredients to both. The assembly is local.

The short version

• Your browser cannot visit a name — DNS first turns the name into a number, like a contacts book
• A server is just a computer that waits to be asked; your browser asks, it answers
• The answer arrives as ingredients: HTML for structure, CSS for looks, JavaScript for behaviour
• The lock icon means HTTPS: the conversation is encrypted, and the server's identity is checked
• The finished page is built on your own device — which is why old phones struggle with heavy pages
• All of it, lookup to painting, normally takes less than a second

References and further reading

• Domain Name System — Wikipedia
• Client–server model — Wikipedia
• HTTPS — Wikipedia
• An overview of HTTP — MDN Web Docs

See you in the next post.

— Min SiThu Software Engineer & Tech Content Creator https://minsithu.org

You already know the problem it solves, even if you have never written code. Think of the folder before a school or office deadline: report.docx, report_final.docx, report_final2.docx, report_REALLY_final.docx, and one mysterious report_final_NEW.docx that nobody remembers creating. Five files, one document, and no honest way to say which changes are in which copy. Programmers lived exactly like that for years. Version control is what they built to escape it.

The easiest way to feel it is to think about save points in a video game. Before a hard fight, you save. If the fight goes badly, you do not restart the whole game — you reload the save and try a different approach. The disaster is gone, and so is nothing else. A commit in version control is exactly that save point, and the whole of Git is built from this one idea, repeated and shared.

A commit is a save point, and the note on it matters

When you commit, you are telling the system: remember everything exactly as it is right now. Git stores a snapshot of your files, your name, the time, and a short message you write — something like "Add login form" or "Fix total on receipt". That message looks like a small thing. Six months later, when you are staring at a strange line of code at midnight, it is the only explanation you will get, so good messages are a kindness to your future self.

Two habits make commits useful instead of decorative. First, commit often — small saves, one clear job each, rather than one giant save at the end of the week. Small commits are easy to understand and easy to undo. Second, commit when something works, even something small. A save point you made while the code was healthy is worth ten you made in a panic.

A branch lets you try the dangerous idea safely

Sooner or later you will want to try something risky: a new design, a big cleanup, an experiment that might fail. Doing it on your only copy is how working software gets broken. A branch solves this by giving you a parallel line of save points. Your main line — usually called main — keeps the version that works. The branch is where the experiment lives, free to break without hurting anyone.

If the experiment succeeds, you bring it back. If it fails, you delete the branch and nothing happened. This one idea changes how people work: trying things becomes cheap, so people try more things, and the software gets better faster.

Merging is where two lines of work become one again

Bringing a branch back into main is called merging. When the two lines touched different files, or different parts of the same file, Git combines them quietly and you barely notice. When both lines changed the same lines in different ways, Git stops and asks you to choose. That pause is called a merge conflict, and beginners fear it far more than it deserves. It is not an error. It is Git honestly saying: "Two people wanted different things here — a human should decide."

The fix is calm work: open the file, look at both versions, keep the right combination, and commit the result. The first conflict feels like a wall. The fifth one feels like paperwork.

With a real history, undoing a mistake stops being scary

Without version control, a mistake in code is a small disaster: you changed twelve files yesterday, something is broken today, and you cannot remember half of what you touched. With a history, the questions become simple. What changed between the working version and now? Show me just that difference. Take this one file back to how it was on Tuesday. Undo this one commit and nothing else.

You can even ask Git to hunt for the exact commit that introduced a bug, testing old save points one by one until the guilty change stands alone. None of this is magic. It is just what happens when every state of your work is kept, labelled, and reachable.

Teams need it because shared folders do not scale

Everything above matters for one person. For a team, it is the difference between working and colliding. Imagine five people editing the same file through a shared folder, or emailing copies of a zip file named final_v2_REAL.zip around: two people fix the same bug in different ways, one person overwrites another person's afternoon, and nobody can prove which copy is current. With Git, everyone works on their own full copy of the project — history included — commits their save points, and shares them through a common place such as GitHub. Changes arrive as commits with names and reasons attached, not as anonymous files.

It was not always Git. Older tools like Apache Subversion kept one central copy that everyone checked work in and out of. Git, created by Linus Torvalds in 2005 to manage the Linux kernel, made every copy complete, so you can work offline on a train and still have the whole history with you. That freedom is a big reason the whole industry settled on it.

You only need a handful of commands to start

Git has many commands, but daily life uses very few:

• git init or git clone — start a project, or copy an existing one
• git add and git commit — choose changes, then save the point with a message
• git status and git log — ask "where am I?" and "what happened here?"
• git branch and git switch — make a side line and move onto it
• git merge — bring a finished branch back
• git push and git pull — send your save points to the shared place, and receive everyone else's

Learn those, and you understand the shape of the whole tool. The rest is detail you can look up when you need it.

The short version

• Version control is a memory for your project: every change, recorded and reachable
• A commit is a save point — small, often, and with an honest message
• Branches make experiments cheap, because the working version stays untouched
• A merge conflict is a question, not a failure
• History turns "who broke this and when?" from an argument into a lookup
• Git won because every copy is complete — the whole history travels with you

References and further reading

• Version control — Wikipedia
• Git — Wikipedia
• Apache Subversion — Wikipedia
• Pro Git — the official Git book, free to read online

See you in the next post.

— Min SiThu Software Engineer & Tech Content Creator https://minsithu.org

A friend of mine stood in a bookshop last month with a programming book in each hand, looking at them the way you look at two phones when you can only afford one. He sent me a photo and a single question: "Which one first?" It is a better question than it sounds: with these five, the order matters almost as much as the books themselves.

Here is how I think about the shelf. A good set of programming books is like a small team of coaches, each hired for one job. You would not ask a swimming coach to fix your diet. Do not ask a design book to teach you daily habits, or a habits book to teach you deep theory. Below is what each book actually teaches, who it is for, and how hard it honestly is.

The Pragmatic Programmer teaches you how to think like a professional

Cover © Addison-Wesley — via Open Library

David Thomas and Andrew Hunt wrote this as a set of short, practical tips from real work; the 20th Anniversary Edition (2019) refreshed it for modern tools. Almost none of it is tied to one language. It talks about taking responsibility for your work, keeping knowledge in plain text, not repeating yourself, building small "tracer bullet" versions to learn early, and making code easy to change later.

Who it is for: everyone, but especially people in their first few years of programming. Honest difficulty: the easiest book on this list. The sections are short, the tone is friendly, and you can read it in any order. If you only buy one book this year, this is the safest one to pick.

Clean Code teaches you that code is read far more often than it is written

Cover © Prentice Hall — via Open Library

Robert C. Martin's argument is simple: you write a line of code once, but people read it ten times — during reviews, during bug hunts, during the feature change six months later. So it is about meaningful names, small functions that do one thing, honest formatting, and treating comments as a last resort rather than decoration. The examples are in Java, but the lessons travel to almost any language.

Who it is for: anyone writing code that other people (including future you) must maintain. Honest difficulty: easy to read, harder to live by. Some of its rules are debated — not everyone agrees functions should be quite that small — so read it as strong advice to think with, not as law.

Code Complete teaches you that building software is a craft with checklists

Cover © Microsoft Press — via Open Library

Steve McConnell's book is the heavy one, literally: the second edition runs to around 900 pages. It covers the "construction" part of programming — designing routines, naming variables, handling loops and conditions, defensive programming, debugging, and refactoring. It is full of small, researched, practical rules.

Who it is for: people building real projects who want a reference beside the keyboard. Honest difficulty: long and dense. Almost nobody reads it cover to cover in one go, and you are not supposed to. Read a chapter when you meet the problem it solves, and it will earn its shelf space for years.

Design Patterns teaches you the names for shapes you keep rebuilding

Cover © Addison-Wesley — via Open Library

Written by Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides — the "Gang of Four" — this 1994 book describes 23 reusable solutions to design problems that show up again and again. Patterns like Observer, Factory and Strategy each get a name, a shape, and a discussion of trade-offs.

The real gift is vocabulary. Once a team shares these names, "let us use an Observer here" replaces a ten-minute whiteboard sketch. Who it is for: programmers with some object-oriented experience who have started to feel their designs getting tangled. Honest difficulty: dry, and written in an older style with C++ and Smalltalk examples. Read it too early and it does harm — beginners tend to force patterns everywhere. Read it after messy design has hurt you once, and it reads like answers.

Structure and Interpretation of Computer Programs teaches you what a program really is

Cover © MIT Press — via Open Library

This is the famous MIT textbook by Harold Abelson and Gerald Jay Sussman, and it is the deep end of this list. Working in Scheme, a small teaching language, it builds up ideas about abstraction and recursion step by step — and near the end, you build an interpreter, a program that runs other programs. Many readers say that is the moment programming finally "clicked" for them.

Who it is for: patient readers who want understanding, not a quick job skill. Honest difficulty: the hardest book here, with mathematical exercises that demand pen and paper. The good news is that it is free to read online, legally, so the only cost is your time and stubbornness. Go slowly, do the exercises, and do not go alone if you can find a study partner.

Read them in this order, not the order I listed them

If I hand these to a beginner friend, the order is deliberate:

• The Pragmatic Programmer first, because habits and attitude help with every language you will touch
• Clean Code second, while your own messy code is still fresh enough to recognise in its examples
• Code Complete alongside your real work, one chapter at a time, as a reference rather than a novel
• Design Patterns after you have written object-oriented code long enough to feel the problems it names
• SICP last and slowest, when you are curious about what sits underneath everything else

The pattern to notice: thinking first, daily craft second, depth last. Each book makes the next one easier to understand.

The short version

• Every book on this list has exactly one job — pick the book that matches the problem you have right now
• Habits beat theory at the start, which is why The Pragmatic Programmer goes first
• Clean Code and Code Complete are about the code you write every day, not about cleverness
• Design Patterns is a vocabulary book, and vocabulary only helps once you have something to say
• SICP is the deep end: slow, hard, free to read online, and worth it when you are ready
• Order beats selection — the right book at the wrong time still feels like the wrong book

References and further reading

• The Pragmatic Programmer — Wikipedia
• Clean Code — Wikipedia
• Code Complete — Wikipedia
• Design Patterns — Wikipedia
• Structure and Interpretation of Computer Programs — Wikipedia
• Book cover images: Open Library — credit lines under each cover

See you in the next post.

— Min SiThu Software Engineer & Tech Content Creator https://minsithu.org