(Cross-posted from ianholmes.wordpress.com)
The idea behind the JBrowse project has always been to bring the standards of commercial software development to genomics.
JBrowse was originally an attempt to bring genome browsers up to the usability standards of commercial web apps. In the 1990s, bioinformatics led the web: Lincoln Stein (a co-PI of JBrowse) wrote the CGI.pm module that was used to power sites like Amazon in the early days, as well as his genome browser GBrowse. But by the mid-2000s, the Internet boom had left us behind. Genome browsers looked like MapQuest; we wanted JBrowse to look like Google Maps.
To bring industry UI standards to bioinformatics software development, we’ve had to adopt industry’s best practices. As a really basic example, JBrowse was arguably the first bioinformatics project to seriously invest in front-end developers primarily writing JavaScript. As time has gone on, we’ve embraced the label “Research Software Engineer” as a description of what we do. And we’ve adopted other ideas from industry, like Design Sprints and Agile methods.
What is Agile, and what does it mean for research software?
Agile is a name for a set of software engineering principles that have evolved (or been discovered and formalized) over many decades in the industry. Some of its core ideas are iterative improvement of working software; a central focus on customer needs and stories; responsiveness to change; and an emphasis on interactions between people – including, for example, pair programming by developers, self-organization of teams, and collaboration with users.
Different industries use Agile in different ways, and don’t always call it by that name. For example, in the game industry (my first career) it’s common to iterate rapidly on playable prototypes. This is initially driven by a very small team focused on AI and game logic, snowballing into a much bigger effort involving graphic designers, musicians, and playtesters. This in many ways is similar to Agile, but reflecting the unique needs of game development.
Academic software has unique needs too. For an example of something where we need to figure out an academic equivalent, consider a specialized role that is common in industry Agile teams: the Product Owner. This person is responsible for advocating for the needs of the user to the developer team, prioritizing development, and ensuring that new features are coherent. The Product Owner is not necessarily a developer themselves, but they have to be able to talk to developers, and to have a deep understanding of the users’ needs and the nature of the software.
This role is, as I mentioned, quite standard in industry; but in academic software, it’s kind of a new thing, and we have to figure it out. Perhaps the closest fit is an outreach coordinator (which is a more common title in the academic job market). A good fit might be a postdoc or Masters graduate who really knows the scientific domain and has frequently used informatics software, but was not necessarily involved in tool development themselves.
It might be that someone in this kind of role could also write some documentation, or take the lead on writing papers. Again, a recent PhD or (in genomics) a biocurator could be an excellent fit.
JBrowse needs a Product Owner
The JBrowse team has gotten big enough that we need a Product Owner. We are developing version 2 of our genome browser, and it’s a highly extensible platform that can be used for many different things: comparative genomics, cancer genomics, genome annotation, structural variant analysis, you name it. Keeping things focused on user needs is becoming a major job.
As I mentioned, paper-writing would probably also be a part of the academic product owner role. There is now quite a lot of accumulated work in JBrowse 2, and we have a bit of a paper backlog: research software engineers tend to like research problems, but writing them up or wrangling them through review? Not so much. So for whoever joins in this role, there could be a plum opportunity to get a bunch of papers out.
Because of the overlap with the postdoc skill set (project management skills and broad familiarity with the science), and the opportunities for publishing papers, we think that “postdoc” is the closest match to this job in existing academic categories. So we will be recruiting this as a postdoc-style position, at least as first, although we would also consider applicants without a PhD (in which case it would be more like a “research associate” position). But the responsibilities would be a bit different from a traditional postdoc: more focused on delivering software to the user community, like a product owner in an Agile team.
Product Owners have a future in genomics software
I was motivated to write this post because, by now, I trust the trend: When we adopt a practice from the software engineering industry, and have to reinvent or customize some aspects of it, this is rarely a one-off. Typically, it’s a harbinger of a new kind of practice in bioinformatics software. I wanted to lay out our thinking on this, as it’s taken me a while to understand what this role entails.
Bioinformatics as a career is a thing, now, in academia and in industry. Front-end development is definitely a thing. I can all but guarantee that this kind of role – what Agile calls the Product Owner – will become more and more important in genomics software development (which, increasingly, infiltrates all of genomics). And it will set you up to transition to a professional role in Foundation, or Verily, or many other big, mid-size, small, and as-yet-unborn companies working in the bioinformatics application space.
So if you are a recent PhD graduate, or a Masters or BA, who has a broad understanding of genomics and the role of visualization, then please get in touch. This might be a job for you. More importantly, it might be a career for you. And the fact that it isn’t quite defined yet is a huge plus: there’s no fast-track quite as fast as the track that most people don’t even realize is a career yet.
How to apply
If you’re interested in becoming a Product Owner for the JBrowse genome browser, please contact Ian Holmes at ihh at berkeley dot edu, including the phrase “JBrowse Product Owner” in the subject line of your email.