The Research IT team is recruiting for an assistant developer, so we thought it might be a good idea to write a blog post about life in our team and what an assistant developer role means to us.
The job description vs job advert
If you’ve found this post by following a link in the job advert, the University’s official job description might seem a bit daunting. Don’t worry it’s like that because the University is big, really big (there are almost 8,000 members of staff and over 2,000 of those in Professional Services, where IT Services sits) so staff doing broadly similar roles across the university have a shared job description. Having shared job descriptions brings positives and negatives. As someone applying for a role in the university you may find the description lists very broad skills but doesn’t contain much detail about the actual role, work you’ll do or team you’ll be working in. Developers working in our team share a job description with developers in other teams, but the specific type of work we do and the exact skills we need differ in the detail. It’s this detail that defines the role, which we have tried to convey in the advert and in this blog post. So let’s talk about our team…
What do we do?
We are a small team, currently the team is three senior developers, one systems administrator, one database manager working on one very specific project, one administrator and the team leader – we also work with some lovely contractors. Our function is to provide bespoke software solutions to deliver research projects within the University, we create software from scratch and use common frameworks to enable us to do that, but the nature of our function means we are always building something novel.
So, a project lifecycle might look like:
- A member of research staff contacts us looking for some technical assistance with a grant application they are writing.
- We work with the researcher to understand and refine their requirements and then put together an estimate for the cost and time required to deliver the solution to support their research and fit with the grant requirements.
- The researcher submits their application to the relevant funding body. And then we wait…. often months… During this time we work on our other projects that have already been funded.
- Assuming the researcher is successful we work with them to create the software to support their research project – the money from this coming from the successfully funded grant. We often work with external designers and usability experts to create the best possible solution we can within budget and use them to provide expertise we don’t currently have within our team.
- During the development process we make sure the software adheres to both internal and external governance and legal requirements.
- When the software is in use, we provide technical support to the researchers (we don’t normally deal with support from end users directly) for the duration of the project and keep the software up to date.
- At the end of the project, we help the researcher extract any data needed for their research (if they haven’t done this themselves) and then the software is either “retired” or passed on to another organisation if it is to continue as a service after the research project.
So, in a nutshell, we create new “things” for researchers and these “things” have a finite lifespan.
The more astute among you will have noticed we’ve not said what sort of things we create and what we use to do that…
What do we create?
Despite the fact that our team is really small, our remit is to work with any researcher who needs our services across the university (and can pay). This means we have to be able to work in a very wide range of disciplines. For example, we currently have projects in Engineering, Epidemiology, Mental Health, History and Geography – and this is just a current snapshot not including past and future projects. Working in such a diverse range of disciplines means a diverse range of solutions and, very broadly, these include:
- Data driven websites and applications
- Mobile apps
- Games/game-like things – web and mobile
- Data processing pipelines
- Natural Language Processing
Grant funded projects must demonstrate value for money, so we often need to work with the “best of breed” solution in any specific discipline, but we do standardise where we can. It’s not possible to do what we do with such a small team and not have common tool chains. So, a few technologies we commonly use include:
- Django web framework
- Python libraries like Pandas, NLTK and NumPy
- Phaser (JavaScript games engine)
- Cordova & native app development
- Apache & NGINX
- Git
- Docker
- Jenkins & Bitbucket pipelines
Why our team is special and why you should consider applying
Teams like ours are very unusual outside of a university and are even uncommon within universities. In other development jobs you’ll be working on a specific product or working on multiple, similar projects in a narrow range of technologies. Our team has to be able to skill-up quickly with new tools for a project, so you are always working on something new, learning something and building your skillset. We have a significant amount of technical freedom, and it’s often our decision what tool we use to deliver a specific project. This doesn’t mean we just pick whatever we fancy, but we do have the flexibility to use the best tool for the job at hand. Research projects are finite so we have “end of life” dates for projects and, although this can sometimes be five or more years in the future it does mean we are not left supporting lots of old projects and legacy code.
Also, our projects bring positive benefits. as we build software to support research that increases our understanding of a topic. For example, some of our current work focuses on climate change and mental health in adults.
Who should apply and what will the assistant developer do?
The assistant developer role would suit someone without lots of experience yet, and the range of technologies our team works with means that we’re looking for someone with a willingness to learn new skills and an awareness of development in general rather than specific skillsets.
We’d like you to have some technical experience (for example, some programming knowledge) but don’t want to be prescriptive over what we expect. For example, you may have done things like created and run a small website (perhaps backed by a database) or, written some code in a popular scripting language (for example, Python, PHP or JavaScript), and stored your code under version control and possibly read about or written some automated tests.
In terms of where the role sits within the team, you’ll be working with the senior developers and the systems administrator to help deliver new projects and support our existing projects and processes. You might be asked to make changes to one of our existing projects to keep it up to date, develop some functionality on a new project or work on improving some of our internal systems (such as our automated deployment pipelines, test suites and monitoring systems). The work will be diverse, and you’ll need to show you can pick up new skills quickly.
The job is currently only being advertised internally and you can apply here, if you want to see some of examples of our work then they’re on our website or if you want an informal chat about the role please contact: Serena Cooper, Research IT Team Manager (serena.cooper@bristol.ac.uk) or Kieren Pitts (kieren.pitts@bristol.ac.uk)