Comment by ryandrake
3 days ago
Absolutely amazing. Well done, Garmin. Imagine getting to go to work everyday to work on something that actually saves lives. Fantastic systems engineering work.
3 days ago
Absolutely amazing. Well done, Garmin. Imagine getting to go to work everyday to work on something that actually saves lives. Fantastic systems engineering work.
“ Imagine getting to go to work everyday to work on something that actually saves lives.”
I work on medical devices that improve and save lives but the work actually kind of sucks. You spend most of your time on documentation and develop with outdated tools. It’s important work but I would much prefer “move fast and break things”. So much more interesting.
Well, I'm glad it's that slow. I can't shake the idea of the horrors it would be to get a glucose pump whose software has been vibe-coded.
I work on team managing safety critical code. Management has asked to increase our AI usage, especially for generating requirements.
2 replies →
I certainly get it. But I also am very frustrated with the snails-pace development of closed loop glucose pump system. The tech has existed for quite some time to implement them in theory. Body hackers have already done so a decade ago.
I often wonder if we have created the correct balance here. How many quality of life years have been lost due to the decades lost by being conservative? And how much of the conservative pace is done for the “right” reasons vs personal or corporate CYA?
1 reply →
Not to invalidate your experience, but I think both of you feel this way because “you only want what you don’t have”. There are different kinds of joy that come from being impactful, and different kinds that come from moving fast. If only we could move fast and be impactful :’(
I could be fast and impactful. Just in a negative way. The problem is that I come from the software dev side so I tend to be less interested in the medical side. It’s the same in a lot of safety critical. There is a lot of mundane work to tick the necessary checkboxes. There isn’t much that is interesting from a technological side. Maybe the result is interesting but getting there takes a lot of extremely boring work.
7 replies →
Lots of the moving fast stuff is very impactful, just often in a bad way.
> develop with outdated tools
I suspect a lot of aviation is the same.
Many private planes use outdated tech, carbeurated piston powered engines driving propellers.
Maintenance heavy, but all of it is well known and stable.
What is in this particular case that requires outdated tools? If they are code, certainly you can write them on VS Code or whatever you likes, and only need to compile and load on the original tools, can’t you?
It’s more the library and language side. Typically you are years behind and once a version has proven to be working, the reluctance to upgrade is high. It’s getting really interesting with the rise of package managers and small packages. Validating all of them is a ton of effort. It was easier with larger frameworks
Sometimes it's because you need to support ancient esoteric hardware that's not supported by any other tools, or because you've built so much of your own tooling around a particular tool that it resembles application platform in it's own right.
Other times it's just because there are lots of other teams involved in validation, architecture, requirements and document management and for everyone except the developers, changing anything about your process is extra work for no benefit.
At one time I worked on a project with two compiler suites, two build systems, two source control systems and two CI systems all operating in parallel. In each case there was "officially approved safe system" and the "system we can actually get something done with".
We eventually got rid of the duplicate source control, but only because the central IT who hosted it declared it EOL and thus the non-development were forced, kicking and screaming to accept the the system the developers had been using unofficially for years.
1 reply →
You need tracability from requirements down to lines of code. It's a very painstaking process.
1 reply →
Oh, you could "move fast and break things" in your current job. For a while... ;)
(please don't)
You'd be even more impressed if you saw just how little resources they have to use (ram, storage, cpu), or how old of a C standard they have to work with. I have a few friends that work on this.
I am indeed impressed but not at all surprised considering what we used to get to the moon!
Seems like Java is popular at Garmin.
And also — sadly — Monkey C. I cannot imagine what possessed them to invent their own scripting language for wearable device apps. It's sort of like JavaScript but worse and with minimal third-party tooling support.
https://developer.garmin.com/connect-iq/monkey-c/
4 replies →
While I might not trust C code more than Java in life saving equipment, I would trust a median C developer over a Java one.
1 reply →