Coding frequency | Percent |
---|---|
Never | 20.2% |
Rarely | 21.8% |
Sometimes | 29% |
Regularly | 17.7% |
All the time | 11.3% |
Sample size = 124 |
Profession summary: government economic service (GES)
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
How often analysts are using code at work
We asked respondents “In your current role, how often do you write code to complete your work objectives?”
Access to and knowledge of programming languages
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.
Access to coding tools
Programming tool | Yes | No | Don't Know |
---|---|---|---|
Python | 72.6% | 8.1% | 19.4% |
R | 95.2% | 2.4% | 2.4% |
SQL | 55.6% | 7.3% | 37.1% |
Matlab | 5.6% | 26.6% | 67.7% |
SAS | 22.6% | 17.7% | 59.7% |
SPSS | 29.8% | 15.3% | 54.8% |
Stata | 42.7% | 19.4% | 37.9% |
VBA | 33.1% | 14.5% | 52.4% |
Sample size = 124 |
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.
Knowledge of coding tools
Programming tool | Yes | No | Not required for my work |
---|---|---|---|
Python | 19.4% | 47.6% | 33.1% |
R | 58.9% | 29% | 12.1% |
SQL | 29.8% | 37.1% | 33.1% |
Matlab | 4.8% | 41.1% | 54% |
SAS | 9.7% | 41.1% | 49.2% |
SPSS | 6.5% | 41.9% | 51.6% |
Stata | 29% | 32.3% | 38.7% |
VBA | 11.3% | 40.3% | 48.4% |
Sample size = 124 |
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 who do not code at work.
Access to git
Knowledge of git
Coding capability and change
Where respondents first learned to code
Respondents with coding experience outside their current role were asked where they first learned to code. Those analysts who code in their current role but reported no other coding experience, are included as having learned ‘In current role’. Those who reported first learning to code outside of a work or educational environment were categorised as ‘self-taught’ based on free-text responses.
These data only show where people first learned to code. They do not show all the settings in which they had learned to code, to what extent, or how long ago.
Where learned | Percent |
---|---|
Current employment | 33.3% |
Education | 36.4% |
Previous private sector employment | 3% |
Previous public sector employment | 15.2% |
Self-taught | 10.1% |
Other | 2% |
Sample size = 99 |
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.
Ability change | Percent |
---|---|
Significantly worse | 7.6% |
Slightly worse | 12.1% |
Stayed the same | 19.7% |
Slightly better | 34.8% |
Significantly better | 25.8% |
Sample size = 66 |
Coding practices
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’
Consistency of good coding practices
Statement | I don't understand this question (%) | Never (%) | Rarely (%) | Sometimes (%) | Regularly (%) | All the time (%) |
---|---|---|---|---|---|---|
Automated data quality assurance | 8.1% | 30.3% | 19.2% | 18.2% | 21.2% | 3% |
Code review | 3% | 9.1% | 12.1% | 18.2% | 34.3% | 23.2% |
Coding guidelines / Style guides | 12.1% | 16.2% | 8.1% | 22.2% | 34.3% | 7.1% |
Functions | 11.1% | 11.1% | 12.1% | 22.2% | 28.3% | 15.2% |
Open source own code | 33.3% | 45.5% | 12.1% | 5.1% | 4% | 0% |
Packaging code | 20.2% | 52.5% | 12.1% | 4% | 9.1% | 2% |
Proportionate quality assurance | 10.1% | 10.1% | 2% | 12.1% | 43.4% | 22.2% |
Quality assurance throughout development | 10.1% | 12.1% | 10.1% | 12.1% | 33.3% | 22.2% |
Standard directory structure | 38.4% | 20.2% | 10.1% | 9.1% | 15.2% | 7.1% |
Unit testing | 44.4% | 27.3% | 6.1% | 11.1% | 8.1% | 3% |
Use open source software | 2% | 9.1% | 12.1% | 17.2% | 28.3% | 31.3% |
Version control | 7.1% | 39.4% | 11.1% | 11.1% | 17.2% | 14.1% |
Sample size = 99 |
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.
Statement | I don't understand this question (%) | Never (%) | Rarely (%) | Sometimes (%) | Regularly (%) | All the time (%) |
---|---|---|---|---|---|---|
Analytical Quality Assurance (AQA) logs | 10.1% | 28.3% | 13.1% | 27.3% | 15.2% | 6.1% |
Code comments | 7.1% | 8.1% | 2% | 7.1% | 25.3% | 50.5% |
Data or assumptions registers | 16.2% | 33.3% | 9.1% | 18.2% | 14.1% | 9.1% |
Desk notes | 28.3% | 25.3% | 6.1% | 18.2% | 12.1% | 10.1% |
Documentation for each function or class | 15.2% | 34.3% | 19.2% | 15.2% | 11.1% | 5.1% |
Flow charts | 9.1% | 35.4% | 22.2% | 20.2% | 8.1% | 5.1% |
README files | 11.1% | 30.3% | 11.1% | 24.2% | 15.2% | 8.1% |
Sample size = 99 |
Dependency Management
We asked respondents who reported writing code at work if they manage dependencies for their projects.
We provided examples of tools that may be used for dependency management:
- Requirements files, e.g. python requirements.txt or R DESCRIPTION files
- Virtual environments (e.g. venv or renv) or virtual machines
- Containers e.g. Docker
Use dependency management software | Percent |
---|---|
Yes | 14.1% |
No | 41.4% |
I don't know what dependency management is | 44.4% |
Sample size = 99 |
Continuous integration
We asked respondents who reported writing code at work if they use continuous integration.
We provided some examples of continuous integration technologies:
- GitHub actions
- Jenkins
- Travis
Use continuous integration | Percent |
---|---|
Yes | 10.1% |
No | 35.4% |
I don't know what continuous integration is | 54.5% |
Sample size = 99 |
Reproducible workflow packages
We asked respondents who reported writing code at work whether they use reproducible workflow packages.
We provided some examples of packages:
- drake
- make
- pymake
- targets
Use reproducible workflow packages | Percent |
---|---|
Yes | 2% |
No | 54.5% |
I don't know what reproducible workflows are | 43.4% |
Sample size = 99 |
Reproducible analytical pipelines (RAP)
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.
Knowledge of RAP
We asked respondents who reported writing code at work, if they had heard of RAP.
RAP Champions
We asked respondents who had heard of RAP, if their department has a RAP champion and if they know who it is.
Knowledge | Percent |
---|---|
Yes, and I am a RAP Champion | 3.7% |
Yes, and I know who the RAP Champion is | 35.4% |
Yes, but I don't know who the RAP Champion is | 19.5% |
No | 1.2% |
I don't know | 40.2% |
Sample size = 82 |
Awareness of RAP strategy
We asked respondents who had heard of RAP, if they had heard of the RAP strategy.
RAP strategy knowledge | Percent |
---|---|
Yes | 17.1% |
Yes, but I haven't read it | 50% |
No | 32.9% |
Sample size = 82 |
Opinions on RAP
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 and/or my team are currently implementing RAP | 26.8% | 29.3% | 22% | 14.6% | 7.3% |
I feel confident implementing RAP in my work | 13.4% | 19.5% | 35.4% | 29.3% | 2.4% |
I feel supported to implement RAP in my work | 7.3% | 20.7% | 35.4% | 30.5% | 6.1% |
I know where to find resources to help me implement RAP | 6.1% | 20.7% | 26.8% | 36.6% | 9.8% |
I or my team are planning on implementing RAP in the next 12 months | 11% | 17.1% | 28% | 36.6% | 7.3% |
I think it is important to implement RAP in my work | 4.9% | 8.5% | 24.4% | 39% | 23.2% |
I understand what the key components of the RAP methodology are | 7.3% | 30.5% | 18.3% | 36.6% | 7.3% |
Sample size = 82 |
RAP scores
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 components
RAP component | Type | Percentage of analysts who code in their work |
---|---|---|
Proportionate QA | Basic | 65.7% |
Use open source software | Basic | 59.6% |
Peer review | Basic | 57.6% |
Version control | Basic | 31.3% |
Documentation | Basic | 21.2% |
Team open source code | Basic | 4% |
Functions | Advanced | 43.4% |
Follow code style guidelines | Advanced | 41.4% |
Function documentation | Advanced | 16.2% |
Dependency management | Advanced | 14.1% |
Unit testing | Advanced | 11.1% |
Code packages | Advanced | 11.1% |
Continuous integration | Advanced | 10.1% |
Sample size = 99 |