marmalade2413

Newton's Tree | Forward Deployed Engineer, Site Reliability Engineer | London, UK | HYBRID | Full-Time | https://www.newtonstree.ai/

Newton's Tree is an early-stage health-tech startup enabling healthcare providers to select, test, deploy, and monitor third-party AI applications as part of routine care pathways. Our enterprise AI platform allows hospitals to safely and effectively adopt AI technologies at scale.

We are looking for adventurous builders to join us in two key roles to help bridge our platform and the hospital frontline:

Forward Deployed Engineer (£70k-£90k): You will be the critical link between our internal engineering team and hospital IT teams. While our SRE team focuses on core platform stability, you will own the site-specific implementations—navigating complex local networks, architecting integration paths, and ensuring our AI platform works across diverse environments. Stack: Linux, Kubernetes, JSON/YAML, Python, SQL, and healthcare interoperability standards (HL7v2, FHIR, DICOM). https://www.newtonstree.ai/job/forward-deploy-engineer

Site Reliability Engineer (£70k-£90k): You will ensure the reliability, scalability, and performance of our AI platform both in hospital sites (on-prem) and on the cloud. You'll work closely with customers to install hardware for Kubernetes clusters and collaborate with dev teams to ensure swift, reliable feature deployments. Stack: Linux, Kubernetes, Terraform, Ansible, GitOps (FluxCD), Argo Workflows, Talos Linux, Cilium CNI, Teleport, and monitoring tools (Prometheus, Grafana, Datadog). https://www.newtonstree.ai/job/site-reliability-engineer

Logistics: Both roles are Hybrid within the UK (with occasional in-person working in London and travel to hospital sites as needed). Please note that applicants must have the right to work in the UK, as we are unable to offer visa sponsorship.

To apply: Send your CV and a short note telling us why you'd be excited to work with Newton's Tree to info@newtonstree.com, or read more at the links above.

I disagree with referring to this as automatic software as if it's a binary statement. It's very much a spectrum and this kind of software development is not fully automatic.

There's actually a wealth of literature on defining levels of software automation (such as: https://doi.org/10.1016/j.apergo.2015.09.013).

Can you confidently say that the architure of the LLM doesn't include any a priori bias that might effect the integrity of this LLM?

That is, the architectures of today are chosen to yield the best results given the textual data around today and the problems we want to solve today.

I'd argue that this lack of bias would need to be researched (if it hasn't been already) before this kind of model has credence.

LLMs aren't my area of expertise but during my PhD we were able to encode a lot of a priori knowledge through the design of neural network architectures.

It's not akin to a psychopath telling you they're sorry. In the space of intelligent minds, if neurotypical and psychopath minds are two grains of sand next to each other on a beach then an artificially intelligent mind is more likely a piece of space dust on the other side of the galaxy.

An absolutely fantast book. I've read it cover to cover a couple of times during my PhD (which focused on neural networks and numerical solvers). Gives the right amount of depth to serve as a detailed introduction whilst covering a lot of the key areas in optimisation. I still use this book as a reference years later.

I recently picked up Gleam for a small medical imaging project and I can quite honestly say I've never had more fun with a language. Docs are great and the whole language is small enough to be learned in about an hour.

Thank you! Ah I may need to work on improving the RSS reader. It seemed to work with my newsreader but it's far from perfect...

Yes! It's not hosted via Emacs but here's the static site generation process: https://abdrysdale.phd/colophon.html

I would be remis if after reading this I didn't point people towards talk box ( https://github.com/rich-iannone/talk-box) from one of the creators of great tables.

Adding fuel to the fire of "this is over engineering" but this is overkill right?! I'm not in the web development field but my own site is just deployed with Emacs (specifically HTML generated from org-mode).

I was going to write a response but you've put what I would have said perfectly. The problem, at least in academia, is the pressure to publish. There is very little incentive to write maintainable code and finalise a project to be something accessible to an end user. The goal is to come up with something new, publish and move on or develop the idea further. This alone is not enough reason not to partake in practices such as unit tests, containerisation and versatile code but most academic code is written by temporary "employees". PhD's a in a department for 3-4 years, Post Doc's are there about the same amount of time.

For someone to shake these bad practices, they need to fight an uphill battle and ultimately sacrifice their research time so that others will have an easier time understanding and using their codes. Another battle that people trying to write "good" code would need to fight is that a lot of academics aren't interested in programming and see coding as simply as means to an end to solve a specific problem.

Also, another bad practice few bad practices to add to the list:

* Not writing documentation.

* Copying, cutting, pasting and commenting out lines of code in lieu of version control.

* Not understanding the programming language their using and spending time solving problems that the language has a built in solution for.

This is at least based on my own experience as a PhD student in numerical methods working with Engineers, Physicists, Biologists and Mathematicians.

The key elements that I consistently see missing when comparing languages is the cost/effort of maintenance and how easy is to write fast/slow code.

The former boils down to, there's little point saving time in the writing of new code when new versions of the language hinder the use of old codes. Julia, being a very young language, simply does not have the legacy of backwards compatibility that Fortran has and as a result libraries written today are unlikely to work in 10 years time. Partly because of Julia's age and partly because backwards compatibility is not valued as much as it is in Fortran. The GNU Fortran compiler can still compile code written nearly 50 years ago (https://gcc.gnu.org/fortran/).

The second point is that benchmarks like this seem to focus on tuned implementations, which is really important, but another important aspect is how easy is it write fast code. With Fortran, it is very easy to write very fast code as a lot is abstracted away from the programmer so they can focus on FORmula TRANslation. My experience with Julia has not been the same and thus for people don't have the time to perform such optimisations, Fortran may still be the better choice.

I do look forward to watching the development of Julia but for now I'll stick with using Fortran as the high performance numerical language in my tech stack.

I'll finish with something I've read but I can't remember from where:

Over the years there have been many examples of "X with replace Fortran" and the only thing that ends up getting replaced is X.

The choice of 1 based array indexing is due to Julia having it's roots in mathematics - which is a common choice for mathematics based programming languages (e.g. Fortran, Julia, MATLAB/GNU Octave, Mathematica, R and Wolfram). The reason being is that matrix notation starts at 1 and not 0.

For a comparison on array indexing in different programming languages see here: https://en.wikipedia.org/wiki/Comparison_of_programming_lang...

From personal experience, I wouldn't let something as simple as starting index getting in the way of programming for a language as you'll soon start automatically switching to thinking in 1 based and 0 based indexing depending on the programming language.