Comment by vjvjvjvjghv
3 days ago
“ 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.
That’s not necessarily a bad thing. I often encounter badly written or conflicting requirements. An AI may be better at detecting problems or gaps than humans.
1 reply →
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?
It's a question of incentives.
For safety regulators, the incentives are all on the side of limiting acute downside (e.g. a plane crashing), not maximizing potential aggregate upside (e.g. millions of tons of fuel saved per year and millions of tons of C02 not in the atmosphere).
Society punishes regulators that approve products that kill people, so regulators adapt to this and as a result tend to be very conservative.
Regulators don't capture any of the upside (reputational or otherwise) when a new product enters the market and cures disease, makes cars more efficient, helps planes land on their own in an emergency, etc.
I don't know what "right" should be here, but you've hit on a good point. It's complicated.
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.
Maybe you should change your line of work. If you're that unhappy about what you do in spite of the fact that what you do is orders of magnitude more important than the next move-fast-and-break-things-advertising-driven-unicorn then that suggests to me that you should let someone else take over who does derive happiness from it and you get yours from a faster paced environment.
Personally, you couldn't pay me enough to do the latter and I'd be more than happy to do the former (but I'm not exactly looking for a job).
6 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.
That’s what we often do. Develop with one set of non validated tools but in the end put everything into the validated system for submission.
You need tracability from requirements down to lines of code. It's a very painstaking process.
Painstaking and often done with terrible tools and badly written requirements.
Oh, you could "move fast and break things" in your current job. For a while... ;)
(please don't)