Reading Other Peoples Code

Until now you have written code from a blank file. The bigger half of a developer's life is the opposite. You open a folder someone else made, often years ago, often by someone who has now left the company, and you try to understand what it does before you change anything. The first time you do this on a real GitHub repository, the panic is real. There are forty folders. There are files with names like webpack.config.cjs. The README assumes you already know what a monorepo is. Take a breath. Every senior engineer in Lahore felt the same panic on her first day. The skill of reading code is learnable, and it is mostly about where you point your eyes first.

Open any small open source repo, say a popular Urdu keyboard layout on GitHub. Resist the urge to open random files. Read in this exact order. First the README dot md at the top. Second the package dot json or pyproject dot toml or requirements dot txt, whichever the language uses. Third the folder named src or app, and inside it the file called index, main, or app. That sequence answers three questions in turn. What does the project promise to do, what other code does it depend on, and where does it actually start running. Ninety percent of repositories give up their shape to those three reads.

Now the docstring habit. A docstring is a short block of text written at the top of a function, between triple quotes in Python, or between slash star star in JavaScript, that explains in plain language what the function does, what it takes in, and what it gives back. Good code is full of them. When you read someone else's code, read every docstring before you read any logic. When you write your own code from this lesson onward, write the docstring before you write the function body. The discipline is small. The reward is enormous. A docstring is a promise to your future self that you will not have to re read your own code at one in the morning to remember what it does.

Try this. Go to GitHub dot com and search for urdu sentiment. Open the top repo. Find one Python file with at least three functions. Read the README, the requirements file, the file names, then for each function read only the docstring and the first two lines. Write three sentences in your notebook. What the project does as a whole, what one function inside it does, and one thing about the code you do not yet understand. That third sentence is the most valuable. The list of things you do not yet understand is the syllabus your future self will study from.

One last habit, the one that compounds. Whenever you read a piece of code that you think is unusually clear or unusually clever, save the link in a file called code-i-admire dot md. After three months you will have twenty examples. Look at them together. You will start seeing patterns the original authors used, ways of naming, ways of breaking up logic, ways of writing comments. Those patterns will quietly enter your own code without you having to memorise rules. The Pakistani way of learning, sit next to a craftsman and watch the hands, works for code too. The internet just gave you ten thousand craftsmen to sit next to.