Glossary

Every concept in this sheet, plus the smaller terms it uses. Select a concept to open its card.

A good question: A question that states the goal, what you tried, what you expected, what happened and the one specific thing you need.
Account security basics: Two-factor authentication on every work account, a password manager, a locked screen when you step away and never reusing personal passwords for work.
Asking for feedback: Asking specific questions about specific work, such as "what would have made that PR easier to review?", rather than "any feedback?"
Asking for more responsibility: Asking for a slightly bigger, specific piece of work once you deliver your current work reliably, with a plan for the support you need.

Blameless postmortem: A written review after an incident that describes what happened, the impact, the causes and the fixes, focusing on systems rather than individuals.
Burnout: The World Health Organization describes burnout as an occupational phenomenon from chronic workplace stress that has not been successfully managed: exhaustion, distance from work and reduced effectiveness.

Career ladder: A company document describing what is expected at each level, such as junior, mid and senior, across skills like delivery, quality and communication.
Checking your market value: Comparing your pay with current data for your role, level and location from salary sites, published ranges and trusted peers.
Company AI policy: Your employer's rules on which AI assistants you may use, with which data and code, and whether AI-written code must be marked or reviewed.
Company research: Learning what the company sells, who its customers are, how it makes money, its main competitors and, where public, its tech stack and team structure.
Confidential company data: Source code, customer data, credentials, plans and internal documents that you agreed to protect when you signed your contract.
Context switching: Moving attention between different tasks, messages and meetings, each switch costing time to get back into the problem.

Domain knowledge: Understanding the business area your software serves, such as payments, logistics or health, its terms, rules and users.

Employment contract: The signed document that sets your role, pay, start date, working hours, leave, probation, notice period and the rules you agree to follow.
Estimates and story points: Relative sizes teams give to tickets, based on effort, complexity and uncertainty, rather than exact hours.

Fake job offer: A fraudulent offer that asks you for money, bank details or a paid "training kit", often after a chat-only interview with no video call or company email.
First raise conversation: A prepared conversation about pay, usually timed with the review cycle, based on your evidence, your expanded scope and market data.
Focus blocks: Protected stretches of one to three hours without meetings or chat, used for the hardest thinking work.

Getting unstuck: A routine for when you are blocked: restate the problem, reproduce it, read the error fully, shrink the case, check logs and history, then ask.
Giving credit: Thanking people publicly or telling their manager when a teammate helped you or did great work.
Goals with your manager: Three or four written goals for the year, agreed with your manager, each with what success looks like and how you will show it.

Harassment and how to report it: Unwelcome behaviour such as bullying, discrimination or sexual harassment, and the channels to report it: manager, HR, an ethics line or an external authority.
Healthy boundaries: Clear, reasonable limits on when you are reachable, how much you take on and how you recover, agreed openly with your team.

Impostor feelings: The feeling that you were hired by mistake and will soon be found out, very common among new engineers in their first months.
Incidents and on-call as a junior: When production breaks, the team follows an incident process; juniors usually shadow on-call first, gather facts, communicate and escalate rather than fix alone.
IP, non-compete and side work clauses: Contract terms that give the employer rights to what you create, limit where you work after leaving, restrict side projects or ask you to repay training costs if you leave early.

Light pre-start learning: A short refresher on the basics of the stack named in the job description, Git and the terminal, rather than trying to master everything before you start.
Local development environment: Everything needed to build, run and test the code on your machine: tools, versions, access, secrets and seed data.
Low-context written updates: Messages that make sense on their own: what, why, current state, link and what you need, without assuming the reader was in the room.

Managing expectations: Saying clearly what you will deliver, by when and with what risk, and updating people as soon as that changes.
Mentors and your internal network: People beyond your manager who advise you, such as a senior engineer, a mentor in another team or your manager's manager.

Notice period and leaving well: The time you must work after resigning, set in your contract, plus the handover, documentation and goodbyes that leave a good impression.

Onboarding buddy: A teammate assigned, or chosen by you, to answer everyday questions about the code, tools and unwritten rules in your first weeks.
Onboarding plan: A written list of what you should learn and deliver in your first weeks and months, agreed with your manager.
One-on-one: A regular private meeting with your manager, usually weekly or every two weeks, that belongs to you as much as to them.

Payslip, tax and benefits: Your payslip shows gross pay, deductions such as income tax, social security or provident fund, and net pay; benefits include insurance, leave and allowances.
Performance review: A regular, often yearly or twice-yearly, assessment of your work against expectations, usually with a self-review, peer input and a rating.
Plain English at work: Short sentences, common words, one idea per message and a structure people can scan, useful whether English is your first language or not.
Prioritising your work: Knowing which of your tasks matters most this week, usually from your team's goals and your manager, and doing that first.
Probation period: An initial period, often three to six months, during which either side can end the job with shorter notice, followed by a confirmation.
Pull request description: The text on a pull request that explains what changed, why, how it was tested and anything the reviewer should look at closely.

Raising blockers early: Telling the right person as soon as something stops your progress or puts a date at risk, with what you tried and what would unblock you.
Reading an unfamiliar codebase: A deliberate way to learn a large codebase: start from entry points, follow one real feature end to end, read its tests and use git log to see how it changed.
Receiving code review: Reading comments as feedback on the code, answering each one, asking when a comment is unclear and pushing back politely with reasons when you disagree.
Receiving feedback well: Listening fully, asking for an example if unclear, thanking the person and saying what you will try, even when the feedback stings.
Remote and office etiquette: Everyday norms such as camera and mute habits, status and calendar hygiene, time zone awareness, quiet in shared spaces and respecting people's focus time.
Retrospective: A regular team meeting to discuss what went well, what did not and what to change in how the team works.
Reviewing other people's code: Reading a teammate's change for correctness, clarity and tests, and writing specific, kind comments that say whether each point blocks the merge.

Safe deploys and rollback: Ways to release without breaking production: testing on staging, hiding new code behind a feature flag, releasing gradually and knowing how to revert.
Self-review: Reading your own diff in the review tool before asking anyone else, as if you were the reviewer.
Small pull request: A change focused on one thing, small enough that a reviewer can understand it properly in one sitting.
Sprint cycle: A fixed period, often one or two weeks, that starts with planning what to do and ends with reviewing what was done.
Standup: A short daily meeting, often 15 minutes, where the team shares progress toward the current goal, the next step and anything blocking them.
Starter task: A small, low-risk ticket chosen so a new joiner goes through the whole path: branch, change, test, review, merge and deploy.
Status update: A short, regular written note on what you finished, what is in progress, what is blocked and what you need.

Testing your change: Adding or updating automated tests for what you changed, running them locally and making sure the CI checks pass before review.
Ticket and acceptance criteria: A ticket describes a piece of work; acceptance criteria are the checks that must be true for it to count as done.
Timebox before asking: A fixed amount of time you spend trying on your own before asking for help, agreed with your team and adjusted as you grow.

Verifying AI output: Reading, understanding, testing and owning every line an AI assistant suggests before it goes into a pull request.

When changing jobs early makes sense: Reasons that justify leaving within the first year, such as unpaid salary, harassment, no real engineering work or a clear offer of much better growth.
Work log and brag document: A running list of what you did, why it mattered and the evidence, such as links to pull requests and messages of thanks, added to weekly.
Working hours and leave: Your contracted hours, overtime rules, annual, sick and public holiday leave, as set by your contract, company policy and local labour law.
Working notes: A private running document of commands, answers, names, terms and decisions you meet each day.
Working with product and design: Product managers decide what to build and why; designers decide how it looks and behaves; engineers decide how to build it and flag trade-offs.