Beginner 15 terms

IT Fundamentals

Essential English vocabulary every IT professional must know — hardware, software, processes, and core concepts explained clearly.

  • Hardware /ˈhɑːdweər/

    The physical components of a computer system — everything you can touch: CPU, memory, storage drives, keyboard, display, network cards. Hardware runs software; hardware problems are often called "physical layer" issues.

    "The laptop keeps overheating — that's a hardware issue. We need to clean the fan or replace the thermal paste, not reinstall the OS."
  • Software /ˈsɒftweər/

    Programs and operating data that run on hardware. Divided into: system software (OS, drivers, utilities) and application software (the apps users interact with). Software is intangible — it exists as instructions executed by the CPU.

    "The problem is software, not hardware — the CPU and RAM are fine. We need to patch the operating system and reinstall the corrupted application."
  • Operating System (OS) /ˈɒpəreɪtɪŋ ˈsɪstəm/

    The foundational software that manages hardware resources and provides services to applications: process scheduling, memory management, file system, input/output. Examples: Linux, Windows, macOS, Android, iOS.

    "We standardised on Ubuntu 22.04 LTS as our operating system for all servers — it's well-supported, widely documented, and has a 5-year security update cycle."
  • Server /ˈsɜːvər/

    A computer (or software process) that provides services or resources to other computers (clients) over a network. Can be physical hardware or a virtual machine. Common types: web server, database server, file server, mail server.

    "Our application runs on three servers behind a load balancer — two handle web requests and one runs the database. If one web server goes down, traffic automatically routes to the other."
  • Client /ˈklaɪənt/

    A computer, device, or program that requests services from a server. In web development: the browser is the client, your backend is the server. In desktop apps: the application itself is the client connecting to remote services.

    "The API is designed with a clear client-server separation — the mobile app (client) only talks to our REST API (server), which handles all database operations."
  • Network /ˈnetwɜːk/

    A collection of devices (computers, phones, servers, routers) connected together to share data and resources. Can be local (LAN) or global (the internet, a WAN). Every device on a network has an IP address for identification.

    "The database is not accessible from the internet — it's on a private network segment that only our application servers can reach. This is a basic security boundary."
  • Bug /bʌɡ/

    An error in code that causes unexpected or incorrect behaviour. The term originates from a 1947 incident where an actual moth was found in a relay of the Harvard Mark II computer. Bugs range from minor cosmetic issues to critical security vulnerabilities.

    "There's a bug in the date parsing logic — dates after December 31 wrap back to January 1 of the same year instead of incrementing the year. It only occurs with the 12→1 month transition."
  • Feature /ˈfiːtʃər/

    A planned piece of functionality that provides value to users. Distinguished from a bug (unintended behaviour) and a chore (technical task with no direct user value). Features go through design, development, testing, and release before users see them.

    "The password reset feature is in scope for next sprint — users have requested it for months and it's currently the top item in the backlog by vote count."
  • Deploy /dɪˈplɔɪ/

    To release software to an environment where it can be run. Environments typically progress: development → staging (pre-production) → production. Deployment can be manual or automated via CI/CD pipelines.

    "We deploy to production every Friday afternoon — the team reviews all merged PRs at standup, runs the smoke test checklist, and if everything passes, triggers the deployment pipeline."
  • Production /prəˈdʌkʃən/

    The live environment where real users access the actual application. Changes to production have real consequences — bugs affect real users, data changes are permanent. "In production" means running live, not in a test environment.

    "Never test in production — always reproduce the bug in your local or staging environment first. We have safeguards: production access requires two-person authorisation and all changes are audited."
  • Environment /ɪnˈvaɪrənmənt/

    A self-contained system configuration for running software at a particular stage: local (developer's machine), development (shared dev server), staging (production mirror for testing), production (live). Each has its own data, configuration, and access controls.

    "The bug only appears in staging, not local — that suggests it's related to environment-specific configuration, probably the database connection pool settings or the Redis cache layer."
  • Version /ˈvɜːʃən/

    A specific release of software, identified by a number (1.0.0, 2.3.1). Semantic versioning (SemVer): MAJOR.MINOR.PATCH — increment MAJOR for breaking changes, MINOR for new features, PATCH for bug fixes.

    "We're releasing version 2.0.0 next month — it's a major version bump because the new API is incompatible with v1. All clients must update their integration before the v1 sunset date."
  • Log /lɒɡ/

    A time-stamped record of events that occurred in a system. Logs are the primary tool for debugging production issues — they capture errors, requests, state changes, and key events. Structured logs (JSON) are easier to query than plain text logs.

    "Check the application logs — the error should be in there with a timestamp and stack trace. Filter for ERROR level events in the last 30 minutes around the time the user reported the issue."
  • Dependency /dɪˈpendənsi/

    External code (library, package, service) that your project relies on. Dependencies are listed in a manifest file (package.json, requirements.txt, pom.xml) and installed by a package manager. Keeping dependencies updated is an ongoing security and maintenance responsibility.

    "The build is failing because a transitive dependency upgraded and introduced a breaking change. We need to pin the dependency version or update our code to match the new API."
  • Documentation /ˌdɒkjʊmenˈteɪʃən/

    Written explanations of how software works: API references, architecture decisions, setup guides, runbooks, changelogs. Good documentation reduces the time for new team members to become productive and prevents knowledge loss when people leave.

    "Before you start the feature, read the existing documentation in the /docs folder — the architecture decision record (ADR-007) explains why we chose the current approach and what alternatives were rejected."