How software actually gets built, one small commit at a time

Software is a set of instructions that tells computers what to do. Engineers write those instructions as code. But typing new code is a small part of the job. Most of it is understanding problems, reading existing code, working with people, and changing things safely.

You'll spend far more time reading code than writing it. That's normal, and it's how everyone learns a codebase.

Who's on a software team

How work flows through the team

1. A customer has a need or a problem.
2. Product turns it into a ticket and decides when it gets done.
3. Engineers design and build it, and review each other's code.
4. QA tests it. It's released to customers.
5. Customers use it, give feedback, and the cycle repeats.

A typical day

What's expected of you in your first months

Nobody expects you to know everything. They expect you to learn steadily, ask questions, be honest about progress, and ship small, reliable changes. That's it. Speed comes later, by itself.

The terminal (also called the command line or shell) is a window where you control the computer by typing commands instead of clicking. Git, Maven, Python scripts and the AWS CLI all run here, so it's worth getting comfortable early.

• Mac: the Terminal app (or iTerm2). It runs a shell called zsh.
• Windows: use Git Bash or WSL so commands match this guide. PowerShell uses different commands.
• IntelliJ and VS Code also have a built-in terminal at the bottom of the window.

Folders and paths

Your computer is a tree of folders (also called directories). The terminal is always "standing" in one folder, the current directory. A path describes where something is:

• ~ is your home folder, e.g. /Users/you.
• . is the current folder, and .. is the folder above it.
• /Users/you/workorder-service is an absolute path (from the very top); workorder-service/src is a relative path (from where you are).

Commands to know

Keyboard shortcuts that save time

• Tab finishes file and folder names for you. Press it constantly.
• ↑ brings back the previous command.
• Ctrl+C stops a running command (like a server or a stuck script).
• Ctrl+R searches your command history.
• Names with spaces need quotes: cd "SWE tutorials".

Your first week is mostly about getting access, installing tools, and getting the project running on your laptop. It's slow for everyone, and that's fine. Here are the tools you'll likely use, and a checklist to track your progress.

Every feature or bug fix you touch follows roughly the same path. Teams use different tools, but the shape stays the same. Once you know the path, you always know what comes next and who to ask.

This path is often called the software development lifecycle (SDLC). You'll hear the word in interviews and planning meetings. It just means "the steps work goes through."

What "done" means

Many teams agree on a Definition of Done: a checklist every ticket must pass before anyone calls it finished. A typical one:

• Code is reviewed and approved by at least one teammate.
• Automated tests are written and passing.
• Documentation (README, doc comments, API docs) is updated if behaviour changed.
• The change is merged and deployed to at least a test environment.
• The ticket's acceptance criteria are all met.

If your team has one, find it in the wiki and keep it open while you work.

Agile is an approach where teams build software in small pieces, show it often, and adjust based on feedback. It replaced the old style of planning everything for a year and delivering it all at the end.

Scrum is the most common way to do Agile. Work happens in sprints, fixed cycles usually two weeks long. Each sprint has the same set of meetings, called ceremonies.

Anatomy of a good ticket

Tickets are often written as user stories: "As a type of user, I want something, so that a benefit." Below the story are acceptance criteria, the testable conditions that prove the work is done.

Story points and estimates

Teams estimate effort in story points (often 1, 2, 3, 5, 8, 13) instead of hours. Points describe relative size and uncertainty: a 5 is "bigger and less clear than a 2". Your early estimates will be off. Everyone's are. Estimate honestly and say what you're unsure about.

Your standup update

The daily standup is 15 minutes, not a status report to a boss. Say what you did, what you'll do, and anything blocking you. Mentioning a blocker early is the most useful thing you can say.

Atlassian makes three tools that many teams use every day, and they're linked together:

• Jira holds the work: tickets, sprints and boards.
• Confluence holds the knowledge: setup guides, architecture, runbooks, meeting notes.
• Bitbucket holds the code: repositories, pull requests and pipelines (see the Bitbucket chapter).

The glue is the issue key, like FSM-1234. Put it in your branch name, commit messages and pull request title, and Jira automatically shows the branch, commits and PR on the ticket's Development panel. Your manager can see progress without asking you.

Issue types

Finding tickets with JQL

JQL (Jira Query Language) is search for Jira. Paste these into Filters → Advanced issue search, then save the useful ones.

Smart commits

If your Jira admin has enabled them, commit messages can comment on a ticket or log time:

Using Confluence well

• Search before asking. Look for pages like "Local setup", "Onboarding", "Architecture", "Runbook" and "Release notes".
• Watch the pages you depend on (the eye icon) so you're notified when they change.
• Fix what's out of date. If a setup step was wrong, edit the page. New joiners are the best at spotting stale docs.
• Link both ways. Paste a Jira link into a Confluence page and it shows the live ticket status; link the page back from the ticket.
• Write things down for the next person. Solved something tricky? A short how-to page saves the next joiner a day.

Git is a version control system. It remembers every saved version of a project and lets many people change the same code without overwriting each other's work. Bitbucket (used in this guide's examples), GitHub and GitLab are websites that host a shared copy of that history and add pull requests, reviews and automation on top. The Git commands are identical on all of them.

Three words, explained simply

• Repository (repo): a project folder that Git is watching. It holds your files plus a hidden .git folder where every past version is kept. When people say "clone the repo", they mean "download the project and its history".
• Commit: a snapshot of your changes with a short message ("Fix crash when cart is empty"), your name and the time. Each commit gets a unique ID like a1b2c3d, so anyone can point to it.
• Remote: the copy of the repo on Bitbucket. Your laptop and Bitbucket each have a full copy; push and pull keep them in sync.

Why not just save files normally? Because a normal save overwrites the old version. With Git you can always answer "what changed, who changed it, when, and why?", and you can go back if the new version is broken.

First-time setup

You do this once per computer, then once per project.

The four places a change lives

Most beginner confusion comes from not knowing which place a change is in.

What never goes into Git: .gitignore

A file called .gitignore lists things Git should pretend don't exist. Check it before your first commit in any project.

Reading history

• git log --oneline lists recent commits, one per line.
• git diff shows changes you haven't staged. git diff --staged shows what you're about to commit.
• git show a1b2c3d shows one commit in full.
• git blame file.js shows who last changed each line and in which commit. Use it to find context, not culprits.

main is the branch everyone trusts. It should always build and pass its tests. Nobody writes new work directly on it. You create your own branch, make your commits there, and bring them back into main through a pull request.

Most repos protect main with branch protection rules: it can't be pushed to directly, and a pull request needs an approval and passing checks before it can merge. If a push to main is rejected, that's the rule working, not you breaking something.

Merging just means taking the commits from one branch and adding them to another. When your feature branch is merged into main, your work becomes part of the official code that everyone builds on and that eventually ships to customers.

Common branch names

Most teams follow a naming pattern so anyone can tell what a branch is for. Check your repo's CONTRIBUTING.md or ask your lead for the exact rules.

Two common strategies optional

• Trunk-based / GitHub Flow. Short feature branches off main, merged back within a day or a few days. Simple, and the most common today.
• Git Flow. Adds develop, release/* and hotfix/* branches. Used by teams that ship versioned releases on a schedule, such as mobile apps.

The daily routine

A merge conflict happens when two branches changed the same lines, and Git can't tell which version is right. Git stops and asks a human. Nothing is broken and nothing is lost. Every engineer resolves conflicts regularly.

Git marks the conflicting part of the file with three markers:

• <<<<<<< HEAD: start of the version on the branch you're on.
• =======: the divider.
• >>>>>>> other-branch: end of the incoming version.

Your job: edit the file so it contains the correct final code, delete the three marker lines, then stage and commit.

Resolving step by step

1. Run git status. It lists files under "both modified".
2. Open each file. Most editors (VS Code, IntelliJ) highlight conflicts and offer "Accept current / incoming / both" buttons.
3. Decide what the final code should be. Often it's a mix of both sides.
4. Remove all marker lines. Run the app and tests.
5. git add each fixed file, then git commit (or git rebase --continue during a rebase).
6. Unsure which side is right? Ask the person who wrote the other change. git log tells you who.

Want to give up and start over? git merge --abort puts everything back exactly as it was before the merge.

Git almost never truly loses committed work. Most mistakes have a calm, two-command fix. Pick a situation below to see it.

Revert vs. reset

• git revert makes a new commit that undoes an old one. History stays intact. Safe on shared branches.
• git reset moves your branch backwards, as if commits never happened. Fine for local commits nobody else has. Dangerous once pushed.

Six months from now, someone will read your commit to figure out why a line exists. That person might be you. A good message saves them an hour.

A useful pattern: start with a verb, say what changes, keep the first line under about 70 characters. If the reason isn't obvious, add a blank line and a short paragraph explaining why.

Conventional Commits

Many teams prefix messages with a type. Tools then generate changelogs and version numbers automatically.

What a pull request (PR) is

A pull request (GitLab calls it a merge request) asks the team: "please review my branch and merge it into main." It's where code review and automated checks happen. A good description answers three questions:

Receiving review comments

Review comments are about the code, not about you. Senior engineers get lots of comments too. Reply to each one: change the code, or explain your reasoning politely. "Good catch, fixed in a3f9c1" is a perfectly good reply.

Reviewing other people's code

You'll be asked to review soon, even as a junior. Your fresh eyes are valuable. Ask questions freely. A simple checklist:

• Does it do what the ticket asks? Did I try it?
• Are there tests? Would they catch a regression?
• Are names clear? Could I understand this in six months?
• What happens with empty, null or very large input?
• Any passwords, keys or personal data in the diff?

Label comments so the author knows how important they are: nit: (tiny, optional), question: (I want to understand), suggestion: (consider this), blocking: (must fix before merge). Always say what you liked, too.

Bitbucket Cloud is where many teams keep their repositories, pull requests and pipelines. It's tightly linked with Jira, so if your team uses both, most of your daily flow starts from a ticket and ends with a merged PR that updates that ticket.

Merge strategies

When you click Merge, Bitbucket asks how. Your team probably has a default; use it.

Signing in from the command line

• SSH (recommended): generate a key once, add the public half to Bitbucket under Personal settings → SSH keys, then clone with the git@bitbucket.org:… URL. No passwords after that.
• HTTPS: use an API token from your Atlassian account settings, never your Atlassian password. Older guides mention "app passwords"; Atlassian has replaced them with API tokens.
• Never share your private key (id_ed25519, the file without .pub) with anyone, including in tickets or chat.

Bitbucket Pipelines

Your repo's CI lives in a file called bitbucket-pipelines.yml at the root. It decides which builds and tests run on each PR and branch. The shipping chapter walks through an example. When a pipeline fails, click into the failed step and read the log from the first red line.

Most enterprise backend services are written in Java, usually with Spring Boot and built with Maven or Gradle. You don't need to know all of Java on day one. You need to find your way around a service and make a safe change.

What is Spring Boot?

A framework is ready-made code that handles the boring, repetitive parts of an app, so you only write the parts specific to your business. Spring Boot starts a web server, turns incoming HTTP requests into Java method calls, turns Java objects into JSON responses, and connects to databases. You write the logic: "when a work order is created, check the asset exists and assign a technician".

Two Spring ideas confuse almost every beginner, so here they are in plain words:

• Annotations are the @Something labels above classes and methods. They're instructions to Spring. @GetMapping("/{id}") means "call this method when a GET request arrives at this path".
• Dependency injection means you don't create the objects you need yourself. You list them in your constructor, and Spring hands them to you. That makes it easy to pass in a fake version during tests.

How a typical service is laid out

The three layers

A request flows down through the layers and the answer flows back up. Each layer has one job, so you always know where a change belongs.

Core Java ideas you'll see daily

The classic Java gotcha: comparing strings

Handling exceptions

An empty catch block is the most common Java mistake in code reviews. It hides the error, so the bug shows up later somewhere confusing.

Build commands

Teams keep Python scripts for one-off and repeated jobs: fixing bad data, exporting reports, calling AWS, running migrations. You'll often be asked to run a script someone else wrote. Doing that safely is a skill.

What a well-behaved script looks like

Read a script before you run it. Good ones explain themselves, require you to choose an environment, and support a dry run.

Errors you'll hit, and what they mean

A relational database stores data in tables. Each row is one record, each column one field. Every table has a primary key (a unique ID). A foreign key is a column that points to another table's primary key. That's how tables relate.

For example, a work_orders table might have a technician_id column. The value 58 in that column means "this work order belongs to the technician whose id is 58 in the technicians table". Instead of copying the technician's name into every work order, you store their ID once and look it up when needed.

You'll also see NULL, which means "no value at all", not zero and not an empty string. A work order with technician_id = NULL simply hasn't been assigned yet. To find those, write WHERE technician_id IS NULL; = NULL never matches anything.

The statements you'll use 90% of the time

Joins: combining tables

A JOIN matches rows from two tables using a shared value, usually a foreign key. The join type decides what happens to rows that have no match.

Indexes, briefly

An index is like the index at the back of a book: it lets the database find rows without reading the whole table. Columns you filter or join on often (technician_id, status) usually need one. If a query is slow, run EXPLAIN before it to see whether an index is used.

MongoDB stores documents: JSON-like objects that can contain nested objects and arrays. Documents live in collections. Two documents in the same collection don't have to have exactly the same fields, which makes MongoDB good for data whose shape varies, such as forms that differ per customer.

What is JSON?

JSON is a simple text format for data that both people and programs can read. You'll see it everywhere: in MongoDB, in API requests and responses, and in config files. It has only a few building blocks:

• { } an object: a set of "name": value pairs, like one work order.
• [ ] an array: an ordered list, like a list of notes.
• Values are text in quotes ("OPEN"), numbers (2), true/false, null, or another object or array.

A MongoDB document is basically a JSON object, with a few extra types such as dates and IDs.

SQL or MongoDB?

• SQL fits data with clear relationships and strict consistency: billing, inventory, users and permissions.
• MongoDB fits flexible or nested data read as a whole: a work order with its notes, photos and custom form answers.
• Many systems use both. Ask which data lives where in your services.

A method-level comment (also called a doc comment or docstring) sits right above or inside a function. It tells other developers how to use the function without reading its code. A complete one covers:

• Summary: one sentence on what the function does.
• Parameters: what each input means, its units, and whether it can be empty or null.
• Return value: what comes back and any guarantees ("never negative").
• Errors: which exceptions it throws and when.
• Side effects (if any): sends an email, writes to the database, changes a global.

Editors read these comments. When a teammate hovers over your function in their IDE, your comment pops up. Tools like Javadoc, Sphinx, JSDoc and DocFX also turn them into documentation websites.

Explain why, not what

The code already shows what happens. Comments are most useful when they explain intent, assumptions or surprises the code can't express.

Other kinds of documentation

Code is read far more often than it's written. "Clean code" just means code the next person can understand and change safely. These principles have names you'll hear in reviews.

A small refactor, before and after

Same behaviour, much easier to read and change.

What changed: a name that says what the function does, constants instead of magic numbers, full property names, an early exit for missing input (the old version silently returned undefined), and no deep nesting.

An automated test is code that runs your code and checks the result. Tests let you change things confidently: if you break something, a test turns red within seconds instead of a customer finding it next week.

In plain words, a test says: "given this situation, when I call this code, then I expect this result." For example: given an adult customer in India with a price of 100, when I calculate the price, then I expect 90. If someone later breaks the discount logic, that test fails immediately and tells them exactly what broke.

Teams usually think about tests as a pyramid: many small fast tests at the bottom, a few slow realistic ones at the top.

Anatomy of a unit test: Arrange, Act, Assert

These tests cover the priceFor function from the clean code chapter. Notice one test per behaviour, including the error case.

Words you'll hear

Debugging is a skill with a method, not a talent. When something breaks, work through these steps in order:

1. Reproduce it. Find exact steps that make the bug happen every time.
2. Read the whole error message. Slowly. It usually tells you what and where.
3. Narrow it down. Which file, function, line? Which input triggers it?
4. Form a guess, then test it. "I think items is empty here." Add a log line or breakpoint to check.
5. Fix the cause, not the symptom. Wrapping it in try/catch to hide the error is not a fix.
6. Add a test that fails without your fix and passes with it.

Reading Java exceptions

• Java prints the error message first, then the at … lines. The top at line is where the exception was thrown. (Python is the opposite: the error is at the bottom.)
• Skip frames from org.springframework, java., jdk. and other libraries. Find the first frame in your own package.
• Look for Caused by: further down. The last "Caused by" is usually the real root cause; the top exception is often just a wrapper.
• Modern Java explains NullPointerExceptions: "because the return value of getCity() is null" tells you exactly what was missing.

Debugger basics in IntelliJ IDEA

Start the app with the bug icon (Debug) instead of Run, then click in the left margin next to a line number to add a breakpoint.

Right-click a breakpoint to make it conditional, e.g. stop only when id == 88213. That's how you catch one bad record among thousands.

Tools that help

• Debugger with breakpoints. Pause the program on a line and inspect every variable. Learn your IDE's debugger in week one; it's the biggest time saver.
• Logging. console.log / print is fine locally. Remove it before committing, or use the project's real logger.
• Rubber duck debugging. Explain the problem out loud, line by line, to anyone or anything. You'll often spot the bug mid-sentence.
• git bisect. Something worked last week and doesn't now? Bisect binary-searches your commits to find the one that broke it.
• Logs for deployed code. You can't attach a debugger to production. Use the request ID and CloudWatch (the AWS chapter).
• Search the exact error message in quotes, along with the library name.

Big-O notation describes how the work your code does grows as the input grows. It ignores exact timings and asks: if the list is ten times bigger, is the code ten times slower? A hundred times? Not slower at all?

Here's a story that happens on real teams. A developer writes a screen that compares every work order with every other work order to find duplicates. With 100 work orders in the test database, that's 10,000 comparisons: instant. A big customer has 200,000 work orders. That's 40 billion comparisons, and the screen never loads. Nothing was "wrong" with the code; it just didn't scale. Big-O is the tool for spotting that in advance.

Picking a data structure

Most importantly: write clear, correct code first. Optimise only when something is measurably slow, and measure again after.

Most software you'll work on follows the client–server pattern. A client (browser, mobile app) asks for something. A server (backend) does the work, usually reading or writing a database, and sends back an answer. They talk through an API: an agreed list of requests the server accepts.

• API (Application Programming Interface) is a contract: "send me this, in this format, and I'll send you that back." The mobile app doesn't need to know how the server works inside; it only needs the contract.
• An endpoint is one specific address in the API, like /api/work-orders. Each endpoint does one kind of job.
• Requests and responses usually carry data as JSON (explained in the MongoDB chapter).
• HTTP is the set of rules for how requests and responses are written and sent. HTTPS is the same, encrypted so nobody in between can read it.

What a request and response look like

Every request has a method (what to do), a path (to what), headers (extra info such as who you are) and sometimes a body (the data, usually JSON). The response has a status code, headers and usually a body.

GET, POST, PUT, PATCH, DELETE

The method says what kind of action the request is. Together they cover CRUD: Create, Read, Update, Delete. Click each one to see a real request and response.

"Same result if sent twice" is called idempotent. It matters for field apps on bad mobile connections: if the app retries a request, retrying a PUT is harmless, but retrying a POST can create duplicates unless the API guards against it.

Tools for calling APIs

• Postman or Insomnia: save requests in collections and share them with the team. Ask if your team has a shared collection.
• curl in the terminal: quick, and easy to paste into a ticket.
• IntelliJ HTTP Client: write requests in a .http file next to the code.
• Swagger UI / OpenAPI: many Spring Boot services publish interactive API docs, often at /swagger-ui.html.

Status codes worth memorising

The first digit tells you who to look at: 2xx success, 4xx the client sent something wrong, 5xx the server failed.

Databases in one paragraph each

• Relational (SQL), see the SQL chapter: PostgreSQL, MySQL, SQL Server. Data in tables with rows and columns, linked by IDs. Strong rules keep data consistent. The default choice for most business apps.
• NoSQL, see the MongoDB chapter: MongoDB (documents), Redis (key–value, often a cache), DynamoDB. Flexible shapes, scales easily for specific access patterns.
• Migrations: versioned scripts that change the database structure (add a column, a table). They live in the repo and run in order, so every environment's database matches the code.

AWS (Amazon Web Services) rents out servers, databases, storage and hundreds of other services, so companies don't run their own data centres. If your services run there, then when something goes wrong in dev, staging or production, their logs in CloudWatch are usually the first place you look.

AWS services you'll hear about

Most teams use a subset of these. Ask which ones, and in which accounts and regions.

• An account is a separate, walled-off area of AWS. Companies often have one account for dev, one for staging and one for production, so a mistake in dev can't touch production.
• A region is a physical location with data centres, like us-east-1 (Virginia) or ap-south-1 (Mumbai). Your services, and their logs, live in a specific region.
• A container is your app packaged together with everything it needs to run (the right Java version, settings, libraries), so it runs the same on any machine. Docker builds containers; ECS or EKS run many of them.

Signing in

Most companies sign you in through single sign-on (IAM Identity Center, formerly AWS SSO) and an access portal, where you pick an account and role. For the command line:

How CloudWatch Logs is organised

• Log group: all logs for one service or function, e.g. /ecs/workorder-service or /aws/lambda/send-notifications.
• Log stream: one source inside the group, usually one container or server instance. A service with 4 containers has 4 streams.
• Log event: one line, with a timestamp.

In the console: open CloudWatch → Logs → Log groups, pick the group, then use Search all log streams to search every container at once.

Logs Insights: querying logs like a database

CloudWatch → Logs Insights lets you query one or more log groups. Choose the time range at the top, then run queries like these:

From the terminal

Tips that save hours

• Seeing no logs at all? Check the account, the region (top right of the console) and the time range. These three cause most "the logs are empty" moments.
• Timestamps are usually in UTC. A problem at 3:10 PM in India (IST, UTC+5:30) appears at 09:40 UTC. The console has a UTC/local time toggle.
• Follow the request ID (also called a correlation or trace ID). It ties together every line from one request, even across services.
• Not every ERROR is your bug. Busy services always have some background errors. Look for errors that match the time and the request.
• Treat production logs as sensitive. They can contain customer names and addresses. Don't paste them into public channels; share the request ID and a short summary instead.

Code passes through several copies of the system, called environments, before reaching real users. Each one catches different problems.

CI/CD

In plain words: every time you push code, a robot grabs it, builds it from scratch, and runs all the tests. That's CI (Continuous Integration). If everything passes and the code is merged, another robot can deploy it, first to staging, then to production. That's CD (Continuous Delivery or Deployment). The robots never get tired or forget a step, which is why teams trust them more than manual checklists.

This guide's examples use Bitbucket Pipelines; others include GitHub Actions, GitLab CI, Jenkins and AWS CodePipeline. The pipeline is defined in a file in the repo, so you can read exactly what runs.

Shipping safely

• Feature flags let you merge unfinished or risky code switched off, then turn it on for 1% of users, then everyone. Turning it off is the fastest rollback.
• Rollback means redeploying the previous version when a release goes wrong. Fix forward later, calmly.
• Semantic versioning (MAJOR.MINOR.PATCH, e.g. 2.4.1): bump PATCH for fixes, MINOR for new backwards-compatible features, MAJOR for breaking changes.

Logs, metrics and alerts

Once code is live, you can't attach a debugger. You rely on what it records.

Metrics are numbers over time (requests per second, error rate, response time), shown on dashboards like Grafana or Datadog. Alerts page the on-call engineer when a metric crosses a threshold.

When things break: incidents

Production problems are called incidents. Healthy teams run blameless postmortems afterwards: they ask "how did our process let this happen?" not "whose fault was it?". If you cause an outage (everyone does eventually), say so quickly. Speed of reporting matters far more than the mistake.

Security isn't only the security team's job. Most real breaches start with an everyday mistake. A few habits prevent most of them.

1. Never commit secrets

Passwords, API keys, tokens and private keys go in environment variables or a secrets manager (AWS Secrets Manager, Vault), never in code. Keep a .env.example with fake values in the repo, and the real .env in .gitignore.

2. Never trust input

Anything from a user, URL, form or other system could be malicious. Validate it on the server, even if the frontend already checks it. The classic example is SQL injection:

3. More habits

• Authentication vs authorization. Authentication: who are you? Authorization: are you allowed to do this? Check both on the server for every request. Hiding a button is not security.
• Least privilege. Give users, services and API keys only the access they need.
• Escape output. Displaying user text as raw HTML enables XSS (cross-site scripting). Frameworks like React escape by default; avoid bypassing it.
• Keep dependencies updated. Most vulnerabilities live in outdated libraries. Don't ignore Dependabot or npm audit warnings.
• Don't log sensitive data. No passwords, card numbers or full personal details in logs.
• Never store plain-text passwords. Use a proper hashing library (bcrypt, Argon2). Never write your own crypto.

The OWASP Top 10 is the standard list of the most common web security risks. Skim it once this year.

Most of the job isn't clever algorithms. It's a handful of habits repeated every day. None of these need talent, only practice.

How to ask a good question

Include what you're trying to do, what you expected, what actually happened (the exact error), and what you've already tried.

Your first 90 days

• Weeks 1–2: get the project running, read the README and the architecture docs, ship a tiny fix (a typo, a doc update).
• Weeks 3–6: take small tickets end to end. Review others' PRs to learn the codebase.
• Weeks 7–12: take a medium feature. Join on-call shadowing if your team has it. Write down three things you'd improve.

Beyond Git