Responding to CARS is voluntary. The results presented here are from a self-selecting sample of government analysts. Because respondents are self-selecting, the results we present reflect the views of the analysts who participated.
For more detail, see the data collection page.
We asked all respondents if they had any coding experience, inside or outside of work. Of 106 respondents, 98.1% reported having coding experience. We asked respondents with coding experience “In your current role, how often do you write code to complete your work objectives?”
| In your current role, how often do you write code to complete your work objectives? | Percentage |
|---|---|
| Never | 4.8% |
| Rarely | 14.4% |
| Sometimes | 25% |
| Regularly | 20.2% |
| Always | 35.6% |
| Sample size = 104 |
Given a list of programming tools, we asked all respondents if the tool was available to use for their work.
Access to tools does not necessarily refer to official policy. Some analysts may have access to tools others cannot access within the same organisation.
| Programming tool | Yes | No | Don't know |
|---|---|---|---|
| Python | 97.1% | 2.9% | 0% |
| R | 97.1% | 0% | 2.9% |
| SQL | 65.4% | 8.7% | 26% |
| Matlab | 8.7% | 27.9% | 63.5% |
| SAS | 43.3% | 23.1% | 33.7% |
| SPSS | 37.5% | 20.2% | 42.3% |
| Stata | 17.3% | 22.1% | 60.6% |
| VBA | 32.7% | 13.5% | 53.8% |
| Sample size = 104 |
Given the same list of programming tools, all respondents were asked if they knew how to program with the tool to a level suitable for their work, answering “Yes”, “No” or “Not required for my work”.
Please note that capability in programming languages is self-reported here and was not objectively defined or tested. The statement “not required for my work” was similarly not defined.
| Programming tool | Yes | No | Not required for my work |
|---|---|---|---|
| Python | 85.6% | 11.5% | 2.9% |
| R | 79.8% | 10.6% | 9.6% |
| SQL | 50% | 26% | 24% |
| Matlab | 13.5% | 39.4% | 47.1% |
| SAS | 21.2% | 43.3% | 35.6% |
| SPSS | 31.7% | 30.8% | 37.5% |
| Stata | 9.6% | 46.2% | 44.2% |
| VBA | 14.4% | 40.4% | 45.2% |
| Sample size = 104 |
We asked respondents to answer “Yes”, “No” or “Don’t know” for the following questions:
Please note these outputs include people who do not code at work.
| Is Git available to use for your work? | Percentage |
|---|---|
| Yes | 99% |
| No | 1% |
| Don't know | 0% |
| Sample size = 104 |
| Do you know how to use Git for your work? | Percentage |
|---|---|
| Yes | 76.9% |
| No | 18.3% |
| Not required for my work | 4.8% |
| Sample size = 104 |
Respondents with coding experience were asked where they first learned to code.
These data only show where people first learned to code. They do not show all the settings in which they learned to code, to what extent, or how long ago.
| Where did you first learn to code? | Percentage |
|---|---|
| Self-taught | 29.8% |
| Primary/secondary education | 1.9% |
| Higher Education | 36.5% |
| Current role | 15.4% |
| Previous public sector employment | 13.5% |
| Previous private sector employment | 1% |
| Other | 1.9% |
| Sample size = 104 |
We asked respondents with coding experience how many years of experience they had in a coding role, excluding any years in education.
This data includes any experience in other roles and sectors, but does not define the type of experience.
| How many years of experience do you have in a coding role? | Percentage |
|---|---|
| None | 1.9% |
| Less than 1 year | 6.7% |
| 1 - 3 years | 32.7% |
| 3 - 5 years | 16.3% |
| Over 5 years | 42.3% |
| Sample size = 104 |
We asked “Has your coding ability changed during your current role?”
This question was only asked of respondents with coding experience outside of their current role. This means analysts who first learned to code in their current role are not included in the data.
| How has your coding ability changed during your current role? | Percentage |
|---|---|
| It has become significantly better | 39.8% |
| It has become slightly better | 25% |
| It has stayed the same | 18.2% |
| It has become slightly worse | 11.4% |
| It has become significantly worse | 5.7% |
| Sample size = 88 |
We asked respondents who said they currently use code in their work, how often they carry out various coding practices. For more information on the practices presented below, please read our guidance on Quality Assurance of Code for Analysis and Research
Open sourcing was defined as ‘making code freely available to be modified and redistributed’
| Statement | I don't understand this question (%) | Never (%) | Rarely (%) | Sometimes (%) | Regularly (%) | All the time (%) |
|---|---|---|---|---|---|---|
| Have code reviewed | 0% | 3% | 7.1% | 22.2% | 32.3% | 35.4% |
| Manually test code | 0% | 2% | 6.1% | 10.1% | 31.3% | 50.5% |
| Separate settings from code | 2% | 7.1% | 11.1% | 14.1% | 28.3% | 37.4% |
| Use a standard code style | 9.1% | 8.1% | 6.1% | 13.1% | 30.3% | 33.3% |
| Use control flow | 0% | 7.1% | 10.1% | 7.1% | 34.3% | 41.4% |
| Use open source software | 1% | 1% | 6.1% | 6.1% | 24.2% | 61.6% |
| Write automated tests | 7.1% | 22.2% | 18.2% | 19.2% | 13.1% | 20.2% |
| Write functions | 0% | 6.1% | 7.1% | 12.1% | 29.3% | 45.5% |
| Sample size = 99 |
We asked respondents who reported writing code at work how frequently they write different forms of documentation when programming in their current role.
Embedded documentation is one of the components which make up a RAP minimum viable product. Documentation is important to help others be clear on how to use the product and what the code is intended to do.
| Statement | I don't understand this question (%) | Never (%) | Rarely (%) | Sometimes (%) | Regularly (%) | Always (%) |
|---|---|---|---|---|---|---|
| Create README files | 2% | 14.1% | 20.2% | 15.2% | 20.2% | 28.3% |
| Document dependencies | 1% | 15.2% | 22.2% | 21.2% | 22.2% | 18.2% |
| Document functions | 7.1% | 20.2% | 8.1% | 8.1% | 28.3% | 28.3% |
| Document manual QA steps | 1% | 11.1% | 15.2% | 26.3% | 33.3% | 13.1% |
| Document pipeline design | 4% | 14.1% | 19.2% | 28.3% | 22.2% | 12.1% |
| Sample size = 99 |
We asked respondents who reported writing code at work how frequently they use good working practices in the coding projects they work on.
| Statement | I don't understand this question (%) | Never (%) | Rarely (%) | Sometimes (%) | Regularly (%) | Always (%) |
|---|---|---|---|---|---|---|
| Have a succession plan | 0% | 2% | 2% | 9.1% | 42.4% | 44.4% |
| Publish code in the open | 4% | 42.4% | 21.2% | 18.2% | 10.1% | 4% |
| Understand project aims | 0% | 1% | 2% | 6.1% | 46.5% | 44.4% |
| Understand project roles | 0% | 1% | 8.1% | 13.1% | 45.5% | 32.3% |
| Use version control | 1% | 10.1% | 9.1% | 9.1% | 23.2% | 47.5% |
| Work to quality standards | 3% | 2% | 8.1% | 9.1% | 46.5% | 31.3% |
| Sample size = 99 |
We asked respondents about their knowledge of and opinions on reproducible analytical pipelines (RAP). RAP refers to the use of practices from software engineering to make analysis more reproducible. These practices build on the advantages of writing analysis as code by ensuring increased quality, trust, efficiency, business continuity and knowledge management.
The RAP champions are a network of analysts across government who promote and support RAP development in their departments. Please contact the analysis standards and pipelines team for any enquiries about RAP or the champions network.
The Analysis Function RAP strategy was released in June 2022 and sets out plans for adopting RAP across government.
We asked all respondents if they had heard anything about reproducible analytical pipelines (RAPs).
We asked respondents who had heard of RAP whether they agreed with a series of statements.
| Statement | Strongly Disagree (%) | Disagree (%) | Neutral (%) | Agree (%) | Strongly Agree (%) |
|---|---|---|---|---|---|
| I think it is important to implement RAP in my work | 0% | 1% | 9.9% | 27.7% | 61.4% |
| I have the resources I need to help me implement RAP in my work | 2% | 5.9% | 23.8% | 29.7% | 38.6% |
| I am currently implementing RAP in my work | 3% | 10.9% | 21.8% | 23.8% | 40.6% |
| My department values RAP | 0% | 4% | 12.9% | 28.7% | 54.5% |
| Sample size = 101 |
In this section we present RAP components and RAP scores.
For each RAP component a percent positive was calculated. Positive responses were recorded where an answer of “regularly” or “all the time” was given. For documentation, a positive response was recorded if both code comments and README files questions received positive responses. For the continuous integration and dependency management components, responses of “yes” were recorded as positive.
“Basic” components are the components which make up the RAP MVP. “Advanced” components are components which help improve reproducibility, but are not considered part of the minimum standard.
| RAP component | Type | Percentage of analysts who code in their work |
|---|---|---|
| Use open source software | Basic | 85.9% |
| Work to quality standards | Basic | 77.8% |
| Version control | Basic | 70.7% |
| Peer review | Basic | 67.7% |
| Create project README | Basic | 48.5% |
| Open source own code | Basic | 14.1% |
| Manually test code | Advanced | 81.8% |
| Use control flow | Advanced | 75.8% |
| Write functions | Advanced | 74.7% |
| Use configuration files | Advanced | 65.7% |
| Follow code style guidelines | Advanced | 63.6% |
| Document functions | Advanced | 56.6% |
| Document dependencies | Advanced | 40.4% |
| Write automated tests | Advanced | 33.3% |
| Sample size = 99 |