IT Words in Context — Part II

Interface (UI / UX context) — the visual, interactive surface of an application: buttons, forms, navigation, screens. "Interface mockups" = design files (Figma, Sketch) showing what the UI should look like.

The same word, different contexts:

• User Interface (UI) — what the user sees and interacts with. "The new interface is cleaner." "We need to redesign the interface."
• OOP interface — a contract: a set of method signatures a class must implement. In Java: interface Serializable { ... }. In TypeScript: interface User { id: number; name: string; }. Guarantees what an object can do without specifying how.
• Hardware interface — physical or protocol connection between components: USB interface, HDMI interface, SPI interface.
• API / programmatic interface — how software components communicate: "The public interface of this module" = the exported functions/classes others can call.

Key distinction: In a design/product discussion → UI meaning. In an OOP/architecture discussion → contract meaning.

Driver (hardware / OS context) — a software component that acts as a translator between the operating system and a specific hardware device. Without the correct driver, the OS cannot control the hardware. A GPU driver (NVIDIA, AMD) exposes the GPU's capabilities to the OS and applications like CUDA or OpenCL.

The same word, different contexts:

• Hardware driver — software that controls a device: GPU driver, network adapter driver, printer driver, USB driver. "Update your graphics driver."
• Database driver — a library that handles the communication protocol between your application and a specific database: pg (PostgreSQL driver for Node.js), psycopg2 (Python), JDBC driver, MongoDB driver. "We're using the official MongoDB driver for Python."
• Business/technical driver — a factor that motivates or causes a decision: "The main driver behind migrating to microservices was team scalability." "Cost is the primary driver for this refactor."
• Everyday English — a person who drives a vehicle.

master → main: the Git default branch rename

In 2020, GitHub changed its default branch name from master to main following discussions about removing language with connections to slavery (master/slave terminology). GitLab, Bitbucket, and most other platforms followed.

Practical implications:

• New GitHub repos created after Oct 2020 use main by default
• Old repos still use master unless manually renamed
• CI/CD pipelines, scripts, and documentation that hardcode master need updating
• git config --global init.defaultBranch main — sets your local default

Other terms that changed at the same time:

• slave → replica (databases: master/slave replication → leader/follower or primary/replica)
• whitelist / blacklist → allowlist / denylist (or safelist / blocklist)
• master/slave in hardware (I2C, SPI protocols) → controller / target

In code reviews: if you see old documentation using "master" for the branch, updating it to "main" is a quick, appreciated contribution.

Driver (business / decision context) — a factor that motivates, causes, or shapes a decision. "The main driver was X" is a very common business and technical expression meaning "the main reason / primary motivation was X".

More examples of this usage:

• "Cost reduction was the key driver for migrating to a serverless architecture."
• "The performance driver here is the database query — everything else is fast."
• "What are the business drivers for adding this feature now?"
• "Growth is the primary driver — we're optimising for acquisition, not retention yet."

In technical writing, you'll often see "driver" used this way in architecture decision records (ADRs), technical proposals, and engineering blog posts to explain the why behind a design choice.

Note: this is the same word used in three completely different contexts in IT English — hardware driver, database driver, and motivating factor. Context (and surrounding vocabulary) always makes it clear which meaning is intended.

Interface (OOP / type system context) — a contract that defines what methods a class must provide, without specifying their implementation. When a class implements an interface, it guarantees the caller that all interface methods will be available.

Why interfaces matter:

• Decoupling: Code depends on the interface, not the concrete class — you can swap MySQLRepository for PostgreSQLRepository without changing the code that uses it
• Testability: You can create a fake/mock implementation of the interface for unit tests
• Polymorphism: Multiple classes can implement the same interface — any of them can be used where the interface type is expected

Language-specific syntax:

• Java/Kotlin: interface Repository { void save(User u); }
• TypeScript: interface Repository{ save(u: User): void; }
• Python: abstract base class (ABC) serves the same purpose
• Go: interfaces are implicit — if a type has the required methods, it implements the interface (no explicit implements keyword)

Interface vs. Abstract class: An interface defines what to do. An abstract class can also define how (provide partial implementations). A class can implement many interfaces, but usually only extends one class.