Elm engineer

The role

We’re looking for an experienced Elm engineer to join our small team and help us scale our ambitions for the problems we can solve.

Over the next 12 months this could involve getting to grips with the next big iteration of our patient facing application, converting this to a design-system approach, adding new functionality for our clinicians, and building tools to visualise and explore our increasingly rich resource of data. Take a look at what we focused on in 2022.

Our design system separation means we can write functional code safe in the knowledge that we’re generating semantic markup; equally we believe in using the platform, and there is certainly scope for someone with passion for accessibility and semantics to push this forward.

Frontend context

We’re proud that we’ve built an application that is both well engineered and well designed in a context (healthcare IT) where neither is common nor expected. Our clinician users use Concentric on their hospital desktops, on tablets in patient consultations, and on their mobiles while on a ward round, while patients give their consent by scanning a QR code, by signing on a hardware signature-pad (thanks WebHID API!), or remotely after considering their bespoke consent information. We get excellent feedback from both groups of users.

At Concentric we love Elm. It has enabled us to build a robust web application used in the gnarly environment of hospitals across the UK, and by over 100,000 patients across every device imaginable. We’ve written code once (e.g. our event sourcing infrastructure) which has been rock solid for years with barely an edit to the code. We’ve solved crazy problems like ontology graph traversal and filtering in the browser, and it’s just worked. We’ve written loads of view code, with layers upon layers of TEA (The Elm Architecture), which means we can focus on one thing at a time without playing bugfix whack-a-mole.

We recently rebuilt our clinician frontend around a custom design system, replacing literally all the HTML and CSS, a mammoth task that felt manageable only because of the Elm compiler and elm-review keeping everything working every step of the way.

The vast majority of our frontend code is written in Elm, while JavaScript (which represents ~5% of our frontend codebase) mostly fills a progressive enhancement role. This means we can mostly ignore the JavaScript and node ecosystem, looking on with bemusement from a land of safety and stability.

We don’t believe in a strict separation between frontend and backend roles and so would also welcome applications if you’re looking for a more full stack role. See our backend and data engineer job description for more information on what we’re doing there.

The ideal candidate will…

• have at least 5 years engineering experience.
• have experience writing Elm or another FP language.
• write great HTML and CSS.
• have written code for the backend and frontend.
• have strong engineering design sensibilities, likely gained by writing code using multiple languages and frameworks.

We would be particularly excited if you…

• have written Elm commercially.
• have experience using or maintaining a design system.
• have wider experience of functional programming.
• have an interest in data visualization.

Our approach to engineering

Our general engineering ethos is to take our time, build it properly, and to sweat the details.

We believe that it’s critically important to find a simple design; that working code is not enough and that the future complexity cost of compromise after compromise is simply not a good trade-off. Simplicity also means communicating changes clearly and treating the git history as a communication medium. Often simplicity also means minimising dependencies.

We’re not afraid to make unusual technology choices – for example our use of Elm and Crystal – when we believe these are better than other mainstream choices (mainstream /= good). But equally, boring is often best and we try to avoid jumping on each passing fad.

Although Concentric may be ‘enterprise software’, we aim for it to be anything but. We prioritise good design, we don’t charge zillions for custom integration (it’s included in the fixed cost), we do our best to avoid special-snowflake customisations, and we don’t deploy on-prem. We simply write good software, and deploy responsibly after a thorough internal QA roughly every 2 weeks. So far this is working pretty well for us.

If this approach resonates, we’d love to hear from you.