International RSE day – Why be an RSE?

To celebrate the first International Research Software Engineers (RSE) day our team wanted to promote becoming an RSE as a career path and raise awareness of Research Software Engineering in general. We think it’s one of the most diverse and exciting technical disciplines and hope this blog post might convince you to think the same.

What is an RSE?

Defining the role of a Research Software Engineer is difficult as it’s an exceptionally varied role that differs between research institutions. Its breadth is best captured in the definition provided by the Society of Research Software Engineering:

“A Research Software Engineer (RSE) combines professional software engineering expertise with an intimate understanding of research.”
Source: https://society-rse.org/about/

In our team the RSEs design, create, deliver and support technical solutions enabling research projects at the University of Bristol. These aren’t the ancillary services to facilitate research (such as finance systems etc) but technical solutions that directly deliver research outcomes. For example, creating an iPad app that a research team uses with a study group as part of their research. In addition we work with academic colleagues to help them with the grant application process. This work involves requirements gathering, the creation of technical estimates and writing data management plans that form part of their research funding submission.

Why be an RSE?

So, you’re interested in research and software engineering? Let me try and convince you that becoming an RSE is the career for you:-

  • Interesting and novel projects
    You’ll work on diverse and interesting projects. Any academic at the University of Bristol can contact our team and ask us to be involved in their research. That means we have an exceptionally diverse range of projects we’re working on. These range from engineering to history and from medical research to the impacts of climate change. Most importantly, these are research projects and so are novel applications and things that have not been done before.
  • Technical freedom
    All developers love a bit of technical freedom… the flexibility to learn something new and to be able to use the “right tool for the right job”. Research Software Engineering allows a lot of flexibility because not only do you need to pick the “best of breed” solution for any given problem to demonstrate value for money for funders but our research projects have a finite timespan. In most cases this is several years but for proof-of-concept work this could be just a few months. This known lifespan means that we have flexibility to try out new things if they are appropriate to that project.
  • RSEs come from varied backgrounds
    Research Software Engineers come from a variety of backgrounds because it’s a very flexible discipline and you don’t need to come from a conventional computer science background. Many academic disciplines help develop strong data handling and programming skills and these can be discipline specific which makes them invaluable in a research software engineering team. Also, if you have some research experience then this makes you better able to help with the grant application process, contributing to academic publications and in understanding research outputs. Our RSEs have a diverse mix of backgrounds and experiences (many switched careers to become RSEs) and this is of huge positive benefit to the team. In my case, for example, I do not have a computer science background and am a self-taught programmer. I have a strong interest in software development but when doing field work on flies (Lucilia sericata – check them out, they’re cool) I wouldn’t have dreamt that years later I’d be writing software to help children with eye movement issues or creating online games to help explain bird flight research.
  • Development for social good
    Academic research furthers human knowledge so RSEs get to work on projects that are delivering clear benefits. In some cases there are obvious direct benefits such as our mobile app to help assess earthquake risks to school buildings in Nepal. In other cases our work involves making something available to people that has never been available in that form before. For example, the MPESE project that made the hidden archive of early Stuart England’s manuscript pamphlets available online.

We hope that this fairly brief blog post has helped raise the profile of RSEs and maybe even convinced you that you might want to become an RSE. If you want to know more than here are some useful links:

We are recruiting – what’s it like in our team?

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:

  1. A member of research staff contacts us looking for some technical assistance with a grant application they are writing.
  2. 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.
  3. 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.
  4. 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.
  5. During the development process we make sure the software adheres to both internal and external governance and legal requirements.
  6. 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.
  7. 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)

Celebrating the women in our team – Claire Webster

At school, I was the child who sat quietly in the corner, and whose every school report said in some form of words “Claire is very quiet and needs to participate in class discussion more”. It wasn’t that I didn’t have anything to say, it was just that others were more vocal, and discussion always moved at such a pace that by the time there was a gap anything I had to say was out of dateI am an extreme introvert, that’s not to say I don’t like having company or I’m shy, those are very different things. I get my strength from solitary pursuits; music, reading, drawing which in turn enables me to fully participate when with others.  

Music has always been a solace for me, whether playing or listening and as a musician one of the biggest joys is performing which is an interesting juxtaposition for an introvert but somehow it makes sense, it’s all a process of exchanging energy. It doesn’t have to be in front of an audience, I swear some of the best playing and singing I’ve ever done has been in an empty church with no one around apart from my accompanist. It’s the process of sharing and communicating with a single purpose, the interpretation of a vision (both the composers and your own), the translation of sound into a feeling, a thought, a memory, of taking listeners on a journey to help them move beyond the immediate. 

So, where is this ramble taking us… Like many women in IT I sort of fell into this career, I trained as a librarian and spent my holidays working at a local service provider at the dawn of the internet (UK Online for those interested). It was here that I learned HTML which in turn allowed me to find a job when I left University and faced the stark realisation that there aren’t that many jobs for newly qualified, straight out of school librarians with no experience. I was either not experienced enough for the roles I was qualified for or over-qualified for the more junior positions. Over time, I progressed from a web developer to a slightly more “hard-core” Perl developer which in turn led me to join the Institute of Learning Technology at the University of Bristol on the 4th of March 2002.  

During my time at Bristol, I’ve had the joy of progressing through many different roles which included a return to my original aspirations in a library when I helped support the main library management system. Once the library system had been moved to a 3rd party supplier, I found myself at a loose end. No longer truly a developer and with no desire to become one again I shifted sideways into the Research IT team as a Relationship Manager. The move from a technical role into a more project-based, facilitation role was daunting at first but very quickly I knew I’d found what I wanted to do.  

Listening to researchers and delving into their aspirations, interpreting their ideas into a reality, helping them along a journey (you see where I was going with the ramble now?). To me communication in whatever form is vital. The processes of active listening, guidance and requirement clarification are fundamental elements of any successful project. So many problems and issues can be resolved if we just stop and truly share what we are trying to achieve but also to make sure that we are understanding what others are trying to achieve too. Most importantly be open about that goal and the benefits you hope it will bring and if you don’t understand, don’t be afraid to ask for further information 

My experiences and the skills I have learnt during my time in Research IT and the strong leadership and support of my managers (both female) has given me the confidence to start yet another part of my career this time as a Business Analyst within the IT Architecture TeamI’m going to miss Research IT but am very much looking forward to introducing a new approach into the strategic projects that can sometimes lose track of the benefits they’re trying to deliver and who they are trying to help. I’ve transitioned from the quiet child in the corner to a capable adult who can (and does) make their voice heard, who will take the lead on discussions and one who I hope builds relationships and bridges across all parts of IT.  

Celebrating the women in our team – Charlotte Mason

Being asked to put together a few words for International Women’s Day has provided me with a great opportunity to reflect upon who and what has led me to reach the position I’m in today, working as a software developer alongside the superb Research IT team here at the University of Bristol. Perhaps it’s somewhat of a cliche, but probably my parents were most influential, providing lots of early guidance in the direction of science and technology.

My father was a research chemist who worked for a major pharmaceutical firm of his day, authoring papers on penicillin amongst other topics. Although he left school at 15, he continued his education at night school, eventually gaining a first class degree in chemistry. He was unfailingly encouraging of all my educational efforts while I was growing up.

My mother was the daughter of two Polish academics, both agricultural scientists. A couple of her formative years were spent in Siberia following the Soviet invasion of eastern Poland at the start of WW2. My grandmother’s background made her the ideal candidate to be put in charge of the livestock in the little village where they were placed, and my mother used to describe how their hut was shared with pigs and other village animals, which were brought indoors in winter and overnight. It was maybe as a result of her experiences there that she was always vocal about the value of scientific knowledge when life gets ugly.

Although my mother worked in the pharmaceutical industry for a while before my brother and I were born, my childhood memories of her are as the physics lab technician at the local secondary school. She gave that job her all and did it exceptionally well, often going “above and beyond”. I recall electronics being introduced to the curriculum, something she didn’t know much about, and so she took herself off to local adult education classes to study it until she had a solid understanding of it. The value of that knowledge was not to be underestimated.

Returning to IT, my first experience of this was our family’s BBC Micro Model B computer. Although I say it belonged to the family, really it was the domain of my older brother and his school friends. However, I did get a reasonable number of opportunities to try out the various games available (Chuckie Egg was my favourite!) and the “music” of loading them up from cassette tape is forever etched on my memory.

I gained more substantial experience when I embarked on a degree at Leeds University in the early 1990s, where computer science formed a third of my course for the first two years (together with maths and music). We were taught to program – I recall that Pascal, SML and C++ were on the curriculum at that time – and the buzz of typing logical, structured words into a terminal, and seeing it doing something cool in response, is something which has stayed with me to this day. Although I focussed more on maths for a short while longer, the lure of programming was never far away, and I started my first job doing that shortly before 2000.

A good proportion of my career has been spent writing code for and working with various flavours of mobile devices, from Pocket PC, Palm Pilot and Symbian, through to Blackberry and then Android. I’ve been able to draw on that when working on the SAFER PREPARED project here at the University, where Prof Anastasios Sextos has developed methods to evaluate the safety of buildings in countries prone to earthquakes. With a series of questions coded into an Android application, it is quick and easy for field engineers to inspect and photograph a building, and to upload and store this information centrally; a straightforward scoring mechanism then provides guidance to the appropriate authorities on which areas are most in need of attention and support.

Celebrating the women in our team – Tessa Alexander

I am a Research Software Engineer in Research IT at the University of Bristol and have worked in IT for over 20 years.

I found a love of coding while taking A-level Computing.

I come from a web background, from streaming real time market data to early browsers in the early 00s through a journey of an open source developer in government, charity, and education sector roles.

I have always been driven to make tools to help others share their message and now specifically research.

I have always been supported not pressured and encouraged to do my best.

I have been surrounded by intelligent strong women my entire life and I dedicate this post to all of them.

Celebrating the women in our team – Serena Cooper

How team manager Serena Cooper ended up in IT and her thoughts on how we can support our female colleagues.

I started with the Research IT team in May 2020 during lockdown. I love this job as it brings together my background in research with my experience managing IT teams  as well as my desire to use IT to do good.  I am proud to say I am a feminist, a strong independent woman who has had some excellent role models and advocates. My journey into IT was the long way round with a bit of avoidance along the way.

I grew up surrounded by computing, my father was a computer engineer and my mother a programmer when computers filled rooms and code was made by punching holes in bits of paper. Programming and hardware were normal dinner time conversation and my two brothers absorbed it like  sponges. I, on the other hand, found it boring and lacking in creativity. After briefly considering becoming a scientific illustrator, I pursued a career in biochemistry. I ended up in the computationally heavy area of protein X-ray crystallography and, although I worked alongside the CCP4 Team at Daresbury Labs, I was a user of IT and not a contributor.

X-ray crystallography was wonderfully female discipline not just with its big-hitter heroes like Dorothy Hodgkin, Olga Kennard and Rosalind Franklin but also the continued strong presence of women and how normal and expected that was. It was a stark contrast to the host chemistry department where even in the mid-90s there was not a single female lecturer. I always remember a colleague contemplating a temporary lecturer post being worried she would get all the pastural work and didn’t want the feeling of pressure of being the “first one”.   That particular department is doing slightly better, a quick look at their website now and I see they have six female lecturers!

Messing around with high energy X-rays, liquid nitrogen and high-end graphics was fun, but the day-to-day reality was of pipetting small amounts of liquids in a damp cold-room, of lack of results, and of a strong personal feeling of being an imposter.  So, in a turn to the side, I joined the Research Councils as a portfolio manager, and it is here through various good managers I lost my imposter syndrome and made the slow slide into IT.

I was recognised by the formidable Jo Booth Davey as someone who could articulate user needs in a way the “techies” understood.  All those years of being in a vaguely IT literate environment had paid off! Jo was EPSRC’s software development lead and, like a great general, inspired not a lfear but much loyalty, said it as it was, took no nonsense and got things done. She was a massive influence on me and a fantastic advocate and mentor, not least because I decided I liked the look of what she did and wanted her job! Five years later when she retired it became a reality.

Whilst my particular journey has included a lot of fantastic female colleagues, IT is still male dominated.  As I have moved along, I try to be a good peer and mentor and give back the encouragement, advocacy and support I received and still receive. I have also had, and taken, opportunities for female-centred training and support and would encourage others to do the same.

Through those past advocates I have gained the confidence to speak up when I see unfairness or issues that need to be addressed.  IT will only change with visible role models, if recruitment is less to a type and support given to those entering teams as “the first”.  Those who can must be supportive of those who don’t – yet – have confidence, and highlight all the undesirable behaviours or situations for the continuing benefit of all.

 

 

 

An introduction to Research IT at the University of Bristol

Research IT at the University of Bristol covers a wide range of subject areas and a breadth of scope and technology.  This post is a general introduction. Future posts will cover our projects, aspects of our work, and areas around Research IT in more detail. We are hoping to have some guest posts from those who have used our services.

I took over management of the team in May 2020 and have been truly amazed at the variety of projects they are working on. For such a small team (3 developers, a sys admin and a relationship manager) they manage to work on quite a few projects. We worked on 24 different projects in 2020 and had conversations with over 80 academics about their research and how we could help.

I like a chart so have done some analysis on the university faculties we work with. As you can see, we have an almost equal spread of projects shared between Health Sciences and the Arts. I don’t know all the reasons for this distribution, but some of it may be down to word of mouth and ongoing relationships with some researchers. We are however able to, and very happy to work with researchers in any discipline.

projects are in Health sciences, 38% in Arts, 8% each in science and Engineering and 4% social sciences.
pie chart of Research IT’s active projects in 2020 by faculty

The topics covered in these projects include cataloguing and visualisation of data from historical manuscripts, producing tools to help with earthquake and drought management, and creating platforms for clinical trials of online mental health treatments and for sharing biological data sets.

The size of projects can vary from just a few days of consultancy, through to significant developments of many months and ongoing work for the years of the research project.

We maintain a pipeline of work and are always happy to hear about your research project to see if we can help. We are currently really interested in working on projects with elements of machine learning, AI,  visualisation and virtual reality.

Further details on some of our projects can be found on our website https://www.bristol.ac.uk/research-it/examples-of-work/