Alex Morley, PhD

Healthcare Tech Substacks

Sun, 22 Nov 2020 00:00:00 +0000

So substack is allowing writers to avoid having their content moderated or edited which has some less than savoury implications. But it also represents pushback against advertising-driven revenue models and lets content creators earn a living independently. So the jury (at least my internal jury) is still out about the net benefits of the new platform to society as a whole. Regardless I have enjoyed reading quite a bit of content on it recently especially around healthcare technology that I wanted to share.

Health Trends

…is written by a medical Doctor who has experience working in healthcare startups as well as the NHS. Each week they break down a trend in healthcare tech into the problem being solved, solutions, a glossary, history, opportunities and predictions for the future along with links to external resources.

Read if: You want a highly digested and well researched overview of a topic.

Don’t read if: You are looking for a story or conversational tone.

Grenz on Health

…is a newsletter by Chris Grenz (shock) who was an early contributor to, and advocate of FHIR (an open standard for the exchange of healthcare data). In his newsletter Chris dives into some operation details about FHIR, some novel usecases as well as some more general discussions about data in healthcare such as trust and interoperability.

Read if: You work with health data professionally.

Don’t read if: You aren’t comfortable / interested in diving into some technical details.

Insight

…is Zeynep Tufekci’s newsletter. OK it’s not actually dedicated to healthcare or tech. But most of the time (especially) recently it is about healthcare or tech. Zeynep is a sociologist focusing on technology and policy. Recent articles discuss randomised controlled trials, US election forecasting and the Tech Hearings.

Read if: You have time. Articles are often long form.

Don’t read if: You want to keep a simple view on world events.

the-best-parts-of-the-internet

Wed, 24 Jun 2020 00:00:00 +0100

Seen some cool thingz pop up on recently which remind that I actually don’t hate the whole of the internet (or the whole of hackernews). Also that maybe I do get art. Just not the kind of art that I was exposed to as a kid.

No paint - I’m no artist but everything that this the produces is a masterpiece IMO.

Loglo - As with no paint you have to click through to event have a tiny clue what this is about but basically its a programming environment for drawing usings stacks of commands in rows and columns in a spreadsheet. Crazy, stupid brilliant stuff.

TTS.mp3 - If your on a mac you can use say. But this you can send as a link.

Doug Engelbart’s Demo - Amazing to see how far we haven’t come since this famous demo. I’d heard about it years ago but never sat down and watched the whole thing. Steve Jobs ain’t got nothing on this.

Hire junior developers

Fri, 01 May 2020 00:00:00 +0100

Medium to large organizations with software at the core of their offering all run into the same sets of problems:

We are spending 10X the amount on engineering salaries compared to what we use to. Why are we building so slowly?
We have a massive backlog of small tasks that never get done.
We are spending a fortune on hiring.
Most of our engineers are leaving after a year or two.

There are countless causes for any ones of these problems so I can’t tell you what the solutions are. But I can tell you what they are not. Your engineers are not too junior. In fact, maybe you have the opposite problem. Your engineers aren’t junior enough.

Why do we hire senior engineers?

As an engineering manager, I only want to hire the best for my team. We have a headcount limit and senior engineers will get more done. We don’t have the capacity to train and mentor junior engineers. As a recruiter or talent manager, I want to show that I can bring in the best talent. As a CEO I want to be able to say that we only hire the best, that we have higher standards than our competitors.

We hire senior engineers because we want what’s best for ourselves and those around us. But while these decisions might be locally optimal they can be harmful to your organisation as a whole.

So let’s zoom out. From an organizational perspective why would it be worth paying (a lot) more for senior developers?

We assume that they can do twice the work while costing less than twice as much (including salary and overheads).*

To which my answer would be: Twice what work?

Can a senior engineer design a major new component faster than a junior one? Sure probably way more than 2x faster and probably much better too. Experience is really important here. But what about debugging an issue that has come in from a client? Sometimes they might be faster but sometimes it won’t make a difference who is looking at the issue. What about propagating a configuration change across some services? Adding an endpoint to expose some existing functionality?

The size and complexity of the tasks for engineers in a typical organisation vary a lot. There will be a few big tasks and lots of small tasks. With too few junior engineers the people working on the big tasks will be distracted by the small ones. People tend to not just be more efficient when they can just focus on one task at a time but also less stressed. If I can use a clunky hardware analogy here: GPUs offer much better value per core than CPUs but are better suited to a very specific type of workload. In a modern system, we make sure that we have a GPU for the “embarrassingly parallel” problems while reserving the GPU for single-core performance.

So, as always, it depends. In some scenarios having an engineer with 10 years of experience under your belt will be invaluable. For other things, it won’t. The question becomes how many experienced engineers do you need. For how much of the work that’s done every day in your org will our 2x work > 2x cost assumption hold? If you can honestly tell me that most of the work that its done is complex or high-level enough that experience matters that much then great. Your systems are probably very well designed.

In light of this… some potential answers to your questions.

We are spending 10X the amount on engineering salaries compared to what we use to. Why are we building so slowly?

Are your senior engineers are distracted by all of the smaller tasks they have to do? Are they are unhappy because the work they are doing is unsatisfying? Or is (see below) everything is being slowed down by the small tasks that never get done?

We have a massive backlog of small tasks that never get done.

The type of work that is exciting changes for each developer as the move through their career. When I started as a dev I loved making changes that I could see the result of quickly, even if they weren’t complex or massively challenging. I had a phase where I loved cleaning up bits of code that hadn’t seen some love in a while. Now I would much rather be doing “design heavy” programming where the goal isn’t just to get something working but to make sure it’s going to be usable and extensible for years to come. If you have all of these different types of tasks to be done then the best (and kindest!) way to make sure they get done is to hire people at all career stages. And remember that most people are happier to stretch themselves with a task than they are to sit and do easy things all day.

We are spending a fortune on hiring.

Senior developers are hard to recruit. Their salaries are in the ranges where larger sums of money make less of a difference to them than their junior counterparts. Hiring is always going to be hard. Finding the “right” junior developers to interview is not easy either (they are going to have less on their CV for the initial filtering stage) but it is easier to hire them once you have found them.

Most of our engineers are leaving after a year or two.

Hiring mostly senior engineers is a recipe for dis-satisfaction. Not only due because they’ll end up working on tasks that don’t stretch them enough but also because it inhibits their growth in other areas: it decreases the opportunity for mentor-mentee relationships which tend to benefit both parties and it reduces the chances of them getting good leadership opportunities. These are both often high on the list of a senior developer’s desires and sooner or later they will realise they have to move in order to fulfil them.

Flat structures are great but people need a path forward for their careers and that usually requires leadership opportunities whether you’re are on the management or individual contributor track.

* Replace 2x with whatever multiplier takes your fancy ¯\_(ツ)_/¯

Climbing down from the ivory tower"

Thu, 30 Apr 2020 00:00:00 +0100

I think this is gonna take three parts:

Context: What I actually did, what I am doing now.

I started at med school in Oxford. I took a pause halfway through mainly because I was frustrated with wrote-learning facts when I knew we didn’t have good ideas about why those facts were true (i.e. we don’t have a deep understanding of how most medicine works). I started a PhD in neuroscience (because brains are cool, fight me). Then, I don’t know what came first, the realisation that the scientists who I respected were deeply skeptical of most published work, or the realisation that I wasn’t sure that I would trust my own work if it were presented to me by someone else. There are human/incentive parts to the problem as well as technical ones but even the hardest technical problems are easier than human ones so I dived into them trying to drag the best software engineering practices that I could find on the web into the work I did as a scientist. Sometimes this work made other peoples lives easier, and I enjoyed that, but it didn’t change the system I was working in and I didn’t want to stay there.

Working anywhere where the incentives are out-of-whack with the way you want to work is tiring. And after 4 years of that I didn’t have the energy to jump straight back into medical school. I figured I could get a cushy part-time job as a software engineer to pay the bills and spend the rest of my time thinking about how to help fix the system that I had removed myself from. When I joined Babylon, I knew that wasn’t going to be the reality, it was a 4-day a week gig and I was genuinely excited by some of the work I had been told about. Since then, I have still been doing some work for the folks back in the lab in Oxford. Almost entirely on projects that I was told not to waste my time on as a PhD student (don’t get me wrong, these projects were a huge distraction from my PhD, but I knew they were important and that it was pretty unlikely that they were going to get done otherwise). That said, it means I still have a pretty good window on what academic life would be for me now if I’d stayed, and so I think I’m in a good place to contrast the changes in life, both good and bad, that come about by moving from acedemia to tech.

Life: How my life has changed moving into industry.

Lot’s more people use the work I do.
Less say in the projects you work on. Sometimes that is a huge releif.
Playing a supporting role is valued.
I have a line manager whose job is to be a manager. In acedemia you may be lucky to find a boss who cares about you, I’m sure mine did, but having someone who has the time, training and incentive to support you is another thing. Obviously this isn’t a given in industry, there are lots of terrible managers, but in acedemia the system doesn’t even acknowledge the role of manager as separate from senior leadership and thus even good bosses will have a really hard time being a good manager.

Software: What is the difference between research software and “production” software.

“Most reserach scientists don’t use version control” [Shocked faces]

For me there are two drivers that make this difference. Everything else stems from them:

A single piece of production software is usually written by a team not an individual. Conversely the vast majority of research software is written by one person.

A whole bunch of tools that make software better are valuable when writing software on your own. But the overhead of learning/using them can be difficult to overcome (especially if you are the only one who you think is going to use it - see point 2.). But the same tools are indispensible when writing software as a team as collaboration would be too complex otherwise.

e.g.

version control - git. Shines when different people are working on different parts of a project. When your on your own you usually work on one thing at a time. In that case git is only as useful as a backup mechnanism
dependency / environment control - “works on my computer” is fine for just one person. How many computers do you use? But with a team it has to work on lots of computers for any work to be done.
code review - This one is huge. If you work on your own its basically non-existant. If you work in a team the team is responsible for the software working well and so everyone cares that other people’s contributions are correct. Importantly code review is probably where developers will do about 50% of their learning - there are things you will never know you didn’t know unless someone else reviews your code and that’s something that no amount of individual practice will get you.

Production software is made to be used by other people (i.e. not for the developer(s) themselves).
- you have to test all paths as you don’t know how it will be used
- bugs in software that’s used by other people get fixed, bugs in software that you wrote for yourself, maybe not.

Ethics: What were the ethics of working as a “basic” neuroscientist in acedemia versus as a software engineer in medical technology.

More ramblings; maybe interesting

Tue, 21 Apr 2020 00:00:00 +0100

Hey 👋. Going to be writing some things down over the next few weeks to work on the art and maybe provide something slightly less boring that sitting at home staring at the wall.

Thinking about:

On moving from acedemia to “industry”. How no one, even the people that are reading our work, has a clue what we* do as scientists or how we do it.
Coding and art. Am a total newbie but loving playing around with new languages and concepts and making things that you could almost call art (a bar which my hand-drawn drawings do not meet).
Why organizations should be hiring more junior developers. A lot of devs are finding their way in freelance work at the moment. That works for some but I think everyone would win if there were more opportunities for junior devs to work as part of a bigger team.

CU L8R

* I’m still a scientist, right?

Job Alert: Get paid to work on jupyter notebook interfaces

Thu, 20 Jun 2019 00:00:00 +0100

Want to hack on some crazy ideas for taking .ipynb’s to the next level? I’d like someone to help me iterate on a few prototypes for extensions on the jupyterlab interface.

(Soft) Requirements:

Javascript expertise (typescript a bonus)
Experience developing interactive applications on the web

If you’re not sure whether you fit the above, or think you have something else to offer, please enquire/apply anyway!

Desired:

Experience with Jupyter as a user
Experience with Jupyter or JupyterLab as a developer

Terms

1-2 month contract in the first instance (possibility for extension depending on funding)
2-5 days a week
Work should take place between July-November

Apply

Send an email to alex@alexmorley.me (before June 24th) with:

Two-three sentences on why you’d be excited to work on this.
One or two sentences highlighting what skills you could bring to the project.
EITHER: links to some of your relevant work (or descriptions of it if it’s not public)
AND/OR: your CV
Your hourly rate

Questions?

Ask here or send me an email alex@alexmorley.me

The Project

The aim is test potential solutions for better supporting users who use Jupyter for exploratory data-analysis.

There’s some more info in these slides. …

in this repo (a little out of date)

and in these videos & prototypes (which discourse won’t let me embed…)

Iterating / Forking as an Interface

Boo your browser doesn't support the video tag. Try this link
Click here for an interactive prototype

Notebook cells as a DAG

Boo your browser doesn't support the video tag. Try this link
Click here for an interactive prototype

Using the notebooks format to provide a UI for arranging notebooks, scripts and data sources.

Boo your browser doesn't support the video tag. Try this link
Click here for an interactive prototype

Jupyter Flow

Fri, 26 Apr 2019 00:00:00 +0100

Jupyter Span / Graphical Notebooks

Computational notebooks that reflect the mental model of humans

A core tenet of user-centered design is that user interfaces should, as much as possible, reflect the prior mental model that the user has of a process. Just as syscall API hides hardware-specific details from programmers developing applications, abstractions at each level of a user interface offer an opportunity to reduce the mental load on the user, enabling them to perform more complex tasks and make fewer mistakes. However these abstractions, however well implemented, will often have tradeoffs in terms of the complexity or performance of the application.

Computational notebooks, such as Jupyter and Wolfram, have had broad success by reflecting in their interface an existing user model i.e. “this code produces this visualisation” by allowing multimedia to be embedded as part of a script. Jupyter has arguably had more success not only because it is free software, but also by piggybacking on existing programming languages which allows users to transfer previously applied models into a new context, rather than having to learn something new. Both types of computational notebooks also reflect the modularity inherent in analysis pipelines, reading in some files might take more than one line of code but most of the time we just want to think about the process as “reading in the files”. In programming language design this is solved using functions, modules and namespaces, in computational notebooks it is reflected in the UI in the form of code cells.

Through personal experience, and observations of wider usage patterns of Jupyter notebooks we have gleaned that there is still room for moving even closer to the user’s mental model of how code should be organised for data analysis. We propose design a new user interface that capitalizes on what Jupyter already does well, and fills in the gaps where they exist. In our first prototype we aim to support:

Branching Paths: reflecting the generally non-linear flow of exploratory analysis and testing
Hierarchical Modularity: Allow collapsing and grouping of cells for organisation. Indeed, whole notebooks can be included as one unit of computation in another notebook using this framework.
Modularity II: Allow naming and documenting to be explicitly linked to code cells. Allow decoration of code cells for easy recognition while they are collapsed.
Horizontal (left to right * ) progression model: Take advantage of modern widescreen hardware, and the natural reading pattern to specify workflows that flow across the screen, with branches being represented by vertical splits. * or right to left depending on locale

Many of the concepts here are well validated in current / past software, the next section discusses some of this prior art as well as the goals underlying other work on the Jupyter UI.

Prior Art

Visual Programming

Wiki page

Examples:

Open Source Alteryx Alternatives

Other directions for improving notebook interfaces

JupyterLab - Desktop environment in the browser

Collab - Easy connection to cheap/free cloud compute resources inluding GPU support.

Wrattler - Data Dependency graph allowing polyglot notebooks and cacheable cells.

Proposed Interface

See Prototype here

Branching Paths:

reflecting the generally non-linear flow of exploratory analysis and testing

Feature Spec

Hierarchical Modularity:

Allow collapsing and grouping of cells for organisation. Indeed, whole notebooks can be included as one unit of computation in another notebook using this framework.

Modularity II:

Allow naming and documenting to be explicitly linked to code cells. Allow decoration of code cells for easy recognition while they are collapsed.

Horizontal (left to right * ) progression model:

Take advantage of modern widescreen hardware, and the natural reading pattern to specify workflows that flow across the screen, with branches being represented by vertical splits. * or right to left depending on locale

Explicit linking of figure to code diff

In a given session, it should always be possible to view the answer to the question: what were the code changes between Figure (state) A and Figure (state) B? Importantly Figures (states) A and B can be any Figure (or explicitly saved state) generated during the session.

Process and Design Principles

Accessibility

Ease of sharing
First-Class support for Offline / Limited Connectivity scenarios

User Centered

Always aiming to reflect mental model that people already have.
Finding current pain points in notebook use.
Get user feedback early (from now) and often.

How to fork / branch?

Simplest implementation is to run from start until the branch point then update cells on the new branch after the branch point only when selected.

Communication between branches: No they should be independent
Threads vs. Seperate instances: Seperate instances for backend to start. In browser should be sandboxed as well.
Copy memory vs Run from start: Run from start for now. Copy could be implemented later on as an optimization.
Where is the logic implemented: Front-end? Will work for iodide and jupyter. Back-end? Easier and maybe more powerful, + will need some backend logic for jupyter either way.

Mozilla Fellowship Update

Sat, 30 Mar 2019 00:00:00 +0000

Just in case y’all wondering what I’m up to at the moment (other than writing my PhD thesis…). Contributors and comments welcome for all projects. More information in the links!

Lead / Solo

:wrench: Tool
Back Your Scientific Stack A proposal to emulate, and build upon, the work done by backyourstack.com, in order to inspire recognition and funding for the open source projects that a lot of scientists rely on. The core goal is to encourage funders to accept (and grantee’s to apply for) donations to open source projects as part of their grant.

:wrench: Tool
Feed.Me A browser-extension to customise (social media) feeds client-side. The aim is give anyone the power to take control over the algorithms that dictate what they see on social media.

:floppy_disk: Database
Meta Open Database
Our aim is to create a database that will provide, and link, information about the multitude of factors that determine whether a piece of tech is right for you. This project also acts as a backend to Back You Scientific Stack.

:computer: Software
Jupyter Span / Graphical Notebooks Computational notebooks that reflect the mental model of humans. We are developing an experimental new UI for Jupyter that reflects their use as an IDE for data science and seperates out this use case from report-generation.

:scroll: Paper
Continuous Research
Continuous delivery for science!

Core Contributor

:closed_book: Book
The Turing Way - A Guide to Reproducible Data Science The Turing Way is a lightly opinionated guide to reproducible data science. Our goal is to provide all the information that researchers need at the start of their projects to ensure that they are easy to reproduce at the end.

:computer: Software
Spikeforest / MountainLabJS
A framework supporting continuous benchmarking of spike sorting software. Designed for use in any benchmarking application especially where big datasets and long-running algorithms are the norm. Includes wrapping of spike sorters in singularity containers and python classes (or JSON objects), job batching, comparison with ground truth, and processing using remote compute resources.

What can Research Software Learn from Human-Centered Design?

Tue, 22 Jan 2019 00:00:00 +0000

Note: A couple weeks ago I went on a week long residency learning about human- or user- centered design. I learnt a lot, but am obviously not an expert. Thus the aim of this post is to share what I learned and my opinion about why a wider consideration of these techniques could be a good thing, rather than tell you how to run your project… Note2: I drafted this post with research software in mind -as that’s where my background is- but I don’t think anything here is specific to this domain, and so the title may be changed to reflect that.

“Organic OSS” Development

Before we get into what human-centered design is I first want to outline a common pattern that we see in Open Source software development. The pattern in the comic below is not a bad one, indeed it has served many communities extremely well. But it is important to consider the limitations of such a pattern, as well as its strengths.

Pros - there’s a lot of cool stuff going on here

“Organic” - requires little extra energy or time at the start of a project beyond what would have been required anyway.

Re-use - lot’s of people don’t have to implement the same piece of software because it’s already been done for them and shared.

Community Building - allowing people to develop the features that they want, and submit them back to the project is a great way to build community and can be a formative experience for all involved.

Cons - but also some inherent limitations

Feature Choice - the features that get implemented are often the ones that developers want which may or may not overlap with the rest of the user base.

Feedback Bias - in a similar vein, the feedback that a project will get can be biased towards developers, or those who are more tech-savvy. Furthermore, the absolute limit of the possible feedback you can get is from your user base, there is little scope for addressing a potential user.

User Experience - as a result of this, and the rest of the process lack of consideration for users outside of the developer-base can result in a worse experience for them.

Human-Centered Design

So what is human-centered design and how can it help us reduce some of the cons while keeping the pros of open software development. As the name suggests the aim is to put humans, or users, at the center of the design process. In this context, the key is that users are involved from the very beginning of the process, even in the ideas stage. The goal is to gain a deep understanding of what people need from a piece of software before you commit to building it a certain way. Then as the project evolves, we keep seeking detailed feedback that guides our decision-making. This is critically different from user research that seeks to validate decisions that have already been made (an almost useless endevour) and not limited to research that just seeks to test which of two or three choices is best (like an A/B test, although these have their place too).

User Research

As user research is critical to this design process you might be thinking, great we’ve already lost the first “Pro” of OSS development “requires little extra energy at the start”. And to some extent this is true, there is an upfront cost but first I would like to show you that there are ways to do this with a small inital time/resource investment and secondly how the value that you can extract later on will more than offset this investment.

The graph above is quite a complete overview of what different methods of user-research are possible (click on the image for a description of each of them). Which are available to you will depend on your project. An early-stage project is more likely to benefit from mostly qualitative research such as interviews or ethnographic studies. These sound time-intensive but you can cheat a bit. Instead of recruiting participants and setting up interviews you can just take 10 mins out of a coffee break with a colleague and talk to them about their experiences. Or instead of a full ethnographic field study you can ask a friend if you can spend a bit of time at their workplace with a notebook to observe what their needs are. Needless to say the more seriously you take this the more you will get out of it, but on the other hand something is definitely better than nothing. It is amazing how much more deeply you will understand the problem at hand after spending time listening to people’s frustrations and watching their interactions before you start trying to sell them on your proposed solution. Please make sure to get proper consent and take ethical considerations into account when doing this research!

As researchers and developers we might have a bias towards quantitative research methods. But, especially in the early stages, limiting yourself to these approaches will constrain the questions you can ask far more than is desirable. Qualtitative techniques such as interviews and observation allow to find answers to questions that you will likely have never even thought to ask, and these answers can be invaluable for the trajectory of your project.

A quasi-quantitative comparison

Still don’t beleive me? Fine I’ll try to explain it using graphs.

View this as an Iodide Notebook

These curves assume that the ability to change a core paradigm of the software you are building has an follows an inverse logistic function, and the probability of you finding out that the paradigm needs to change is linearly related to the number of users your project has. For the user centered design curve we are better able to find things that need changing at the very start of the project, when it is easy to be able to make these changes.

That might be a little contrived but the point stands, human-centered design is not only a great pattern for user experience, but also allows you to -I hate using this phrase- “fail early”, which is presumeable a good thing.

Acknowledgements

I am currently a Mozilla Fellow and my attendance at Simply Secure’s underexposed design residency in Berlin was co-sponsored by the Software Sustainability Institute. Check Simply Secure’s page for more user research (and security) goodies and the SSI’s page for more research software-related content.

Data Science for Experimental Design - loopy stuff

Wed, 17 Oct 2018 00:00:00 +0100

It’s not a new concept. But when people talk to me about improving the scientific process it really resonates with me when they talk about feedback loops. This framework is broad enough to encompass most ways in which we can think about improving science, but also makes explicit what actions need to be taken, and where bottlenecks are likely to arise. Here are a few examples of how people have used these cycles to make/explain progress/problems in scientific processes.

Examples of feedback looks in the scientific process.

Pre-registration prevents hacking of the scientific feedback loop - Chris Chambers. Find out more here.

So I was super excited when the first thing I saw at the Data Science for Experimental Design workshop, held at the Turing Institue, was Daphne explaining how we were going to cover each part of the cycle. Unfortunately I haven’t been able to get a copy of that slide yet, but from the other images you might be able to imagine how it might look.

Loop Number 1 - Optimising Experimental Design

The first two talks of the day discussed optimisation algorithms for experimental design. Here we focus on how we can implement closed loop systems that enable us to run experiments that make optimal uses of the resources available, both in terms of time and cost. We were told how finding solutions to these systems can be hugely computationally expensive, and discussed some potential avenues to find shortcuts that are just as good. It’s worth noting that this type of work involves collaborating with statistians and data scientists in the planning stage of an experiment. All too often we reach out for advice try to solve our inference problems after the data is collected, by which time it may already be too late.

Loop Number 2 - Automating the discovery loop

Adam, the first ever robot scientist. Then we moved on to the next level of abstraction, how much of the scientific process can we automate. Ross King told us about Adam, a machine he claims is the first ever robot scientist. In Richard’s view, one of the key steps to sharing science in a reliable way is to use formal, logical languages, rather than natural ones like english or mandarin. By programming a machine using these languages, Richard’s team could extract all the steps from a high-level goal, e.g. “What does this yeast gene do?”, down each layer of abstraction to the observations made on the sensors of the machine.

In the last session before lunch, Dr Vishal Sanchania from Synthace, described Antha, a software platform that has a somewhat smaller remit that Richards robot scientists, but works out of the box with a wide range of hardware, and an thoughtful user-interface. This level of abstraction seems appealing, but many members of the audience were concerned about the lack of clarity in the availability of the source code, or whether there would be an open API that would freely allow third party customisation.

After the break we had the reproducibility crew and Dr Rachael Ainsworth and Dr Sebastien Besson. Dr Besson spoke about his lab’s project The Image Data Resource and Omero. One of the key points in the scientific feedback loop is other researchers being able to explore the data that lead the original authors to make the concolusiont that they did. These databases allow anyone to explore all different types of image data and metadata in their web based browsers.

Dr Ainsworth then took us on a whirlwind tour of open science. From why you should do it, why your worst collaborator is yourself in 6 months time (hint: your past self doesn’t reply to emails), and some great re-mix and re-use of materials from colleagues open science talks.

Structural and Cultural Barriers to Implementing Optimal Feedback Loops

“we need to make sure we consider the effects of the changes we seek to drive in as many different contexts as possible [or …] we risk not only being ineffective but actively contributing to existing societal inequalities”

To close off the day three scientists with sociological backgrounds lead discussion groups about cultural and contextual considerations for moving forwards with Data Science for Experimental Design. For me two themes resonated loud and often in these sessions, in terms of what we as scientists should be doing to be effective, 1) we need to actively engage those with expertise in driving institutional change to help us in our efforts 2) we need to make sure we consider the effects of the changes we seek to drive in as many different contexts as possible. The latter point is especially important, what works to increase accessibility to science in one context may not work in another, and without taking these considerations into account we risk not only being ineffective but actively contributing to existing societal inequalities. These considerations might be technical e.g. considering low-bandwidth internet users when you share data, or not, e.g. using graphics to aid those who find large sections of text difficult to understand. This can often be extra work but remember also that the wider the audience you consider the wider the audience you have the potential to reach.

Alex Morley, PhD

Healthcare Tech Substacks

Health Trends

Grenz on Health

Insight

the-best-parts-of-the-internet

Hire junior developers

Why do we hire senior engineers?

In light of this… some potential answers to your questions.

Climbing down from the ivory tower"

More ramblings; maybe interesting

Job Alert: Get paid to work on jupyter notebook interfaces

(Soft) Requirements:

Desired:

Terms

Apply

Questions?

The Project

Iterating / Forking as an Interface

Notebook cells as a DAG

Using the notebooks format to provide a UI for arranging notebooks, scripts and data sources.

Jupyter Flow

Jupyter Span / Graphical Notebooks

Prior Art

Visual Programming

Examples:

Other directions for improving notebook interfaces

Proposed Interface

Feature Spec

Process and Design Principles

Accessibility

User Centered

How to fork / branch?

Mozilla Fellowship Update

Lead / Solo

Core Contributor

What can Research Software Learn from Human-Centered Design?

“Organic OSS” Development

Pros - there’s a lot of cool stuff going on here

Cons - but also some inherent limitations

Human-Centered Design

User Research

A quasi-quantitative comparison

Acknowledgements

Data Science for Experimental Design - loopy stuff

Examples of feedback looks in the scientific process.

Loop Number 1 - Optimising Experimental Design

Loop Number 2 - Automating the discovery loop

Loop Number 3 - Sharing, Evaluating, and Re-Using

Structural and Cultural Barriers to Implementing Optimal Feedback Loops