The Practical Developer

A feature branch starts clean. It branches off main on Monday, adds tax to the receipt total, and by Wednesday main has moved on: someone rounded the totals to two decimals and added a README. The branch still works, but merging it back adds a merge commit that joins two lines of history, a fork and a join for work that could read as a straight line. Rebasing is the other way to bring a branch up to date. It lifts the branch's commits off the old base and replays them on top of the latest main, so the history reads top to bottom. The question is when that straight line is worth the rewriting it takes. What I would check before using it My judgement, from years of working in shared codebases, is this: rebase a branch only while it is yours alone, and merge once anyone else depends on it. That single check decides almost every rebase question. If the branch exists only on your machine, rebasing is safe, because nobody else has the old commits and nobody will notice they were rewrit...

A small shop's orders module has four functions, and each one starts with the same two lines: note the time, and at the end, print how long the work took. The timing lines are not the work. They are scaffolding around the work, copied into every function by hand. When the team decides to log the timings to a file instead of printing them, someone has to edit all four functions. When one of them is missed, the timings quietly disagree, and nobody notices until a slow afternoon gets blamed on the wrong function. That is the problem a decorator solves: behaviour that wraps a function, written once and applied wherever it is needed, without touching the function's own code. A decorator is a function that takes a function and returns a new one, usually one that calls the original and adds something around it. Writing @timed above a function is the same as writing total = timed(total) after defining it, only shorter and harder to forget. The wrapper is what actually runs when the ...

Your product page lets shoppers crop and resize their own photos before upload, and the JavaScript version stutters on a phone. Each drag of the crop handle runs a loop over hundreds of thousands of pixels, the interface freezes for a beat, and the customer thinks the page is broken. That is the exact problem WebAssembly was built for. It does not make your page prettier or your code easier to write. It gives the browser a second engine for heavy number work, one that runs close to native speed, while JavaScript keeps handling clicks, forms, and the page itself. A WebAssembly module is a compact binary file that the browser loads and runs inside a sandbox. It cannot read files, reach the network, or touch the page on its own. It can only do what the JavaScript around it allows: JavaScript calls the functions the module exports, and the module calls back into JavaScript functions it is given. That boundary is deliberate, and it is the first thing to understand. WebAssembly is a guest i...

Your team runs a small internal service, and the response times in its log keep creeping up. Someone asks a simple question: how slow is it, on a normal day, and how often does it cross the 200 millisecond budget you promised? A spreadsheet would answer it once. A small program answers it every day, on any machine, without installing anything. That is the kind of job C was built for: a tiny tool, close to the machine, that reads numbers, does arithmetic, and prints an answer. C is also the language underneath most of the software you already use, so learning to write one small tool in it teaches you how the layer below your usual stack works. C is a small language, and that smallness is the whole point. There are few keywords, no built in objects, and no automatic memory management. A program is a set of functions, and data lives in variables, arrays, and structs that you lay out yourself. When you declare an array of seven integers, you get seven integers in a row in memory, and you ...

A small shop owner wants to change a price, add a new product, and publish a post about a weekend sale, all by herself, without calling a developer and without waiting a week. That is the problem WordPress was built to solve. It is a content management system, which means it separates the content of a site from the code that displays it, so the owner edits words and prices in a dashboard while the software handles the pages, the menus, and the database. WordPress started in 2003 as blogging software and grew into the platform behind a large share of the web, from personal blogs to news sites, company pages, and small shops. A WordPress site has two sides. Visitors see the public side: pages, posts, and products. Owners work in the admin dashboard, where they write posts, approve comments, and change how the site looks and behaves. Appearance comes from themes, which control layout and styling. Features come from plugins, which add things like contact forms, search optimisation, or a s...

A small team wants to build a 2D platform game and release it on phones and on PC, with the same levels, the same art, and one codebase. Building the graphics, physics, sound, and input handling from scratch for each platform would take longer than building the game itself. That is the problem a game engine solves: it handles the hard, shared parts, graphics, sound, collisions, physics, so the team can spend its time on the game. Unity is the engine most small teams reach for, because it covers 2D and 3D, runs on phones, consoles, and computers, and lets artists and programmers work on the same project at the same time. A Unity project is built from scenes, and a scene is built from GameObjects. A GameObject is an empty container, and it only does something once you attach components to it. A sprite renderer draws it, a rigidbody gives it physics, a collider lets it bump into things, and a script tells it how to behave. The same GameObject can be a player, an enemy, or a moving platfo...