Analyst Programmer 261311 vs Developer 261312 and Systems Analyst (ACS)
ANZSCO 261311 (Analyst Programmer) is one of the most common IT codes in ACS applications — but it is also one of the most easily confused with 261312 (Developer Programmer) and 261112 (Systems Analyst). Understanding the difference clearly helps you choose the right code and build an application that fits.
Three commonly confused codes
261311 — Analyst Programmer
Under ANZSCO, the Analyst Programmer combines both systems analysis and programming: analysing user requirements, designing the technical solution, and carrying out the programming. This is the “bridge” role between analysis and development.
Characteristic keywords: system design, technical specifications, programming the solution, taking part in both analysis and development.
261312 — Developer Programmer
The Developer Programmer focuses mainly on writing code to requirements and specifications defined by others. This role has less to do with requirements analysis and higher-level system design.
Characteristic keywords: implementing to a spec, unit testing, maintenance, bug fixing, code review.
261112 — Systems Analyst
The Systems Analyst mainly analyses business processes and requirements and identifies technology solutions — but typically writes little code, or none. The focus is on analysis, specification, and advising on solutions.
Characteristic keywords: process analysis, eliciting requirements, advising on solutions, not writing code.
Why 261311 is common but easily rejected
261311 is common because many programmers genuinely do both analysis and development in a small-company environment — a widespread reality in many workplaces. ACS recognises this.
However, ACS is also careful with 261311 applications because it is a “versatile” code that is easily claimed in general terms. The applications most likely to be rejected are those that describe the work as a list of technologies (used Java, React, MySQL and so on) but fail to show:
- How you took part in requirements analysis
- How you designed the architecture or modules
- The difference between your responsibilities and those of someone who only codes to a spec
What a 261311 application needs to show
For ACS to classify an application under 261311, the work evidence needs to clearly show:
The analysis side:
- Working directly with stakeholders to understand requirements
- Writing technical specifications and functional specifications
- Evaluating technical solutions and recommending a choice
The development side:
- Writing code to implement the analysed solution
- Taking part in code review or leading the implementation
If your application only shows one of the two sides — or only a list of technologies — ACS may place it under 261312 (if it leans towards coding) or 261112 (if it leans towards analysis).
When to choose 261312 instead of 261311
Choose 261312 when:
- The work is mainly implementing to a spec written by someone else
- There is little or no involvement in requirements analysis from the start
- The role is a junior/mid developer mainly writing code
261312 is not a “lower level” — it is simply a different code. An application that fits your genuine code will have a higher success rate than one straining to reach 261311.
When to choose 261112 instead of 261311
Choose 261112 when:
- The work is mainly analysis, specification and advising on solutions
- You write no code, or very little
- You work more with business stakeholders than with code