A first programming unit looks like it is about syntax, and for the first few weeks it is. Then the unit description names something that is not syntax at all: the model of addressable memory.
A first programming unit looks like it is about syntax, and for the first few weeks it is. Then the unit description names something that is not syntax at all: the model of addressable memory. That idea is what turns a set of remembered patterns into an understanding of why code behaves the way it does, and students who never build it can pass early exercises and then find that nothing after a certain week quite lands. Below is how MAAS mentors read a unit built like this.
Author: MAAS Editorial Team · Reviewed by a MAAS subject mentor
Last updated: 2026-08-19
Category: writing-tips
First, confirm which INFO1110 you are enrolled in
Direct answer: This guide describes the University of Sydney unit INFO1110 Introduction to Programming, a 6 credit point unit taught by Computer Science within the Faculty of Engineering, offered in both Semester 1 and Semester 2 of 2026 at Camperdown and Darlington.
Evidence: The unit has no prerequisites, no corequisites and no assumed knowledge, but it carries a long prohibition list: INFO1910, INFO1103, INFO1903, INFO1105, INFO1905 and ENGG1810. That list is the practical detail most likely to affect you, because several of those are units a student might otherwise take alongside it.
Example: A student who had already completed ENGG1810 in an engineering stream planned to take INFO1110 as a refresher before second-year computing. The plan failed on enrolment rather than on merit, and it cost him a semester of sequencing.
What does "no assumed knowledge" actually mean for you?
Direct answer: It means the unit starts from zero and it does not mean the room does. A unit with no prerequisites collects students who have written code since school alongside students who have never opened a terminal, and the two groups fail in different ways.
Evidence: Students with prior experience tend to arrive fluent in one language's habits and slow to adopt the unit's conventions, and coding style is an assessed outcome here rather than a matter of taste. Students with no experience tend to lose time on the mechanics of running things at all, which is invisible to the syllabus and expensive in the first fortnight.
Example: A student who had built websites found the early weeks trivial and stopped attending labs, then hit recursion with no habit of asking for help and no relationship with a tutor. A classmate with no background attended everything, asked constantly, and finished ahead of him. The advantage was real at week two and gone by week eight.
Why does the middle of the unit get suddenly harder?
Direct answer: Because programming concepts are unusually dependent on one another, so a gap does not stay local. Miss how functions pass values and you will not properly understand recursion, and recursion is not a topic you can skip and return to.
Evidence: This is a documented pattern rather than a personal failing. Robins (2010) describes a learning edge momentum effect to explain why introductory programming produces an unusual grade distribution with more failures and more high marks than most units: success in acquiring one concept makes closely related concepts easier, and failure makes them harder, so small early differences compound. He also reviews decades of research and finds little support for the older idea that people simply divide into programmers and non-programmers.
Example: A student who could not explain what happened to a list passed into a function was, three weeks later, unable to debug a recursive routine. The recursion was not the problem. The unexamined assumption about what a function receives was, and it had been sitting there quietly since week four.
What to do about it. Treat any confusion as urgent rather than as something to catch up on later. In most units a shaky week costs you that week's marks; in this one it costs you the weeks that build on it.
The model of addressable memory
Direct answer: The unit description lists it beside data types, control flow, iteration, functions and recursion, which places a mental model of the machine on the same footing as the language features. It is the answer to why code does what it does, rather than what to type.
Evidence: du Boulay (1986) set out the difficulties novices face in learning to program, and a central one is the absence of a workable model of the machine that the program runs on. Without it, a learner is memorising the behaviour of constructs case by case, which works until the cases multiply. With it, behaviour becomes something you can predict rather than recall.
Example: Asked why changing a list inside a function affected the caller's list while reassigning a number did not, a student answered that lists are special. That is a memorised case. The stronger answer talked about what the name refers to and what is actually passed, which explains that behaviour and also predicts several others the student had not yet met.
| What the unit assesses | What it looks like when it is working | Where students under-deliver |
|---|---|---|
| Coding style conventions | Code a marker can read without effort | Treating style as decoration |
| Algorithmic design | A plan before there is any code | Typing first and designing by trial |
| Procedural construction and data types | Choosing the right structure for the job | Using a list for everything |
| Recursion | Trusting the recursive call | Trying to trace every level in your head |
| Testing and debugging | Finding your own bugs systematically | Changing lines until output looks right |
Why is coding style assessed at all?
Direct answer: Because the learning outcomes list coding style conventions as a competency in their own right, alongside algorithmic design and the rest. In a unit this size the marker is reading your reasoning through your code, and code that is hard to read hides whether the reasoning was sound.
Evidence: Style here means the conventions the unit teaches rather than personal preference: names that say what a thing is, functions that do one job, structure that matches the problem. Students arriving from self-taught backgrounds often have habits that worked alone and stop working the moment somebody else has to follow them.
Example: Two submissions solved the same task correctly. One used single-letter names throughout and a single forty-line function. The marker could confirm the output and could not confirm the design, and the mark reflected that. The other student solved it no more elegantly but made the design legible, which is a different skill from making it work and is separately assessed.
The self-check. Read your own code a week later without running it. If you cannot follow it, neither can a marker, and neither will you during an exam when you are asked to modify it under time pressure.
Algorithmic design comes before typing
Direct answer: The outcomes separate designing an algorithm from constructing a program, and that separation is a working instruction. The design step happens away from the keyboard, in words or on paper, and it is where most of the difficulty in a task actually lives.
Evidence: The unit description frames the skill as converting practical problems into computational solutions. Conversion implies two representations: the problem as stated, and the problem as something a machine can execute. Students who start typing immediately are trying to do the conversion and the construction at once, which is why their code drifts.
Example: Given a task about processing records, a student wrote code for twenty minutes, deleted it, and wrote different code. A classmate spent five minutes writing four steps in plain sentences and then implemented them in fifteen. The second student was not faster at coding. She had separated two problems that the first was solving simultaneously.
Testing and debugging are content, not chores
Direct answer: The unit description names competency in software development practices including testing and debugging as part of what it develops. These are taught skills with method, not the administrative tail of writing code.
Evidence: Debugging by systematic narrowing means forming a hypothesis about where the fault is, designing the smallest observation that would confirm or eliminate it, and repeating. Debugging by editing until the output looks correct is a different activity that happens to share a name, and it produces code that passes the example and fails the marker's test.
Example: A student whose function was wrong for empty input changed three lines and got the sample working. He never learned which of the three had mattered, so the same fault reappeared in the next task in a different disguise.
Write the test before you fix the bug. A test that fails for a known reason and then passes tells you what you changed; an output that looks better tells you almost nothing.
Six things worth doing in this unit
- Check the prohibition list before enrolling, especially if you have done ENGG1810 or any of the INFO19xx units.
- Go to labs in the first three weeks even if the material is easy, because that is when help becomes cheap to ask for.
- Escalate confusion the same week it appears. Concepts here compound, so a delay is not neutral.
- For every construct, ask what is in memory rather than what the output was. That question is the unit's spine.
- Practise explaining code aloud without running it. If you cannot predict the behaviour, you are recalling rather than modelling.
- Learn one systematic debugging method and use it even when guessing would be faster. The habit is what transfers.
Frequently asked questions
Do I need programming experience for INFO1110?
No. The University of Sydney unit page lists no prerequisites and no assumed knowledge. Expect a mixed room, and expect prior experience to matter less than it looks like it will after the first month.
Which units are prohibited with INFO1110?
The listed prohibitions are INFO1910, INFO1103, INFO1903, INFO1105, INFO1905 and ENGG1810. Check this against your own enrolment before planning a sequence, since prohibitions block enrolment regardless of intention.
Why does this guide not list assessment weightings?
The unit page does not publish them, and they are set in each semester's unit outline. A weighting quoted from another semester would look authoritative while being wrong for you, so take yours from your own outline.
Can I use an AI assistant to write my code?
Whatever any individual assessment permits, the unit is examining whether you can design, predict and debug, and code you did not reason about does not build those. Read your own unit outline for what is allowed, and treat anything you cannot explain line by line as not yet yours.
Is recursion really that hard?
It is hard when the foundations underneath it are shaky, which is usually what has happened. If recursion is not landing, check that you can say precisely what a function receives and what it returns first.
Where MAAS fits
MAAS mentors work alongside students in units like this rather than in place of them. In a first programming unit the most useful thing a mentor does is refuse to look at the output first: asking what you expected to happen and why, until the gap between your model and the machine's behaviour becomes visible. That is the gap the whole unit is about. The work stays yours. If that is useful, our tutoring service and our data and coding projects service are the two places to start.
References
du Boulay, B. (1986). Some difficulties of learning to program. Journal of Educational Computing Research, 2(1), 57–73. https://doi.org/10.2190/3LFX-9RRF-67T8-UVK9
Robins, A. (2010). Learning edge momentum: A new account of outcomes in CS1. Computer Science Education, 20(1), 37–71. https://doi.org/10.1080/08993401003612167
Tools & resources
The University of Sydney. (2026). INFO1110: Introduction to Programming. https://www.sydney.edu.au/units/INFO1110