University assignments are small, well defined, written from scratch by one person and thrown away after grading. Professional software is large, unclear, shared, long-lived and never finished. The skills that matter shift from writing new code to reading, changing and communicating about existing code safely. Knowing the differences in advance makes the transition far less of a shock.
What people tell me
I did well in my programming courses and assignments, but when I started an internship or my first job, everything felt different. The requirements were vague, the codebase was huge, I had to use tools nobody taught us, and people cared about things like tests, reviews and deployments that never came up at university. I feel like my degree did not prepare me, and I am not sure what I should be focusing on.
A composite of the messages behind this question, with personal details left out.
Key takeaways
- At university you mostly write new code alone. At work you mostly read and change code that other people wrote.
- Assignments come with clear specifications. Real work starts with unclear problems that you help define.
- Code at work lives for years, so readability, tests and safe changes matter more than cleverness.
- Git, code review, CI, deployment and communication are core skills, not extras.
- Your degree gave you foundations. The gap is practice with real-world workflows, which you can build before graduating.
The shock is normal, and it is not your fault
Almost everyone feels this. You were good at the thing university measured, and then you arrived somewhere that measures something else. That does not mean the degree was useless. Data structures, algorithms, databases, networks and operating systems all show up in real work, often in quieter ways than exams suggested. What changes is everything around the code.
Once you see the differences clearly, the transition becomes a list of skills to practise rather than a vague feeling of being unprepared.
What actually changes
| At university | At work |
|---|---|
| Clear specification, marks for each requirement | Vague problem, part of the job is working out what to build |
| You write everything from scratch | You change code written by many people over years |
| A few hundred lines | Hundreds of thousands of lines, several services |
| Works on your machine, submit and forget | Must work in production, for real users, for years |
| Individual work, collaboration can be cheating | Collaboration is the job: reviews, pairing, asking for help |
| One correct answer for grading | Trade-offs between speed, cost, quality and risk |
| Deadline, then done | Ongoing maintenance, bugs and changes |
| Nobody reads your code except the grader | Everyone reads your code, including you in six months |
Each row is a skill you can learn.
Reading matters more than writing
The biggest surprise for most graduates is how little time goes into writing new code. A large share of the day is reading existing code, understanding why it is the way it is, and making a careful change without breaking anything else. University rarely practises this, because every assignment starts with an empty file.
You can practise it now: take an open source project, run it, trace how one feature works, and fix a small issue. It feels slow, and that is exactly the muscle you need.
Vague requirements are the job
At university, if the specification is unclear, it is the lecturer's problem. At work, clarifying it is partly your job. Good engineers ask:
- Who is this for, and what problem does it solve?
- What does done look like?
- What should happen in the edge cases, such as empty data, errors or slow networks?
- What is out of scope for now?
Asking these questions is not a sign that you are behind. It is a sign that you are thinking like an engineer.
The tools nobody taught you
Most graduates meet these for the first time at work. Getting comfortable with them before your first job gives you a real head start:
- Git beyond commit and push. Branches, rebasing, resolving conflicts, reading history.
- Pull requests and code review. Writing a clear description, responding to comments without taking them personally.
- Testing. Writing tests for the parts that matter and running them before pushing.
- CI and deployment. Understanding what happens between merging code and it reaching users.
- Debugging with real tools. Debuggers, logs and browser developer tools rather than print statements everywhere.
- Written communication. Updates, questions and short explanations in chat and tickets.
Code has a long life
Assignment code is thrown away after grading, so clever shortcuts cost nothing. Work code gets read, changed and debugged for years, often by people who never met you. This is why teams care about naming, small functions, consistency with existing patterns and tests. It is not bureaucracy; it is making life bearable for the next person, who is often you.
How to close the gap while still studying
- Build one project that you keep improving for months instead of several you abandon.
- Use Git with branches and pull requests on your own projects.
- Deploy something so real people can use it, and fix what breaks.
- Contribute a small fix to an open source project to experience a real review.
- Work on a group project where you divide the work like a team and review each other's code.
- Look for an internship, even a short one; the internships page is a good starting point.
If you are already in the job
Give yourself a few months. Ask for small tasks first, read the team's pull requests, keep notes on everything you learn, and ask questions that show what you have already tried. The feeling of being unprepared fades faster than you expect once you have shipped a few real changes.
If you are still stuck
Read What Actually Happens Between Your Pull Request and Production, Ten Books That Fill the Gap a CS Degree Leaves and What Actually Changes in Your First Two Years as an Engineer. If you want someone to look at your specific situation, join Sefism and, as a member, book a 1:1 session.
Was this answer helpful?
Read next
- What Actually Happens Between Your Pull Request and ProductionMost engineers learn CI/CD as a sequence of buttons rather than a system, which works right up until the pipeline goes red and nobody knows which stage failed or why it matters. The five stages walked through one at a time, what each is protecting you from, why builds pin their versions, the difference between rolling, blue green and canary releases, and the ten second skill of reading a failed stage.
- Ten Books That Fill the Gap a CS Degree LeavesYou can finish a computer science degree without reading a word of Kleppmann, Feathers, Fowler or Brooks, and leave knowing algorithms but not how software is actually built, debugged and maintained by teams. Ten books grouped by the problem each one solves, with the thing that matters most: when in your career each will actually land.
- What Actually Changes in Your First Two Years as an EngineerInterviews test the small part of the job that is easy to test, and the rest is learned on site. Reading code as the main skill, how to ask a question that costs nothing, why small shipped changes beat large ones in progress, using code review as the fastest teaching you will get, and the four things that actually get people promoted, three of which are not about writing code.
Your situation is not quite this one?
Members get written answers to their own questions, a roadmap built for them and feedback on their projects. Early access is open to X and Instagram followers and university students. Prefer to talk? A free call works too.