10 ms·

“ 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 ac

“ 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.

pinkmuffinere 10mo ago
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 :’(
- 1over137 10mo ago
  Lots of the moving fast stuff is very impactful, just often in a bad way.
- vjvjvjvjghv 10mo ago
  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.
  - jacquesm 10mo ago
    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).
    - vjvjvjvjghv 10mo ago
      I am retiring next year. So that should solve my problem :). I don’t know how other medical device companies are working but in mine leadership is dominated by people who know medical devices from a sales or medical perspective. Software is kind of secondary to them although it’s becoming really important. A lot of our processes aren’t very good for software so we end up doing a lot of work that makes no sense and makes the product actually worse. It’s better not to fix bugs because a new release will take months of paperwork. The requirement structure doesn’t map to software but the SOP isn’t written by people who known software. It feels a little like the development speed of NASA with the SLS vs SpaceX who are basically doing everything faster and cheaper while still having high reliability . My company is NASA here. Just very frustrating
      - jacquesm 10mo ago
        I've worked with a startup in the medical device space. Well funded. They were indistinguishable from most other startups, except in one detail: they did everything right. They made some extremely high tech stuff, very lightweight, and technology wise they were closer to watchmakers than to software and hardware people. I loved working with them and helped them to improve their yield (their QA was so strict that of their initial couple of runs more than 2/3rds of the devices got binned for the smallest infractions). I suspect you may have just been unlucky with where you ended up. I'm getting closer to retirement myself but I no longer have to work for 'the man' so in that sense I got really lucky. But I really sympathize with how you feel. So, count the days, and look forward to something nicer. Best!
        vjvjvjvjghv 10mo ago
        From what I have seen startups have it a little easier. They are usually focused on one product and often just get acquired before having to go to market themselves. Selling multiple products worldwide and complying with regulations is a totally different ballgame.
        jacquesm 10mo ago
sinuhe69 10mo ago
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?
- vjvjvjvjghv 10mo ago
  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
- SoftTalker 10mo ago
  You need tracability from requirements down to lines of code. It's a very painstaking process.
  - vjvjvjvjghv 10mo ago
    Painstaking and often done with terrible tools and badly written requirements.
- jonp888 10mo ago
  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.
OptionOfT 10mo ago
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.
- AlotOfReading 10mo ago
  I work on team managing safety critical code. Management has asked to increase our AI usage, especially for generating requirements.
  - vjvjvjvjghv 10mo ago
    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.
    - OptionOfT 10mo ago
      Yes and... no. I find the risk here that the requirements are the average of all requirements, so the exceptional things don't really get highlighted. Because you now get this giant amount of text shoved in your face, you switch from thinking to validating. Is what's there correct, vs starting from a blank canvas. The doc already curtails your thoughts. Kinda like all cars are starting to look the same. No one takes risks anymore. No-one wants to / feels empowered to / has the knowledge to ask the really difficult questions.
- phil21 10mo ago
  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?
  - 10mo ago
justinclift 10mo ago
Oh, you could "move fast and break things" in your current job. For a while... ;) (please don't)
m463 10mo ago
> 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.

pinkmuffinere 10mo ago

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 :’(

1over137 10mo ago
Lots of the moving fast stuff is very impactful, just often in a bad way.
vjvjvjvjghv 10mo ago
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.
- jacquesm 10mo ago
  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).
  - vjvjvjvjghv 10mo ago
    I am retiring next year. So that should solve my problem :). I don’t know how other medical device companies are working but in mine leadership is dominated by people who know medical devices from a sales or medical perspective. Software is kind of secondary to them although it’s becoming really important. A lot of our processes aren’t very good for software so we end up doing a lot of work that makes no sense and makes the product actually worse. It’s better not to fix bugs because a new release will take months of paperwork. The requirement structure doesn’t map to software but the SOP isn’t written by people who known software. It feels a little like the development speed of NASA with the SLS vs SpaceX who are basically doing everything faster and cheaper while still having high reliability . My company is NASA here. Just very frustrating
    - jacquesm 10mo ago
      I've worked with a startup in the medical device space. Well funded. They were indistinguishable from most other startups, except in one detail: they did everything right. They made some extremely high tech stuff, very lightweight, and technology wise they were closer to watchmakers than to software and hardware people. I loved working with them and helped them to improve their yield (their QA was so strict that of their initial couple of runs more than 2/3rds of the devices got binned for the smallest infractions). I suspect you may have just been unlucky with where you ended up. I'm getting closer to retirement myself but I no longer have to work for 'the man' so in that sense I got really lucky. But I really sympathize with how you feel. So, count the days, and look forward to something nicer. Best!
      - vjvjvjvjghv 10mo ago
        From what I have seen startups have it a little easier. They are usually focused on one product and often just get acquired before having to go to market themselves. Selling multiple products worldwide and complying with regulations is a totally different ballgame.
        jacquesm 10mo ago

sinuhe69 10mo ago

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?

vjvjvjvjghv 10mo ago
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
SoftTalker 10mo ago
You need tracability from requirements down to lines of code. It's a very painstaking process.
- vjvjvjvjghv 10mo ago
  Painstaking and often done with terrible tools and badly written requirements.
jonp888 10mo ago
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.

OptionOfT 10mo ago

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.

AlotOfReading 10mo ago
I work on team managing safety critical code. Management has asked to increase our AI usage, especially for generating requirements.
- vjvjvjvjghv 10mo ago
  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.
  - OptionOfT 10mo ago
    Yes and... no. I find the risk here that the requirements are the average of all requirements, so the exceptional things don't really get highlighted. Because you now get this giant amount of text shoved in your face, you switch from thinking to validating. Is what's there correct, vs starting from a blank canvas. The doc already curtails your thoughts. Kinda like all cars are starting to look the same. No one takes risks anymore. No-one wants to / feels empowered to / has the knowledge to ask the really difficult questions.
phil21 10mo ago
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?
- 10mo ago

justinclift 10mo ago

Oh, you could "move fast and break things" in your current job. For a while... ;) (please don't)

m463 10mo ago

> 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.