Stage 1What Programming Is, and Who This Guide Is For

A program is a list of instructions precise enough for a machine to follow without understanding any of them. That is the whole trick and the whole difficulty. A person told to "add up this month's expenses" will skip the blank rows and ask about the refund; a computer will do exactly what it was told, very quickly, and be wrong in exactly the ways the instructions were wrong.

Programming is the craft of writing those instructions. In India it employs millions of people. As a hobby it is something smaller and, for many, more satisfying: building a tool because you want it, the way you want it, for nobody's approval but your own.

Building for yourself

The hobby programmer's projects are rarely grand. A script that renames three years of phone photos by the date they were taken. A spreadsheet of the family's electricity bills, turned into a chart of which months cost the most. A small web page listing the books you have lent out and to whom. A game your nephew can beat. A soil-moisture sensor on the balcony that tells you, politely, that the tulsi needs water.

None of these would survive a meeting in a software company, and that is their charm. You are the customer, the designer, the programmer and the tester. When the tool annoys you, you can change it tonight.

The first time a script does in a blink what used to take you a Sunday afternoon, the hobby usually has you for life.

What programming is not

It is not mathematics; most hobby code needs no more arithmetic than a household budget. It is not typing speed or memorising, since working programmers look things up constantly. What it does need is patience with detail, and the willingness to be wrong many times a day without taking it personally.

Who this guide is for, and how to use it

The complete beginner should read Part I in order. The practising hobbyist will find the tools, testing, security and preservation stages most useful. The serious specialist will want the boxes labelled "For the Programmer". The general reader who likes a good story may prefer to start with Part II, which tells how computing arrived in India, grew into an industry, and learned to write in Indian scripts.

Part I runs from what a computer does to choosing a language, the fundamentals, tools, debugging, projects, testing, security, open source and hardware, and ends with two stages on storage and preservation (Stages 15 and 16): keeping code, data and equipment alive for years in an Indian climate. The short code listings, mostly Python, are each explained in the text and short enough to type in by hand, which is still the best way to learn from them.

Stage 2How a Computer Runs a Program

You can write useful programs without knowing how a computer works inside, just as you can cook without knowing the chemistry of the Maillard reaction. But a rough picture helps you guess why things go wrong, and it makes error messages less mysterious. Here is the outline.

The parts that matter

A computer has a processor (the CPU), which carries out very simple instructions, such as fetching two numbers, adding them and storing the result, billions of times a second. It has memory (RAM), which is fast, holds the running program and its data, and forgets everything when the power goes. It has storage, a solid-state drive or hard disk, which is slower but keeps your files, including your source code, when the machine is off. And it has an operating system, such as Windows, macOS, Linux or Android, which shares the processor and memory among programs and gives each a safe way to reach files, the screen and the network.

Everything in memory and storage is a pattern of bits, each 0 or 1, grouped into bytes of eight. Whether a pattern means a letter, part of a photograph or an instruction depends entirely on how a program reads it.

From your text to the processor

The processor understands only its own machine code, a set of numbered instructions specific to its family, such as x86 in most laptops or Arm in most phones. Nobody writes machine code by hand any more. You write source code in a language designed for people, and a program translates it.

There are two broad ways of translating. A compiler translates the whole program into machine code before it runs, producing a file you can run again and again. C, C++, Go and Rust usually work this way. An interpreter reads your program and carries it out as it goes. Python and JavaScript are usually described as interpreted, although in practice both first convert your code into an intermediate form, and modern JavaScript engines compile the busiest parts to machine code while the program runs.

You can watch Python do this. The listing below defines a tiny function and then asks the dis module, which comes with Python, to show the intermediate instructions (called bytecode) that Python actually runs.

import dis

def with_gst(price):
    return price * 1.18

print(with_gst(500))
dis.dis(with_gst)

On Python 3.13 the first line printed is 590.0, and the rest is a short list of instructions with names like LOAD_FAST (fetch the value of price), LOAD_CONST (fetch the number 1.18), BINARY_OP (multiply them) and RETURN_VALUE. The exact names and layout change between Python versions, which is itself a small lesson: bytecode is an internal detail, and your source code is the part meant to last.

Why this helps

When a program says it has run out of memory, you now know it means RAM, not your disk. When a script that works on your laptop fails on a Raspberry Pi, a different processor family or operating system is a reasonable first suspect. When a file of Hindi text turns into rubbish, you know that the bytes are probably fine and the program is reading them with the wrong rules (see Stage 20). And when a sum comes out slightly wrong, the box below explains why.

Stage 3Choosing a First Language

People argue about first languages with the energy other hobbies reserve for cricket selection. The honest position is that your first language matters less than you fear. The ideas in Stages 4 and 5 (values, conditions, loops, functions, collections) exist in almost every language, and your second language will take a fraction of the time your first did. Choose one that suits what you want to build, and then stop choosing.

Python

Python is the most common recommendation for adult beginners, and for good reasons. Its syntax is spare and readable. It uses indentation to show structure, so well-formatted code and working code are the same thing. It comes with a large standard library for files, dates, spreadsheets in CSV form, web requests and much more, and it has a vast collection of add-on packages for data analysis, automation, science and small web applications. It is also what India's CBSE senior-secondary computer science course now teaches (see Stage 18), so help is easy to find.

Its weaknesses are real but rarely matter for a hobbyist. It is slower than compiled languages for heavy computation, although the libraries that do heavy lifting are mostly written in faster languages underneath. It does not run inside a web browser without extra work, and it is not the natural choice for phone apps.

JavaScript

JavaScript is the language of the web browser. Every laptop and phone already has an environment that runs it, and a web page you build can be opened by anyone you send it to. If what excites you is things you can see and click, JavaScript gets you there fastest. With Node.js it also runs outside the browser.

It carries more historical oddities than Python, and the web ecosystem around it changes quickly, which can make tutorials go stale within a couple of years. Beginners are best served by learning plain JavaScript with plain HTML and CSS before reaching for any framework.

Here is the same small task in both. Each greets three people by name.

for name in ["Asha", "Ravi", "Meera"]:
    print("Hello,", name)

for (const name of ["Asha", "Ravi", "Meera"]) {
  console.log("Hello,", name);
}

The Python version marks the body of the loop by indenting it. The JavaScript version uses curly braces and ends statements with semicolons, and indents only for the reader's benefit. print and console.log do the same job. Neither is better; they are different spellings of the same idea.

The others

Scratch, from MIT, lets children and adults snap blocks together instead of typing, and it teaches real ideas about loops and events. The C language is small and close to the hardware, which makes it excellent for understanding memory and for microcontrollers, and unforgiving for a first project. Java and C# are widely used in industry and in some school syllabi. Go and Rust are modern compiled languages; Rust in particular is admired and demanding. A spreadsheet formula is programming too, and many people's first real program is a formula that got out of hand.

Stage 4Fundamentals: Values, Variables, Conditions and Loops

Four ideas carry most of the weight in every program you will write. They are simple to state and take a while to feel natural, so read this stage with Python open and type everything.

Values and types

A value is a piece of data: the number 42, the text "Chennai", the truth value True. Every value has a type, which decides what you can do with it. You can multiply two numbers. You can join two strings (the programmer's word for text). You cannot sensibly add the number 5 to the text "5", and Python will refuse to guess what you meant; Stage 7 shows the error it gives.

The common types in Python are int for whole numbers, float for numbers with a fractional part, str for text, bool for True and False, and None, which means "nothing here yet".

Variables

A variable is a name attached to a value, so that you can use it later. wet_days = 0 attaches the name wet_days to the value 0. Choose names that say what the value means, in words: rainfall_mm is better than r, and far better than data2. You are writing for a reader, and in six months that reader will be you, with no memory of what data2 was.

Conditions

A condition lets a program choose. if runs a block of code only when something is true. elif (short for "else if") tries another test, and else catches everything left over. Comparisons use == for "is equal to" (a single = means assignment), != for "is not equal to", and the familiar <, >, <= and >=.

Loops

A loop repeats. A for loop takes each item of a collection in turn. A while loop keeps going as long as a condition stays true, which makes it useful and also the easiest way to write a program that never stops. If that happens, pressing Ctrl and C in the terminal will usually interrupt it.

The listing below uses all four ideas. It counts the wet days in a week of rainfall readings.

city = "Chennai"
rainfall_mm = [12, 0, 45, 80, 3, 0, 110]
wet_days = 0

for mm in rainfall_mm:
    if mm >= 10:
        wet_days = wet_days + 1
    elif mm == 0:
        print("A dry day")

print(city, "had", wet_days, "wet days this week")

The first three lines create a string, a list of seven integers and a counter at zero. The for line takes each reading in turn as mm. The indented if adds one to the counter for readings of at least 10 millimetres; otherwise the elif prints a note for a completely dry day, and a reading of 3 matches neither. After two lines saying A dry day, the last line prints Chennai had 4 wet days this week.

The indentation carries the meaning. The if is indented once, so it belongs to the loop; the counter line twice, so it belongs to the if; the final print not at all, so it runs once, after the loop. Indent that line four spaces and it prints seven times.

Stage 5Fundamentals: Functions, Collections and Files

The ideas in Stage 4 are enough to write a program. The ideas in this stage are what let you write one you can still understand when it has grown past a single screen, and one that remembers anything after it stops.

Functions

A function is a named piece of code that takes some inputs, does one job, and hands back a result. You define it once with def and use it as often as you like. The inputs are called parameters, and the result is the return value. A function that never reaches a return line gives back None.

Functions give a piece of logic a name, so that totals_by_category("expenses.csv") explains itself; they let you reuse it, so a mistake is fixed in one place instead of four; and they give you something small enough to test on its own (see Stage 10). If you cannot describe a function in one short sentence without the word "and", it is probably two functions.

Collections

Real data comes in groups, and Python has four everyday ways of holding a group.

A list keeps items in order, and you can change it. Items are numbered from zero, so readings[0] is the first and readings[-1] is the last. Use a list when order matters.

A dictionary maps keys to values, like the index at the back of a book. prices["tea"] looks up the price of tea. Use a dictionary when you will look things up by name.

A tuple is a fixed, ordered group, such as a latitude and longitude that belong together. A set holds items with no duplicates and no order, and answers "is this in here?" very quickly.

Files

A program forgets everything when it ends. Files are how it remembers, and how it reads what other programs have written. The most useful file for a hobbyist is often a CSV file (comma-separated values), which every spreadsheet program can export. Here are the first lines of one, exported from a household expenses sheet.

date,category,amount
2026-08-01,groceries,1240.50
2026-08-02,travel,180
2026-08-02,groceries,310
2026-08-05,books,899

The first row names the columns and each later row is one expense. The listing below reads that file and adds up the spending in each category, combining a function, a dictionary, a loop and a file.

import csv

def totals_by_category(path):
    totals = {}
    with open(path, newline="", encoding="utf-8") as f:
        for row in csv.DictReader(f):
            category = row["category"]
            amount = float(row["amount"])
            totals[category] = totals.get(category, 0) + amount
    return totals

for category, amount in totals_by_category("expenses.csv").items():
    print(f"{category:<10} Rs {amount:>9,.2f}")

The function opens the file inside a with block, which closes it again automatically, even if something goes wrong. The encoding="utf-8" part matters: on Windows, Python's default encoding may not be UTF-8, and a file containing Hindi, Tamil or the rupee sign can then fail to read (see Stage 20). csv.DictReader turns each row into a dictionary keyed by the column names. Each amount is converted from text with float, because everything read from a file arrives as text, and totals.get(category, 0) fetches the running total for that category, or 0 the first time it appears, before the new amount is added.

The last two lines print one row per category. The odd-looking codes inside the braces are formatting instructions: <10 pads the name to ten characters, and >9,.2f right-aligns the amount in nine characters, with commas and two decimal places. The output is groceries Rs 1,550.50, then the travel and books totals below it.

Note that the commas fall every three digits, in the Western style. A lakh prints as 150,000, not 1,50,000. Writing a small function that formats amounts the Indian way is an excellent second exercise.

Stage 6Tools: an Editor, the Terminal and Git

A carpenter's first tools are a saw, a square and a pencil. A programmer's are an editor, a terminal and a version-control system. All three are free, and learning them early saves more time than any other investment in this guide.

The editor

Code is plain text, written in a text editor, never a word processor, which adds hidden formatting and turns straight quotation marks into curly ones that break code. Good free choices are IDLE, which comes with Python; Thonny, a simple editor for learning Python that can also talk to microcontroller boards (see Stage 13); and Visual Studio Code, a widely used free editor from Microsoft. Turn on syntax highlighting, automatic indentation and saving as UTF-8, and for Python set Tab to insert four spaces, as Python's style guide, PEP 8, recommends.

The terminal

The terminal, also called the command line, shell or console, is a window where you type commands instead of clicking. On Windows it is usually PowerShell inside the Windows Terminal app; on macOS it is Terminal; on Linux it is whatever your desktop provides.

Many programming tools have no other interface, and the terminal is where your scripts print their output and errors. A handful of commands cover most needs: cd to change folder, ls or dir to list files, python totals.py to run a script, the up arrow to recall a command, and Tab to complete a file name. The terminal always has a current working directory, and a relative file name such as expenses.csv is looked up there, not beside the script, which is the commonest reason a beginner's script cannot find its file.

Files deleted from the terminal usually skip the recycle bin and are gone for good. And never paste in a command you do not understand from a web page or a chat message, least of all one that downloads something and runs it (see Stage 11).

Version control with Git

Git records snapshots of a project folder. Each snapshot, a commit, stores every tracked file with a message, an author and a date, so you can see what changed, return to a version that worked, and try a risky idea on a separate branch. Git was created by Linus Torvalds in 2005 for the Linux kernel and is now the standard almost everywhere. It runs on your own machine, offline; hosting services such as GitHub, GitLab and Codeberg keep copies of repositories and add issue trackers and wikis. Git and GitHub are not the same thing, and Stage 15 explains why that matters.

The commands below set Git up once, create a project, and make its first commit.

git config --global user.name "Asha Rao"
git config --global user.email "asha@example.com"
git init expense-tracker
cd expense-tracker
git add totals.py expenses.csv
git commit -m "Add monthly totals by category"
git log --oneline

The two config lines tell Git the name and email to record on your commits; you do this once per computer. git init creates the folder and, inside it, a hidden .git folder where the whole history will live. After copying your two files into the folder, git add chooses which changes go into the next snapshot, and git commit takes it, with a message. git log --oneline then lists the history, newest first, one commit per line, each with a short identifying code.

Commit small and often, each time something works. Write messages that say what the change does, so the history reads like a diary. Run git status constantly; it is harmless and it always tells you where you stand.

Stage 7Reading Documentation and Error Messages

A programmer spends more time reading than writing, mostly documentation and error messages. Both are dense, and both reward slow reading far more than skimming. Often the difference between a beginner and an experienced hobbyist is simply that the experienced one reads the whole message before searching for it.

Reading documentation

Documentation comes in kinds. A tutorial walks you through a first project; a how-to guide is a recipe for one task; a reference describes every function and option tersely; an explanation says why things are designed as they are. Most frustration comes from reading the wrong kind: reference pages will not teach you a library, and a tutorial will not list every option.

A reference entry begins with a signature, such as str.split(sep=None, maxsplit=-1), giving the name, the parameters and, after the = signs, their defaults. Below it you will find what the function returns, what errors it raises, and version notes such as "Changed in version 3.9"; check those against python --version. You can also ask Python itself: help(str.split) prints the same documentation in the interactive prompt.

Reading an error message

In Stage 5 the expenses listing converted each amount with float. Here is what happens without that conversion.

import csv

total = 0
with open("expenses.csv", newline="", encoding="utf-8") as f:
    for row in csv.DictReader(f):
        total = total + row["amount"]

print(total)

Python stops with this message, called a traceback (the path to the file is shortened here).

Traceback (most recent call last):
  File "expenses.py", line 6, in <module>
    total = total + row["amount"]
            ~~~~~~^~~~~~~~~~~~~~~
TypeError: unsupported operand type(s) for +: 'int' and 'str'

Read it from the bottom up. The last line names the kind of error, TypeError, and says precisely what went wrong: something tried to use + on an integer and a string. The lines above it say where: file expenses.py, line 6, at the top level of the script rather than inside a function (which is what the word "module" means there). Since Python 3.11 the markers underneath point at the exact part of the line involved, with the caret under the +.

Put together: total started as the integer 0, and row["amount"] is text, because everything read from a file arrives as text. The message did not merely report a failure; it explained it. In a longer program the traceback lists several files, the most recent call last. Look for the lowest line that names a file you wrote, because that is usually where the fix belongs.

Searching well

When you search, use the error's last line without your own file names and values, and prefer the official documentation and the project's issue tracker; answers on question-and-answer sites can be a decade old. AI chat assistants can explain an error clearly, and can also describe functions that do not exist with complete confidence. Test what they suggest, and never paste in passwords, keys or other people's personal data.

Stage 8Debugging as a Method

A bug is any difference between what a program does and what you meant it to do. Debugging is finding and removing one, and it is not a talent some people are born with. It is a method, and it looks a great deal like the scientific method: observe, guess, test the guess, repeat.

The alternative, which every beginner tries, is changing things at random until the symptom goes away. It sometimes works. It also tends to bury the real fault under a second one.

The method

1. Reproduce it on demand, with the smallest input that still shows it.
2. Read the evidence: the error, the output, and what changed since it last worked, which git diff shows exactly.
3. Form one hypothesis specific enough to be proved wrong, such as "the list is shorter than I think".
4. Test it with a printed value, a smaller case or a debugger.
5. Fix one thing, then confirm the bug has gone and nothing else broke.
6. Write it down in the commit message.

Looking inside the program

The humblest debugging tool is also the most used: printing a value to see what it really is. The function below is meant to average the last few days of temperature readings from a balcony sensor. It returns nonsense.

def average_of_last(readings, n):
    recent = readings[-n:]
    print("DEBUG", len(readings), n, recent)   # remove when fixed
    return sum(recent) / n

print(average_of_last([30, 32, 31], 7))

The slice readings[-n:] takes the last n items, and the labelled print line was added while hunting the bug. Running the script prints DEBUG 3 7 [30, 32, 31] and then an average of about 13.3 degrees, for three readings all above 30. The debug line shows the cause at once: the sensor has sent only three readings, Python happily returns all three when asked for the last seven, and the function divides their sum by 7. The fix is to divide by len(recent). A second, subtler fault is still hiding here; Stage 10 shows how a test finds it.

For anything more tangled, use a debugger, which pauses a running program so you can inspect it. Putting the line breakpoint() anywhere in Python code stops the program there and opens Python's built-in debugger, called pdb. Editors such as Thonny and Visual Studio Code offer the same thing visually: click in the margin to set a breakpoint, run, and watch each variable change as you step through line by line.

Narrowing it down

When you cannot see where a bug lives, cut the problem in half: give the program half the data, or skip half the steps, and see which half still fails. Git does this across history with git bisect, which homes in on the commit that introduced a fault.

Check the assumptions that feel too obvious to check. Is the file you are editing the one you are running? Is the script using the Python you think? (import sys and print(sys.executable) will tell you.) Did you save? Explain the code aloud, line by line, to someone or something; the practice is called rubber duck debugging, after a story in The Pragmatic Programmer about a programmer who explained his code to a toy duck. And when you are stuck, stop. A walk or a night's sleep often makes the bug embarrassingly plain.

Stage 9Projects That Teach

Tutorials teach syntax; projects teach programming. Leave a tutorial's well-lit path and you meet the questions it never asked: how to turn a vague wish into steps, what to do when the data is messy, and when a thing is finished. A good first project is small, personal and finishable in a weekend, and solves a problem you actually have, because only wanting the result keeps you going when it gets hard.

Automate something in your own life

Almost everyone has a folder that is a mess. The listing below tidies a Downloads folder by moving each file into a subfolder named after its extension, so that PDFs go into pdf and photographs into jpg.

from pathlib import Path

DRY_RUN = True   # set to False only after reading the output
downloads = Path.home() / "Downloads"

for item in sorted(downloads.iterdir()):
    if not item.is_file() or not item.suffix:
        continue
    folder = downloads / item.suffix.lower().lstrip(".")
    target = folder / item.name
    if target.exists():
        print("skip (already there):", item.name)
    elif DRY_RUN:
        print("would move", item.name, "to", folder.name)
    else:
        folder.mkdir(exist_ok=True)
        item.rename(target)

pathlib is Python's module for file paths, and Path.home() / "Downloads" builds the path to your Downloads folder on Windows, macOS or Linux alike. The loop visits every item in alphabetical order. The continue line skips folders and files with no extension. For each file, the subfolder name is its extension in lower case, without the dot, so Ticket.PDF is headed for pdf. If a file of that name is already there, the script says so and leaves both alone rather than overwriting one.

The most important line is the second. While DRY_RUN is True, the script only prints what it would do. Read that list carefully, and only then change the value to False and run it for real. Any script that moves, renames or deletes your files deserves this safety catch, and a backup taken first (see Stage 15).

A small web page

A web page is three plain text files: HTML for the content, CSS for how it looks, and JavaScript for anything that responds to a click. A file on your own disk opens in any browser, so you need no server to start. A page listing books you have lent, with a button that hides the returned ones, teaches all three in an evening. If you later publish it, remember that a public page is public: no friends' names, numbers or addresses.

A game

Games teach state (what is true right now), randomness and user input. Start with a number-guessing game in the terminal using Python's random module, then noughts and crosses, then something that moves, with a library such as Pygame or the browser's canvas. Keep the first game's graphics to rectangles.

Data from a spreadsheet

If you keep any records at all, such as electricity bills, fuel, a cricket club's scores or a garden's harvest, there is a data project in them. Export the sheet as CSV and use the approach in Stage 5 to answer a question the spreadsheet makes awkward: which month cost the most, how units used relate to the amount billed, or whether the tariff changed. When you want charts, the widely used libraries matplotlib (for plotting) and pandas (for tables of data) are the usual next step.

Keeping a project finishable

Write one paragraph describing version one before you start, and a list headed "later" where every new idea goes instead of into the code. When version one works, commit it, write a short README saying what it does and how to run it, and use it for a week before adding anything.

Stage 10Testing Your Own Code

Testing sounds like a job for software companies. For a hobbyist it is simpler: a test is a small piece of code that checks another piece does what you meant, and keeps checking every time you change anything. Its real value is memory. Six months from now you will have forgotten exactly what "working" meant; your tests will not.

The idea, with pytest

Python has a built-in testing module, but most hobbyists use pytest, a popular free package that keeps tests short. Install it into your project's environment with python -m pip install pytest. Test files are named test_something.py, and inside them each test is a function whose name begins with test_ and which uses Python's plain assert statement.

Here is the corrected temperature function from Stage 8, saved as readings.py, with one more improvement that the tests below will explain.

def average_of_last(readings, n):
    if n < 1:
        raise ValueError("n must be at least 1")
    recent = readings[-n:]
    return sum(recent) / len(recent)

And here are three tests for it, saved beside it as test_readings.py.

import pytest
from readings import average_of_last

def test_full_week():
    assert average_of_last([30, 31, 32, 33, 34, 35, 36], 7) == 33

def test_fewer_readings_than_days():
    assert average_of_last([30, 32, 31], 7) == 31

def test_zero_days_is_refused():
    with pytest.raises(ValueError):
        average_of_last([30, 32, 31], 0)

Running python -m pytest in the project folder finds the test file, runs each function and reports which passed. The first test checks the ordinary case. The second captures the bug from Stage 8 for good; reintroduce the division by n and it fails. The third catches a subtler fault that only thinking about tests revealed. Asked for the last zero days, the original function computed readings[-0:], and since -0 is simply 0 that means "from the start", so it quietly averaged every reading. No error, just a wrong answer, the most dangerous kind. The new if refuses such a request loudly, and pytest.raises confirms that it does.

That is the pattern worth copying. Every time you fix a bug, write a test that would have caught it. Such regression tests are the cheapest insurance in programming.

How much testing is enough

For a hobby project, test the parts that calculate, parse or transform, because that is where silent wrong answers live. Run the tests before every commit. Code hosts can also run them on every push, a practice called continuous integration, but the habit of typing python -m pytest gets you most of the benefit.

Stage 11Security Hygiene for Hobby Projects

It is tempting to think nobody would bother attacking a hobby project. Nobody needs to bother. Automated tools scan public code repositories for passwords and keys around the clock, and they sweep the internet for devices with default passwords. Hobby code also touches real things: your email account, your bank's exported statements, your home network, and cloud accounts that bill by the hour. A little hygiene, practised from the start, costs almost nothing.

Keeping secrets out of code

A secret is anything that grants access: a password, an API key (the code a web service gives you to identify your program), a token, a private key. The rule is simple. Secrets never go in source files, because source files go into Git, and Git remembers everything.

Instead, the program reads the secret from its surroundings when it runs. The simplest way is an environment variable, a named value set in the terminal before the program starts.

import os

api_key = os.environ.get("WEATHER_API_KEY")
if not api_key:
    raise SystemExit("WEATHER_API_KEY is not set; see README.")

The script asks the operating system for a variable called WEATHER_API_KEY. If it is missing or empty, the script stops at once with a clear message, rather than failing obscurely later. The key itself exists only on your machine.

Many projects keep such values in a small file called .env, which a library loads at start-up. That file must never be committed. Git's .gitignore file lists things Git should ignore, and a sensible one for a Python hobby project begins like this.

# never commit these
.env
secrets/
.venv/
__pycache__/
*.sqlite3

The first two lines keep secrets out, the next two exclude the virtual environment (see Stage 16) and rebuildable cache files, and the last excludes local databases, which often hold personal data and need their own backup (see Stage 15). If a secret does get committed, a later commit deleting it still leaves it in the history and in every clone. Treat it as leaked: revoke or replace it at the issuing service first, and only then clean the history if you wish.

Updating dependencies

A dependency is someone else's code that your project uses, usually installed as a package. Flaws are found in popular packages all the time and published with identifiers called CVEs (Common Vulnerabilities and Exposures). An old project with old dependencies may be carrying known holes. Check now and then, update one package at a time, run your tests, and commit. Stage 16 explains why you should also pin exact versions; pinning and updating are not in conflict, because the point is to change versions on purpose rather than by accident.

Trusting packages carefully

Anyone can publish a package to PyPI, Python's package index, or to npm, JavaScript's. Typosquatting means publishing a malicious package under a name one letter away from a popular one; abandoned packages are sometimes taken over by people with bad intentions; and some packages run code the moment they are installed. Before adding one, check the spelling against the official documentation, look for an active source repository with more than one maintainer, and ask whether ten lines of your own would do. Install packages into the project's own virtual environment, never system-wide with administrator rights.

Your own little servers

Keep a Raspberry Pi dashboard or file share inside the home network rather than opening a port on the router; for remote access, use a private-network tool designed for it. Change every default password, keep the software updated, and switch off services you do not use.

The moment a project stores friends' phone numbers or a club's member list, you are responsible for other people's privacy. Collect as little as possible, keep it out of public pages and repositories, and delete it when you are done. Stage 22 notes the Indian law that applies.

Stage 12Open Source: Licences and Contributing Kindly

Nearly every tool in this guide is open source: its source code is published under a licence that lets anyone use, study, change and share it. Python, Git, Linux and thousands of the packages you will install were built this way, much of them by volunteers. The free software movement, begun by Richard Stallman with the GNU Project in 1983, stresses users' right to control the software they run; the term open source, adopted in 1998, stresses the practical benefits of shared code. Most well-known licences are accepted by both the Free Software Foundation and the Open Source Initiative.

Licences in outline

What follows is an outline, not legal advice. For anything commercial or complicated, consult a lawyer.

Code with no licence is not free to reuse. Under copyright law the author keeps all rights by default, so publishing code on a public site without a licence lets people read it, but not legally copy it into their own work.

Permissive licences such as MIT, BSD and Apache 2.0 let others do almost anything with your code, including using it in closed commercial products, provided they keep your copyright notice. Apache 2.0 adds an explicit grant of patent rights.

Copyleft licences, chiefly the GNU General Public License (GPL), also allow nearly everything, with one condition: if you distribute a modified version, you must make its source available under the same licence. The Lesser GPL (LGPL) applies that condition mainly to the library itself, and the Affero GPL (AGPL) extends it to software that people use over a network.

Creative Commons licences were designed for writing, pictures and music, and Creative Commons advises against using them for software, except CC0, which places work as near the public domain as the law allows. Licences are usually named by short standard codes from the SPDX list, such as MIT or GPL-3.0-or-later. Your dependencies' licences travel with your code when you share it.

Contributing kindly

Most open-source projects are maintained by a few people in their spare time. The kindest contribution is one that costs them little effort to accept.

First read the project's README, its CONTRIBUTING file and code of conduct, and search the existing issues; your question has often been answered. A good bug report gives your version and operating system, the exact steps, what you expected, what happened, and the full error text, ideally with the shortest code that shows the bug.

A good pull request (a merge request on some hosts) makes one change, follows the project's style, includes a test where the project has tests, and explains why. For anything bigger than a small fix, open an issue and ask first. When a reviewer asks for changes, they are investing time in you; answer without defensiveness. Documentation, translations into Indian languages (see Stage 20) and answering beginners' questions are as valuable as code.

Do not post "any update?" on an issue, do not submit anything you have not tested, including an AI tool's output, and do not invent trivial changes to collect points for an event.

Stage 13Hardware Tinkering: Microcontrollers and Single-Board Computers

Sooner or later many hobby programmers want their code to reach out of the screen: to read a temperature, switch on a light, or count how often the gate opens. That is the territory of small, cheap boards, and it has never been easier to enter.

Two kinds of board

A microcontroller is a tiny computer on a single chip. It runs one program, starts in a fraction of a second, uses very little power, and has no operating system. The Arduino family, the ESP32 boards made with chips from Espressif, and the Raspberry Pi Pico are the best known. They are ideal for sensors, lights, motors and anything that should run unattended on a battery.

A single-board computer, such as the Raspberry Pi 4 or 5, is a complete computer the size of a playing card. It runs Linux and can host Python, a web server or a home dashboard, but needs more power and has an operating system to keep updated (see Stage 11).

Arduino boards are usually programmed in C++. The Pico and most ESP32 boards can instead run MicroPython, a compact Python, which the Thonny editor from Stage 6 can talk to directly.

Blinking a light

The traditional first program on any board makes an LED blink. This one is MicroPython on a Raspberry Pi Pico, with an LED and a resistor connected to one of its pins.

from machine import Pin
import time

led = Pin(15, Pin.OUT)   # an LED and a 330-ohm resistor on GP15

while True:
    led.value(1)
    time.sleep(0.5)
    led.value(0)
    time.sleep(0.5)

The machine module is MicroPython's way of reaching the hardware, and Pin(15, Pin.OUT) sets pin GP15 as an output. The while True loop never ends, which on a microcontroller is normal: the program is the device's whole life. A value of 1 puts 3.3 volts on the pin and lights the LED; 0 turns it off. The resistor limits the current, and leaving it out can damage both LED and board. Swap the LED for a sensor, and the step to a balcony weather station is shorter than it looks.

Safety, conservatively

Stay with USB power and small low-voltage batteries. Never work on mains electricity, which is 230 volts in Indian homes and can kill; anything that switches a mains appliance should be a certified, enclosed module installed by someone qualified, and power adapters should be certified products. A soldering iron's tip runs at several hundred degrees: keep it in its stand, let flux fumes clear, keep children away, wash your hands after handling solder (especially leaded solder), and wear eye protection when trimming wire leads, which fly.

Lithium-polymer (LiPo) cells, common in small projects, can catch fire if punctured, short-circuited or overcharged. Charge them only with a proper charger, on a non-flammable surface, never unattended, and never use or charge a swollen one again (see Stage 16).

Stage 14Learning Without Burning Out, and Ergonomics

A hobby is meant to add something to a life, and programming has a particular way of taking over one. The work is absorbing, there is always one more bug, and the internet is full of people who seem to learn faster than you. This stage is about keeping the hobby enjoyable, and keeping your body intact while you do it.

Pace

Half an hour most days beats a whole Sunday once a month. Keep a short learning log of what you tried, what broke and what you learned; on bad days it shows how far you have come. Expect plateaus, where tutorials feel too easy and real projects too hard; that gap closes with small projects, not more tutorials. Compare yourself with yourself last year, not with strangers online, whose posts show finished projects and never the fortnight spent stuck.

When the hobby stops being fun

Warning signs include dreading the project you used to look forward to, coding late into nights you need for sleep, and irritation that spills into the rest of your day. When that happens, stop for a week. Nothing will be lost; your code will wait, and so will Git. If low mood, anxiety or sleeplessness persist for weeks, whatever their cause, talk to a doctor.

Posture, eyes and hands

Most programming injuries come from hours of stillness in a poor position. The advice below is general and conservative; it is not a substitute for a health professional.

• Put the top of the screen at or slightly below eye level, roughly an arm's length away. A laptop on a stand with a separate keyboard and mouse achieves this cheaply.
• Keep wrists straight and forearms roughly level. Do not rest wrists on a hard desk edge while typing.
• Sit with your back supported and your feet flat on the floor or on a footrest.
• Avoid long spells with a laptop on the bed, a floor cushion or your lap; it bends the neck forward, and bedding blocks the laptop's cooling.
• Keep windows beside the screen, not behind it or behind you, to reduce glare.
• Stand up and move at least every half hour to hour, and in a hot room drink water.
• Rest your eyes on something far away regularly. A common rule of thumb is every 20 minutes, at something about 20 feet away, for 20 seconds.

See a doctor or physiotherapist if you have pain that persists or returns, numbness, tingling or weakness in your hands or arms, or neck or back pain that does not settle with rest. See an optometrist or eye doctor for frequent headaches or blurred vision at the screen. Do not simply buy a wrist brace and carry on; early advice matters most.

Storage and Preservation

Stage 15Storage: Code, History, Backups and Records

A programmer's losses are rarely dramatic. A laptop disappears from a train. A drive that worked on Friday is silent on Monday. A script meant to tidy one folder empties another. An account is locked because the phone holding its two-factor codes was stolen.

The code itself is usually the cheapest thing to lose; most hobby scripts could be rewritten in a weekend. What cannot be rewritten is the data your projects gathered over years, the history of what you tried and why, your notes and sketches, and the accounts that hold them. This stage covers keeping those safe. Stage 16 covers keeping old projects runnable and the hardware sound.

Version control as preservation

A Git repository with honest commit messages is a diary of decisions. A message such as "Divide by readings used, not days requested" tells your future self why a line looks the way it does. Mark versions that worked with a tag, for example git tag balcony-station-v1, so that "the code that ran all through the 2026 monsoon" has a name you can return to.

Git is excellent at text: code, CSV files, Markdown, settings. It is poor at large binary files such as photographs, video and big databases, which bloat a repository and are better backed up separately. And Git preserves only what is committed. Uncommitted edits, files listed in .gitignore, local databases and branches you never pushed all exist on one disk only.

A remote is not a backup on its own

Pushing to a code host gives you a second copy, which is good. On its own it is not a backup, for four reasons.

• It holds only what you pushed.
• It copies your mistakes faithfully. Delete a branch and push, or force-push over history, and the remote changes too.
• It depends on an account you can lose, through a stolen phone, a forgotten password or a suspension.
• Services close. Google Code shut down in 2016, and the Gitorious code host closed in 2015.

A backup is an independent copy that no single mistake, and no single company, can reach. Public projects may also be swept into long-term archives such as Software Heritage, but those preserve public code for the world, not your private work, your data or your notes.

The 3-2-1 rule, for code and data

Keep three copies of anything that matters, on two different kinds of storage, with one of them somewhere else.

Cloud sync folders are not backups. If a file is deleted or scrambled by ransomware, the damage syncs too, although version history can rescue recent changes. Keep live Git repositories out of sync folders altogether, because two machines syncing a repository's internal files at once can corrupt it. For a SQLite database, never copy the file while a program is writing to it; use SQLite's own backup command, or stop the program first.

The off-site copy is what makes fire, flood and theft survivable. Do not carry the backup drive in the laptop bag, where one theft takes both, and in an emergency save people, not drives. That is the point of having a copy elsewhere.

Testing a restore

A backup you have never restored is a hope. Drives fail silently, backup tools are misconfigured more often than anyone admits, and the one folder you forgot is always the one you need.

Exporting from a hosting account

An ordinary clone gives you code and history, but not the issues, the wiki or the discussion around them, which is often where the reasoning lives. The commands below take a fuller copy from a project on GitHub.

git clone --mirror git@github.com:asha/expense-tracker.git
git clone --mirror git@github.com:asha/expense-tracker.wiki.git
gh issue list -R asha/expense-tracker -s all -L 1000 --json number,title,body,comments > issues.json
cd expense-tracker.git
git bundle create ../expense-tracker-2026-09.bundle --all
git bundle verify ../expense-tracker-2026-09.bundle
cd ..
git clone expense-tracker-2026-09.bundle restore-test

git clone --mirror copies every branch and tag, not only the default branch. On GitHub a project's wiki is a separate Git repository with .wiki in its name, so it is mirrored the same way. Issues are not in Git at all; the third line uses GitHub's command-line tool, gh, to save every open and closed issue, with its comments, as a JSON file. The bundle lines pack the whole mirror into one file that is easy to copy to a drive, and check it. The last line proves the bundle can be restored. Other hosts, including GitLab and Codeberg, have their own export features; find yours once and note what it includes and what it leaves out.

Keeping secrets out of archives

Backups hold everything, including things you would never hand to a stranger: any secret ever committed, .env files, SSH keys in your home folder, and databases containing other people's details. Encrypt the off-site copy, and keep the passphrase or recovery key both in your password manager and on paper at home. Lose the key and the backup is lost with it. When you share a project as a zip file, make it from a fresh clone or with git archive, which exports the tracked files of one commit without their history. Never zip your working folder and send that.

File formats that last

The format you save in decides whether you can read your own data in twenty years.

SQLite deserves a word. The US Library of Congress lists it among its recommended formats for preserving datasets, and its developers have stated that they intend to support the file format through the year 2050.

Notebooks and design sketches

The paper notebook beside the keyboard often holds the only record of a pin layout, a wiring change, or why a design was abandoned. Photograph or scan the useful pages every month and commit the images to a docs folder in the project, which brings them inside the 3-2-1 routine. Write in pencil or pigment ink, which outlast most felt-tip pens, and never rely on thermal-paper printouts, which fade. Stage 16 covers storing the notebooks themselves in an Indian home.

Stage 16Preservation: Old Projects, Hardware and the Indian Climate

Code does not decay on a disk. The world it runs in moves away from it, and the hardware that holds it decays in heat and damp. This stage deals with both.

Dependency rot

A project that ran perfectly in 2026 may refuse to start in 2029 without a single change. Python releases a new version every year and supports each for about five years. Packages publish new versions that break old code, and remove features they had warned about. Packages vanish or change owners, web services change their interfaces or close, and operating systems drop old libraries. When Python 2 reached its end of life on 1 January 2020, a great deal of hobby code was left stranded.

The cure is to record, while the project still works, exactly what it needed.

Pinning versions and lockfiles

The commands below give a Python project its own virtual environment, a private folder of packages, and write down exact versions.

python -m venv .venv
source .venv/bin/activate          # macOS and Linux
.venv\Scripts\Activate.ps1         # Windows PowerShell
python -m pip install requests==2.32.3
python -m pip freeze > requirements.txt
python --version > python-version.txt
# years later, in a fresh environment:
python -m pip install -r requirements.txt

The first line creates the environment in a folder called .venv, and the activation line (one or the other, depending on your system) makes the terminal use it. The install line asks for an exact version of a package rather than whatever is newest. pip freeze writes every installed package with its exact version, including those pulled in indirectly, into requirements.txt, and the next line records the Python version. Commit both files. The final line is how you rebuild the environment later.

JavaScript projects get a lockfile, package-lock.json, automatically, and Python tools such as Poetry and uv write their own (poetry.lock, uv.lock). A lockfile records the exact version of every dependency, often with a checksum. Commit it. Pinning is not freezing: you still update on purpose, as Stage 11 describes. Installers for old Python versions remain available from the official Python website, so a well-pinned project can usually be revived.

Containers, in outline

A container tool such as Docker or Podman packages a program, its dependencies and a minimal operating system into an image that runs the same way on any machine with the tool. Its recipe, a Dockerfile, should name an exact base image such as python:3.13-slim, not "latest". Rebuilding downloads everything again and old base images can be withdrawn, so to preserve one, save the built image to a file with docker save. For most hobby scripts, a pinned requirements file and a good README are simpler and enough.

Laptops in heat and humidity

Lithium-ion batteries age faster when kept hot and fully charged, so a laptop left plugged in on a warm desk all summer wears its battery quickly. If the maker's software offers a charge limit, such as 80 per cent, use it for a laptop that lives on the desk. Keep vents clear of beds and cushions, never leave a laptop in a parked car, and have dust-clogged vents cleaned, by an authorised service centre if you are unsure how.

Humidity brings condensation. Carry a cold laptop from an air-conditioned office or car into humid monsoon air, and water can form on and inside it. Leave it closed in its bag for half an hour to warm up before opening and switching it on. Protect against electrical surges and outages with a surge-protected power strip, and put an inexpensive UPS on anything that writes data continuously, such as a Raspberry Pi logging sensors or a home file server.

Swollen batteries

A lithium battery that is failing can produce gas and swell. Signs include a laptop that no longer sits flat, a trackpad that lifts or stops clicking, gaps opening in the case, or a phone screen lifting away from its frame. Stop using the device. Do not charge it, press on it, puncture it or try to flatten it. Switch it off, unplug it, place it on a non-flammable surface away from anything that burns, and take it to an authorised service centre. Dispose of old batteries only through e-waste collection, never in household rubbish.

Drives, and why an unpowered drive is not an archive

Every drive fails eventually. A hard disk is mechanical, easily damaged by a knock, and may not spin up after years on a shelf. A solid-state drive, USB stick or memory card stores data as tiny electrical charges, which leak away slowly while it is unpowered, faster when it is warm and well worn. Industry test standards for consumer SSDs require a drive at the end of its rated life to hold data unpowered for only about a year at around 30 °C, a room temperature many Indian homes exceed for months. Cheap USB sticks and memory cards are generally less dependable still.

So a drive in a drawer is not an archive. An archive is a routine: more than one copy, plugged in and checked regularly, and replaced every few years. Record a checksum for important archive files, with Get-FileHash in PowerShell or sha256sum on Linux, and compare it after each copy; a changed checksum means a damaged file.

Boards and components

A spark of static electricity too small to feel can damage a chip without any visible mark. Handle boards by their edges, touch a grounded metal object before picking one up, and store boards in anti-static bags, the pink dissipative kind or the silvery shielding kind, never in ordinary polythene. Chips with legs can be pushed into conductive black foam.

Humidity corrodes copper tracks, pins and connectors, leaving a green or white crust, and salt air speeds this up. Flux residue left after soldering attracts moisture; clean it off with isopropyl alcohol and a soft brush, in a ventilated room away from flames, since the alcohol is flammable. Remove batteries from any project going into storage: alkaline cells leak and eat battery contacts. Store lithium-polymer cells partly charged (many chargers have a storage setting, roughly 3.8 volts per cell), in a fire-resistant bag or a metal tin, away from heat. Photograph wiring before taking a project apart.

The Indian climate

Monsoon humidity sits above 80 per cent for weeks in much of the country. Paper cockles and grows mould, connectors corrode, and silica gel saturates in days rather than months. In coastal cities such as Mumbai, Chennai and Kolkata, salt-laden air adds corrosion all year. North Indian summers push unairconditioned rooms past 40 °C, which ages batteries and SSDs, and dust storms clog vents and fans. Power cuts switch off dehumidifiers and interrupt backups, so check that the weekly backup actually ran after an outage. Termites live in wooden shelves and particle-board furniture and will eat notebooks kept there.

The affordable answers work. Keep drives, spare boards and notebooks in airtight plastic boxes with silica gel. Prefer orange indicating gel, which changes colour when saturated, over the older blue kind, which contains a cobalt compound treated as hazardous. Recharge gel by drying it at a low oven temperature as its packet directs, on a tray never used for food. Put a cheap digital hygrometer, roughly ₹200–500 (2026), inside the box; cheap ones may be off by several per cent, so watch the trend rather than the exact figure. Choose an interior room, not an outside wall, not the top floor under the roof, not beside a bathroom or kitchen, and keep boxes off the floor.

A routine

Stage 17Early Computing in India

India's computing story begins in the 1950s, in two institutions with very different needs. Both were led by scientists who believed a newly independent country should build, and understand, the machines of its century.

Calcutta and Bombay

The Indian Statistical Institute (ISI) in Calcutta, founded by the statistician P. C. Mahalanobis, needed calculation on a vast scale for national sample surveys and economic planning. In 1956 it installed the HEC-2M, a machine from Britain, which is widely described as the first digital computer in India. Machines from other countries followed there over the next few years.

The Tata Institute of Fundamental Research (TIFR) in Bombay, founded by Homi Bhabha, took the harder road of building its own. A team led by R. Narasimhan designed and built the TIFRAC (the TIFR Automatic Calculator), using valves, the glass vacuum tubes that did the work transistors do today. Completed around 1960, it is generally regarded as the first digital computer designed and built in India.

In the mid-1960s ISI and Jadavpur University together built ISIJU-1, a transistorised computer. By then imported machines had begun to arrive at universities, research laboratories and a few large companies. The Indian Institute of Technology at Kanpur acquired an IBM 1620 in the early 1960s, and generations of Indian students met computing through such machines: writing programs on coding sheets, punching them onto cards, and waiting, sometimes a day, to learn whether a single missing comma had wasted the run.

Self-reliance and its limits

Government policy in the 1960s and 1970s aimed at self-reliance in electronics. Electronics Corporation of India Limited (ECIL), set up in Hyderabad under the Department of Atomic Energy, produced its own computers from the late 1960s. A Department of Electronics was created at the start of the 1970s to direct the sector.

The same policies made imports slow and costly. In the late 1970s IBM left India rather than reduce its ownership of its Indian business, as the foreign-exchange rules of the time required. The government-owned Computer Maintenance Corporation (CMC), set up a few years earlier, took over the care of the many machines already installed. In the same decade the National Informatics Centre (NIC) was founded to bring computers into government work, which it still does.

Opening up

The 1980s brought microcomputers and a change of mood. Indian companies such as HCL built and sold their own small computers, and policy in the mid-1980s eased the import of computers and components. Visible public systems followed; the computerised passenger reservation system of Indian Railways, first introduced in Delhi in the mid-1980s, showed millions of people what a networked computer could do, one ticket at a time.

For a would-be hobbyist in those decades access was the whole problem, and most people first programmed at a college terminal or a private training institute (see Stage 18). The home-computer boom that shaped a generation of British and American hobbyists reached India late and thinly, one reason its programming culture grew up so closely tied to education and employment.

Stage 18Computer Education, from Institutes to Classrooms

For most of India's history with computers, learning to program meant learning a trade. That is the opposite of the hobby this guide describes, and yet it built the country's enormous base of people who can code, and the institutions a hobbyist can now use for free.

Colleges, degrees and institutes

Computing first entered Indian higher education through engineering, mathematics, physics and statistics departments, with the IITs and a few universities building dedicated computer science programmes as the field matured. The Master of Computer Applications (MCA) degree, and later the Bachelor of Computer Applications (BCA), opened computing careers to graduates of other subjects.

The largest change came from private training institutes. NIIT, founded in 1981, and Aptech, which followed later in the decade, taught programming in evening, weekend and short full-time courses across hundreds of towns, often to students who had no other way to reach a computer. The government created its own certification scheme, DOEACC, with graded levels starting from the "O" Level; it is now run by the National Institute of Electronics and Information Technology (NIELIT). From the 1990s, engineering colleges multiplied, especially in the southern and western states, feeding the industry described in Stage 19.

Free courses for anyone

A hobbyist today can learn from India's best institutions at no cost. NPTEL, a programme of the IITs and the Indian Institute of Science, publishes full university courses on programming, data structures and much else, with optional paid certification exams. SWAYAM is the government's platform for online courses. At IIT Bombay, the Spoken Tutorial project makes short, practical video tutorials on open-source software, many of them in Indian languages, and the related FOSSEE project promotes free and open-source tools in education.

Programming in schools

School computing has moved from typing and word processing towards real programming. The CBSE's senior-secondary computer science and informatics practices courses now teach Python. The ICSE board's computer applications course has long used Java. Kerala's schools programme, IT@School, now called KITE, moved its computer education onto free software in the 2000s, and runs student IT clubs called Little KITEs.

The Atal Innovation Mission, under NITI Aayog, has funded Atal Tinkering Labs in thousands of schools, equipped with electronics kits, microcontrollers and small 3D printers. The National Education Policy 2020 recommends introducing coding from the middle-school years. For students who enjoy problem-solving, the Indian Association for Research in Computing Science (IARCS) runs the Indian Computing Olympiad, whose stages select the team that represents India at the International Olympiad in Informatics.

Syllabus and hobby

Examination courses have to reward answers that can be marked, so they drill syntax and output-prediction questions. That has value, but it can leave students believing programming means memorising. A child who writes Python for board exams and also builds one silly game at home for fun is learning two different and complementary things. Encourage the second as much as the first.

Stage 19The Rise of the Software Services Industry

Most Indians who can program learned in order to work. The software services industry that employs them was built over half a century, and it shapes the hobby even for those who have never worked in it: the vocabulary, the institutes, the cities, and the assumption that programming is a career first.

The founders

Tata Consultancy Services (TCS) was founded in 1968 within the Tata group and, led by F. C. Kohli through its formative decades, grew from data-processing work for the group's own companies into software for clients abroad. HCL was founded in 1976 by Shiv Nadar and colleagues as a hardware company. Wipro began as a vegetable-oil company and moved into computing around 1980 under Azim Premji. Infosys was founded in Pune in 1981 by N. R. Narayana Murthy and six co-founders with very little capital, and later moved to Bangalore.

In the 1980s much of the work was on-site: Indian programmers travelled to clients' offices, mostly in the United States, to write and maintain software there. The shift to offshore work, done in India and delivered over data links, needed communications that barely existed. Texas Instruments opened a development centre in Bangalore in the mid-1980s with its own satellite link, and it is often cited as the moment multinational companies began to see India as a place to build software. From 1991, Software Technology Parks of India provided exporters with data connections and simplified procedures.

The industry body NASSCOM was founded in 1988. The economic liberalisation of 1991 removed many obstacles, and the Y2K work at the end of the decade (see the sidebar) gave Indian firms long relationships with large clients abroad.

Cities and scale

Bengaluru became the best-known centre, followed by Hyderabad, Pune, Chennai, and Noida and Gurugram near Delhi, with substantial clusters in Kolkata, Kochi, Thiruvananthapuram and elsewhere. By the 2020s the industry employed several million people directly, and industry estimates put its annual revenue in the hundreds of billions of US dollars.

The work changed shape too. Multinationals opened their own global capability centres; product companies such as Zoho, founded in Chennai, and consumer internet firms such as Flipkart in Bengaluru grew up; and public systems such as Aadhaar and the Unified Payments Interface (UPI), launched by the National Payments Corporation of India in 2016, put software into almost every citizen's day.

What this means for the hobby

The industry made programming respectable, well paid and widely taught. It also made it look like a job, measured by certificates, placements and salaries. The hobby in this guide is a different thing: small, personal and done for its own sake. For a professional it can be a way back to what first made code interesting, and a way to learn things the day job never asks for.

Stage 20Computing in Indian Languages: Scripts, Unicode and Input

India's constitution lists 22 languages in its Eighth Schedule, written in a dozen major scripts and many more minor ones. Making computers handle them properly took decades, and the work is still not finished. For a programmer it is also one of the most interesting problems in the field.

Why Indian scripts are hard

Most Indian scripts, such as Devanagari, Bengali, Gurmukhi, Gujarati, Odia, Tamil, Telugu, Kannada and Malayalam, descend from the ancient Brahmi script and work in a similar way. A consonant carries a built-in vowel sound. Other vowels are written as vowel signs (matras) attached above, below, before or after it. Consonants join into conjuncts when the vowel between them is cancelled by a mark called the virama or halant. The shapes on the screen can therefore differ greatly from the sequence of characters underneath.

From legacy fonts to Unicode

For years much Hindi text was typed in legacy fonts, such as the widely used Kruti Dev, which drew Devanagari shapes over the codes normally used for Latin letters. The text looked right only with that font installed; to any program or search engine it was nonsense, and converting such documents still needs special mapping tools.

The Bureau of Indian Standards published a proper encoding, ISCII (Indian Script Code for Information Interchange), covering the Brahmi-derived scripts with a common layout. When Unicode, the international standard giving every character in every writing system a number, added Indian scripts, it based their arrangement on ISCII. Unicode is now what phones, browsers and modern software use.

The listing below looks inside a single Hindi word.

import unicodedata

word = "नमस्ते"
print(len(word))
print(len(word.encode("utf-8")))
for ch in word:
    print(f"U+{ord(ch):04X}", unicodedata.name(ch))

It prints 6, because the word is stored as six code points: the letters na, ma, sa and ta, a virama joining sa to ta, and the vowel sign e. It then prints 18, because in UTF-8 each Devanagari code point takes three bytes. Finally it names each one, from U+0928 DEVANAGARI LETTER NA to U+0947 DEVANAGARI VOWEL SIGN E. A reader sees fewer than six letters, which is the first lesson: len counts code points, not what people read.

What this means in your code

Always read and write text as UTF-8 (see Stage 5), and do not cut strings at arbitrary positions, which can split a conjunct from its vowel sign. Python's sorted orders by code point, not by Hindi or Tamil dictionary order, which needs a collation library such as ICU. Some letters can be stored in more than one way, such as a consonant with a nukta dot, so normalise with unicodedata.normalize("NFC", text) before comparing. Display order can differ from storage order too: in कि the vowel sign is stored after the consonant but drawn before it. Putting shapes in the right places is the job of a shaping engine, such as the open-source HarfBuzz, working with OpenType fonts.

Typing it

InScript is the government-standardised keyboard layout for Indian scripts, built into Windows, macOS and Linux; it arranges vowels on one side and consonants on the other, and the same layout works across the Brahmi-derived scripts. Many people prefer phonetic (transliteration) input, typing "namaste" in Latin letters and choosing नमस्ते from suggestions, which phone keyboards now offer for most Indian languages, alongside handwriting and voice input.

The people doing the work

Much of this was built by volunteers. Swathanthra Malayalam Computing, a free-software community, has produced fonts, input tools and spell-checkers for Malayalam. Localisation volunteers translate programs such as Firefox and LibreOffice into Indian languages, which is an excellent first contribution for a bilingual hobbyist (see Stage 12). On the government side, the Technology Development for Indian Languages programme and the Bhashini language-technology mission support tools and datasets, and AI4Bharat at IIT Madras publishes open language models and data for Indian languages.

Stage 21Open-Source and Developer Communities

India has one of the largest populations of programmers in the world, and a large, lively community of people who write code together for reasons other than a salary. For a hobbyist it is the best antidote to learning alone.

The free-software years

From the late 1990s, Linux user groups formed in many Indian cities, meeting in college rooms and offices to install Linux for newcomers, argue about editors and swap CDs. The Free Software Foundation of India was set up in 2001. Bangalore's FOSS.IN conference, which began as a Linux event, drew contributors from around the world through the 2000s. Swecha grew into a free-software movement in the Telugu-speaking states, and Kerala's decision to put free software in its schools (see Stage 18) gave the movement unusual public reach.

Conferences and meetups today

PyCon India, the national Python conference run by volunteers, has been held every year since 2009 in different cities. IndiaFOSS, organised by the FOSS United Foundation, gathers people who build and maintain open-source software. HasGeek runs community conferences including JSFoo for JavaScript, Rootconf for systems and infrastructure, and The Fifth Elephant for data. In 2023 Kochi hosted DebConf, the annual conference of the Debian project, one of the oldest and largest volunteer-run Linux distributions.

Between conferences, cities have regular meetups, such as BangPypers, Bengaluru's Python user group, along with groups for JavaScript, Rust, Go, data science, security and hardware. Many are free and deliberately welcoming to beginners. Indian contributors are active in projects such as Mozilla, GNOME, KDE and the Wikipedias in Indian languages, and students take part in mentoring programmes such as Google Summer of Code, and in the government's Smart India Hackathon.

Getting the most from a community

Go to listen first. Talks aimed at beginners are common, and the corridor conversations are often better than the talks. Volunteering at a conference, such as registration, stage management or social media, is one of the easiest ways to meet the organisers and speakers. Read the event's code of conduct, and expect it to be enforced. And bring a small project to show; people remember "the person who built a monsoon rainfall dashboard" far longer than a job title.

Online, the same manners apply. Search before asking, share the exact error and what you have already tried, and thank the people who answer. A community stays generous only if some of the newcomers it helps stay on to help the next ones.

Stage 22Makers, Hobby Electronics, and Starting Out in India Today

Long before microcontrollers were cheap, India had a strong culture of repairing, rewiring and building electronics, much of it centred on a handful of famous markets. That culture and the modern maker movement have now met.

Where the parts are

Lamington Road in Mumbai, SP Road in Bengaluru, Ritchie Street in Chennai and the electronics markets of Old Delhi, with Nehru Place for computers, have supplied hobbyists, repairers and small manufacturers for decades. They reward knowing what you want: bring the part number, compare shops, and test before paying where you can. Counterfeit and remarked chips exist in every market, so for anything critical prefer reputable sellers. Indian online shops now deliver boards, sensors and kits to smaller towns, opening the hobby well beyond the big cities.

Electronics For You, published since the late 1960s, has long been the magazine through which Indian readers learned about circuits and projects. Makerspaces such as Maker's Asylum, college robotics and electronics clubs, and the Atal Tinkering Labs in schools give people access to tools, 3D printers and help. India also designs processors of its own: the SHAKTI processors from IIT Madras and C-DAC's VEGA processors are both based on RISC-V, an open instruction-set design anyone may use.

The law, in outline

This is a brief orientation, not legal advice. Laws and rules change, so check the current text for anything that matters.

Starting out in India today

The path has never been cheaper. An ordinary laptop and a free Python installation will carry you through Part I. NPTEL, SWAYAM and Spoken Tutorial offer structured courses at no cost, some in Indian languages (see Stage 18). A microcontroller starter kit costs roughly ₹1,500 (see Stage 13), and the communities in Stage 21 will answer your questions. The heat, dust and monsoon make the habits in Stages 15 and 16 matter more in an Indian home than almost anywhere.

What remains is the part no guide can supply: choosing one small thing you want to exist, and building it for yourself.

Glossary

B

Backup — An independent copy of data that no single mistake, device failure or company can reach. [Stage 15]

Bug — Any difference between what a program does and what its author meant. [Stage 8]

Bytecode — The intermediate instructions Python produces from source code and then runs. [Stage 2]

C

Checksum — A short value calculated from a file's contents, used to detect damage after copying. [Stage 16]

Code point — The number Unicode assigns to a single character or mark. [Stage 20]

Commit — A recorded snapshot of a project in Git, with a message, author and date. [Stage 6]

Compiler — A program that translates source code into machine code before it runs. [Stage 2]

Container — A program packaged with its dependencies and a minimal operating system, run by a tool such as Docker. [Stage 16]

Copyleft — A licence condition requiring distributed modified versions to be shared under the same licence. [Stage 12]

CSV — Comma-separated values; a plain-text table format every spreadsheet can read. [Stage 5]

D

Debugger — A tool that pauses a running program so it can be inspected line by line. [Stage 8]

Dependency — Someone else's code that a project uses, usually installed as a package. [Stage 11]

Dependency rot — The gradual failure of an untouched project as the software around it changes. [Stage 16]

E

Environment variable — A named value set outside a program, commonly used to supply secrets. [Stage 11]

F

Floating point — The binary format for fractional numbers, which cannot hold most decimals exactly. [Stage 2]

Function — A named piece of code that takes inputs, does one job and returns a result. [Stage 5]

I

InScript — The government-standardised keyboard layout for Indian scripts. [Stage 20]

Interpreter — A program that reads source code and carries it out as it goes. [Stage 2]

ISCII — Indian Script Code for Information Interchange; the Indian standard on which Unicode's Indian blocks were based. [Stage 20]

L

Lockfile — A file recording the exact version of every dependency a project uses. [Stage 16]

M

Microcontroller — A small computer on one chip that runs a single program without an operating system. [Stage 13]

MicroPython — A compact version of Python for microcontrollers. [Stage 13]

O

Open source — Software published under a licence letting anyone use, study, change and share it. [Stage 12]

P

Permissive licence — A licence such as MIT or Apache 2.0 that allows almost any reuse if the notice is kept. [Stage 12]

Pull request — A proposed change submitted to a project for review; a merge request on some hosts. [Stage 12]

R

Regression test — A test written after fixing a bug, so the bug cannot silently return. [Stage 10]

Remote — A copy of a Git repository held elsewhere, usually on a code host. [Stage 15]

Repository — A project folder together with its complete Git history. [Stage 6]

S

Secret — Anything that grants access, such as a password, token or API key. [Stage 11]

Single-board computer — A complete computer on one small board, such as a Raspberry Pi. [Stage 13]

SQLite — A public-domain database stored in a single file, well suited to long-term keeping. [Stage 15]

T

Terminal — A text window for typing commands; also called the command line or shell. [Stage 6]

Three-two-one rule — Three copies, on two kinds of storage, with one kept elsewhere. [Stage 15]

Traceback — Python's report of an error, showing where it happened, most recent call last. [Stage 7]

Typosquatting — Publishing a malicious package under a name one slip away from a popular one. [Stage 11]

U

Unicode — The international standard assigning a number to every character in every writing system. [Stage 20]

UTF-8 — The most widely used way of storing Unicode text as bytes. [Stage 20]

V

Version control — A system, such as Git, that records the history of changes to files. [Stage 6]

Virama — The mark that cancels a consonant's built-in vowel, joining it to the next consonant. [Stage 20]

Virtual environment — A private folder of packages for one Python project. [Stage 16]

Further Reading and Organisations

Learning and craft

• Al Sweigart, Automate the Boring Stuff with Python.
• Eric Matthes, Python Crash Course.
• Allen B. Downey, Think Python.
• Marijn Haverbeke, Eloquent JavaScript.
• Scott Chacon and Ben Straub, Pro Git.
• David Thomas and Andrew Hunt, The Pragmatic Programmer.
• David J. Agans, Debugging: The 9 Indispensable Rules for Finding Even the Most Elusive Software and Hardware Problems.
• Charles Petzold, Code: The Hidden Language of Computer Hardware and Software.
• Charles Platt, Make: Electronics.
• Jukka K. Korpela, Unicode Explained.
• The official Python documentation, from the Python Software Foundation, and Mozilla's MDN Web Docs for HTML, CSS and JavaScript.

Open source, hardware and preservation

• The Open Source Initiative, the Free Software Foundation and the Free Software Foundation of India.
• The SPDX licence list, for standard licence identifiers.
• Software Heritage, the archive of publicly available source code.
• The Raspberry Pi Foundation, the Arduino project and the MicroPython project.
• Electronics For You magazine.

India

• Dinesh C. Sharma, The Outsourcer: The Story of India's IT Revolution.
• Tata Institute of Fundamental Research, Mumbai; Indian Statistical Institute, Kolkata; C-DAC, Pune.
• NPTEL, SWAYAM, and the Spoken Tutorial and FOSSEE projects at IIT Bombay.
• National Institute of Electronics and Information Technology (NIELIT).
• Indian Association for Research in Computing Science (IARCS).
• Atal Innovation Mission, NITI Aayog.
• NASSCOM.
• FOSS United Foundation, PyCon India and HasGeek.
• Swathanthra Malayalam Computing, AI4Bharat at IIT Madras, and the Bhashini mission.
• CERT-In, the Indian Computer Emergency Response Team.

Image Sourcing Sheet