The state of UK public sector analysis code: 2024

How to use this research

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.

Coding frequency and tools

We asked respondents if they had any coding experience, inside or outside of work. Of 1300 respondents, 92.9% had coding experience. We asked all respondents with coding experience “In your current role, how often do you write code to complete your work objectives?”

To see how this compares to other years, see the data collection page

2024 data

Show chart Show table
In your current role, how often do you write code to complete your work objectives? Percentage
Never 9.4%
Rarely 12.7%
Sometimes 17.7%
Regularly 36.1%
Always 24.1%
Sample size = 1208

Access to and knowledge of programming languages

Given a list of programming tools, we asked all respondents with coding experience if the tool was available to use for their work. Note this includes respondents who do not code in their current role.

Access to tools does not necessarily refer to official policy. Some analysts may have access to tools others cannot access within the same organisation.

Access to coding tools

Show chart Show table
Programming tool Yes No Don't know
Python 76.1% 11.5% 12.4%
R 92.9% 4.5% 2.6%
SQL 71.9% 7% 21.1%
Matlab 4.6% 40.5% 54.9%
SAS 22.4% 31.7% 45.9%
SPSS 23.7% 30.4% 45.9%
Stata 15.8% 30.7% 53.5%
VBA 43% 16% 41%
Sample size = 1208

Given the same list of programming tools, the same 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.

Knowledge of coding tools

Show chart Show table
Programming tool Yes No Not required for my work
Python 50.3% 34% 15.6%
R 80.1% 13.2% 6.6%
SQL 62.3% 22.1% 15.6%
Matlab 11.8% 45.9% 42.3%
SAS 19.7% 43.7% 36.6%
SPSS 26.7% 36.6% 36.8%
Stata 11.7% 49.4% 38.9%
VBA 21.8% 44.5% 33.8%
Sample size = 1208

Open source capability over time

The proportion of respondents who report having the capability to use R and Python, is shown alongside the proportion who are able to use SAS, SPSS or Stata, for the past four years of the survey.

Show chart Show table
Programming language type Year Know how to programme with these tools (percent) Lower confidence limit (percent) Upper confidence limit (percent)
2021 Open Source 77% 0.7413160 0.7958949
2022 Open Source 80.3% 0.7802509 0.8231395
2023 Open Source 72.6% 0.7005951 0.7491138
2024 Open Source 80.9% 0.7869734 0.8296660
2021 Proprietary 60.1% 0.5687348 0.6321733
2022 Proprietary 56.3% 0.5359005 0.5893030
2023 Proprietary 36.1% 0.3351431 0.3873442
2024 Proprietary 40.7% 0.3805305 0.4338641

Professions capability in different tools

Differences in preferred languages may lead to silos between analytical professions. Here we show the percentage of respondents reporting capability in different tools, within the different analytical professions.

Please note that respondents might be members of more than one profession, and may report capability in more than one tool.

Profession Python R Matlab SAS SPSS SQL Stata VBA
Data Engineers 84.2% 78.9% 21.1% 15.8% 31.6% 89.5% 5.3% 31.6%
Data Scientists 88.5% 90.4% 19.9% 14.7% 13.5% 84% 7.1% 21.8%
Government Digital and Data 67.2% 65.5% 15.5% 29.3% 13.8% 75.9% 5.2% 24.1%
Government Economic Service 39.2% 79.4% 3.9% 11.8% 9.8% 38.2% 36.3% 11.8%
Government Geography Profession 80% 80% 5% 10% 15% 80% 5% 30%
Government Operational Research Service 65.6% 87% 22.9% 22.9% 8.4% 74% 7.6% 33.6%
Government Science & Engineering 64.9% 83.8% 27% 16.2% 13.5% 64.9% 8.1% 18.9%
Government Social Research 25.2% 75.7% 3.5% 9.6% 53.9% 30.4% 13.9% 3.5%
Government Statistician Group 43.7% 86.8% 11% 28.5% 35.9% 64.8% 9.8% 20%

Access to and knowledge of git

We asked respondents to answer “Yes”, “No” or “Don’t know” for the following questions:

  • Is git available to use in your work?
  • Do you know how to use git to version-control your work?

Please note these outputs include people with coding experience who do not code in their current role.

Access to git

Show chart Show table
Is Git available to use for your work? Percentage
Yes 82.5%
No 6%
Don't know 11.5%
Sample size = 1208

Knowledge of git

Show chart Show table
Do you know how to use Git for your work? Percentage
Yes 66.4%
No 23.8%
Not required for my work 9.8%
Sample size = 1208

Coding capability and change

Where respondents first learned to code

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.

Show chart Show table
Where did you first learn to code? Percentage
Self-taught 25.1%
Primary/secondary education 5.9%
Higher Education 43.2%
Current role 8.7%
Previous public sector employment 13.2%
Previous private sector employment 2.2%
Other 1.7%
Sample size = 1208

Coding experience

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.

Show chart Show table
How many years of experience do you have in a coding role? Percentage
None 4.7%
Less than 1 year 12.2%
1 - 3 years 25.7%
3 - 5 years 18.5%
Over 5 years 38.9%
Sample size = 1208

Change in coding ability during current role

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.

Show chart Show table
How has your coding ability changed during your current role? Percentage
It has become significantly better 34.9%
It has become slightly better 32.7%
It has stayed the same 16.7%
It has become slightly worse 10%
It has become significantly worse 5.7%
Sample size = 1103

AI tools

Use of AI tools

We asked all respondents who use code in their role, it they use AI tools when coding at work.

The term ‘AI’ was not defined in this question.

Show chart Show table
Do you use any AI tools when coding at work? Percentage
Yes 39.4%
No 60.6%
Sample size = 1095

How AI tools are used

We asked all respondents who use AI tools when coding at work, what they use these tools for.

Show chart Show table
AI use Yes No
Converting code to a new language 29.5% 70.5%
Debugging code 67.1% 32.9%
Documenting code 20% 80%
Generating synthetic data 12.1% 87.9%
Getting answers to a coding question 78.7% 21.3%
Improving efficiency of code 45.2% 54.8%
Other 0% 100%
Testing code 14.2% 85.8%
Writing code 68.2% 31.8%
Sample size = 431

Trust in AI

We asked all respondents who use AI tools when coding at work, how much they trust the accuracy and reliability of the outputs.

Show chart Show table
Do you trust the outputs from AI tools when coding at work? Percentage
Strongly trust 5.8%
Somewhat trust 56.4%
Neutral/not sure 19.3%
Somewhat distrust 16.2%
Strongly distrust 2.3%
Sample size = 431

Reproducible analytical pipelines (RAP)

RAP refers to the use of good software engineering practices to make analysis pipelines more reproducible. This approach aims to use automation to improve the quality and efficiency of analytical processes.

The following links contain more resources on RAP:

  • you can find minimum RAP standards in the RAP MVP
  • you can find guidance on quality assuring code in the Duck Book

Awareness of RAP over time

We asked all respondents if they had heard anything about reproducible analytical pipelines (RAPs).

Show chart Show table
Year Heard of RAP (percent) Lower confidence limit Upper confidence limit
2021 75.8% 0.7276143 0.7867370
2022 82.1% 0.7982960 0.8423761
2023 88.2% 0.8615990 0.8993581
2024 86.2% 0.8404089 0.8812603

Opinions on RAP

We asked respondents who had heard of RAP whether they agreed with a series of statements.

Show chart Show table
Statement Strongly Disagree (%) Disagree (%) Neutral (%) Agree (%) Strongly Agree (%)
I think it is important to implement RAP in my work 1.6% 3.9% 11.6% 33.3% 49.5%
I have the resources I need to help me implement RAP in my work 5.7% 14.5% 23.2% 31.5% 25.1%
I am currently implementing RAP in my work 10% 14.2% 17.6% 29% 29.1%
My department values RAP 2.8% 6.3% 21.9% 36.7% 32.3%
Sample size = 1068

Good coding practices

We asked respondents who reported writing code at work about the good practices they apply when writing code at work. These questions cover many of the coding practices recommended in the quality assurance of code for analysis and research guidance, as well as the minimum RAP standards set by the cross-government RAP champions network.

Coding practices have been classified as either ‘Basic’ or ‘Advanced’. Basic practices are those that make up the minimum RAP standards, while Advanced practices help improve reproducibility. The percentage of respondents who reported applying these practices either ‘Regularly’ or ‘All the time’ is shown below.

Open sourcing was defined as ‘making code freely available to be modified and redistributed’

Show chart Show table
RAP component Type Percentage of analysts who code in their work
Use open source software Basic 79.9%
Work to quality standards Basic 69%
Peer review Basic 58.7%
Version control Basic 56.5%
Create project README Basic 43.6%
Open source own code Basic 15.5%
Manually test code Advanced 79.3%
Use control flow Advanced 58.4%
Follow code style guidelines Advanced 56.9%
Write functions Advanced 56.2%
Use configuration files Advanced 53.9%
Document dependencies Advanced 34.6%
Document functions Advanced 31.8%
Write automated tests Advanced 16.6%
Sample size = 1095

Consistency of good coding practices

We asked respondents who reported writing code at work how frequently they apply good coding practices when writing code at work.

Show chart Show table
Statement I don't understand this question (%) Never (%) Rarely (%) Sometimes (%) Regularly (%) Always (%)
Have code reviewed 0.1% 6.3% 11.5% 23.4% 27.7% 31.1%
Manually test code 0.7% 3.7% 4.1% 12.2% 32% 47.3%
Separate settings from code 6.6% 9% 9.8% 20.7% 27.2% 26.7%
Use a standard code style 9.9% 13.6% 5.7% 14% 28.8% 28.1%
Use control flow 2.5% 8.7% 10.2% 20.3% 29.6% 28.8%
Use open source software 0.7% 4.9% 6.4% 8% 23.7% 56.3%
Write automated tests 10% 35.6% 20.4% 17.4% 10.4% 6.2%
Write functions 1.1% 7.2% 9.9% 25.7% 26.8% 29.4%
Sample size = 1095

Code documentation

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.

Show chart Show table
Statement I don't understand this question (%) Never (%) Rarely (%) Sometimes (%) Regularly (%) Always (%)
Create README files 2.3% 20.3% 13.5% 20.4% 20.7% 22.8%
Document dependencies 4.3% 28.1% 14.5% 18.4% 17.7% 16.9%
Document functions 12.1% 33.1% 11.5% 11.5% 16.3% 15.4%
Document manual QA steps 3.5% 14% 11.9% 26.3% 27.2% 17.2%
Document pipeline design 9.3% 23.3% 15.4% 23% 19.3% 9.7%
Sample size = 1095

Working practices

We asked respondents who reported writing code at work how frequently they use good working practices in the coding projects they work on.

Show chart Show table
Statement I don't understand this question (%) Never (%) Rarely (%) Sometimes (%) Regularly (%) Always (%)
Have a succession plan 0.8% 5.6% 4.9% 13.3% 37% 38.4%
Publish code in the open 5% 43.8% 18.8% 16.8% 10.3% 5.2%
Understand project aims 0.1% 1.6% 1% 10.4% 40.5% 46.4%
Understand project roles 0.7% 3% 4.5% 16.3% 39.1% 36.3%
Use version control 2.7% 20.1% 8.5% 12.1% 22.1% 34.4%
Work to quality standards 4.1% 5.6% 5.5% 15.8% 37.4% 31.7%
Sample size = 1095