Reading · Software Technology
How this maps to industry practice
The course workflow next to real companies, from startups to enterprises: what is the same everywhere, what changes with size, trunk-based vs Gitflow-style branching, and the terms you will hear as an intern.
This page is context, not rules. It places the course's workflow next to how software companies actually work – from a five-person startup to an enterprise with thousands of developers – so you know which habits transfer directly to an internship and which ones each company does its own way.
What is the same everywhere
The course takes these one-to-one from industry practice. If they come naturally to you, you won't have to relearn them in your first job:
| Practice | In this course | In a company |
|---|---|---|
| Task tracking | GitLab issues, board, milestones | Jira, GitLab, Azure DevOps, Linear; a sprint board |
| Issue → branch → MR → merge | required | required; the branch name usually carries the ticket key (PROJ-1234) |
| Protected main branch | main and develop | main and release branches; not even the tech lead pushes directly |
| Code review on every MR | 1 approval | 1–2 approvals; in large companies CODEOWNERS name mandatory reviewers |
| CI on every MR | build, tests, formatting, static analysis | the same, plus security scans and integration tests – sometimes hours |
| Green pipeline before merge | required | required – a red main means everyone stops and fixes it |
| Formatter and linter | Spotless / dotnet format, SpotBugs / Roslyn | the same, or Checkstyle, ESLint, Prettier, SonarQube |
| Unit tests and coverage | high coverage of the model | 70–90% expected, but what the tests check matters more than the number |
| Versioned releases | v1.0 tags, a Releases page | Semantic Versioning, release notes, often generated |
| Status meeting | weekly session: done / next / blocked | daily stand-up, 10–15 minutes, the same three questions |
| Definition of Done | six points in the contribution rules | the same idea, extended per team |
What changes with company size
The practices stay; their weight changes (Fig. 1). Startups optimise for speed, large companies for safety and traceability.
| Startup | Mid-size | Enterprise | |
|---|---|---|---|
| Merge method | squash, for a clean history | squash or merge commit, per team | regulated; often squash plus Conventional Commits for the changelog |
| Who merges | the author | the author, or auto-merge when everything is green | a merge queue |
| Security | secret scanning | + SAST, dependency scanning | + SBOM, licence compliance, penetration tests, audit logs |
| Documentation | README + wiki | architecture decision records, Confluence | all of that + compliance documents |
Two branching styles
The course uses a Gitflow-style model: a develop branch for integration, release branches, tags on main. Many large web companies use trunk-based development instead: everyone merges tiny branches into main daily, and unfinished features are switched off with feature flags (Fig. 2).
Milestone demos are fixed release points, so the Gitflow-style model fits the course. The habits behind both are the same: small branches, frequent merges, a protected main line, a green pipeline.
What the course leaves out on purpose
These exist in real companies, but for three people and thirteen weeks they cost more administration than they return:
- Conventional Commits (
feat:,fix:…) – the issue key ties a commit to its task, which is what traceability needs; the type is already in the branch name. They can be combined:ABC-12: feat: …. - Squash merges – they would erase the individual commits that grading partly relies on. Common in companies, switched off here.
- Two approvers, CODEOWNERS, automatic changelogs – meaningless with three people.
- Environments and deployment – a desktop game has nothing to deploy. The packaged build on the Releases page is the equivalent.
Terms you will hear
- Trunk-based development
- Everyone merges into main daily; branches live a day or two; unfinished work hides behind feature flags.
- Feature flag
- A configuration switch that turns finished code on or off at runtime, so it can be merged before the feature goes live.
- Conventional Commits
- feat:, fix:, chore:, docs: prefixes, used to generate changelogs and version numbers automatically.
- Semantic Versioning
- MAJOR.MINOR.PATCH – breaking change / new feature / fix. Mandatory for libraries, advisable for applications.
- CODEOWNERS
- A file that says who owns which folder; their approval is required. Useless for three, essential for thirty.
- Merge queue / merge train
- Approved MRs are re-tested and merged one by one on the latest main, so two separately green MRs can't turn main red together.
- Monorepo
- Several applications and libraries in one repository with shared CI. Your project is one repository of a "polyrepo".
- ADR
- Architecture Decision Record: the question, the options, the choice and why. Your design wiki is an early form of it.
- DoR / DoD
- Definition of Ready (when a task can start) and Definition of Done (when it is finished). The course uses only the DoD.
- Story points, velocity
- Relative estimates of tasks and the team's capacity per sprint.
- Retrospective
- At the end of a sprint: what went well, what didn't, what to change. Worth 15 minutes after each milestone.
- On-call, incident, postmortem
- Someone is on duty when production fails; afterwards a blameless write-up says what happened and how to prevent it.
What a course can't simulate
- Real users and operations. No production, no monitoring, no customer complaints. The instructor as product owner covers part of it.
- Long-lived code. In a company code lives for five to ten years and others live with your decisions. In thirteen weeks that doesn't show, which is why documentation and clean code can feel pointless. They aren't.
- Many teams on one code base. API contracts, compatibility, deprecation. Your model–view separation is a miniature of it.
- Time and money pressure at once. The course has deadlines, but no paying customer.
What you take with you
An intern meets all of these in the first weeks: opening a branch from a ticket, writing a meaningful commit, opening an MR with a description, taking a review without taking offence, reading a red pipeline, not pushing to main, not committing secrets – and knowing that "done" isn't when the code runs, but when it is merged and green.
If any of it is still shaky, the issue lifecycle cheat sheet and the code review guide are the two pages to practise with.