I've worked on a variety of medical devices: CT scanners, patient monitors, infusion pumps, radiation therapy devices, contrast injectors, dialysis machines, assistive devices for the blind.
Last year I had to go to the ER it was pretty cool to see that some of the equipment was stuff I've worked on. I needed a CT scan with contrast, I had worked on the standards body that defined the protocol that allowed CT scanner talk to a contrast injector, and they were using the device I worked on with the feature I defined and implemented.
I’ve worked on medical device stuff too, and it’s not like anything else. I’ll never forget the first time I found out that code I’d written had saved someone’s life. I’d done plenty of awesome things, and in that moment they all felt small.
That's fascinating. Sadly, based on the quality of software engineering I've witnessed (and produced) over my career, if I were to find myself having to trust my life with any of it, I would be terrified.
That's when you beat on the code until you aren't scared. Don't let the code out the door until you've unit tested, integration tested, QA'd it to hell and back.
If it's some random cat pic frontend website code and it breaks, yeah whatever, just fix it as it breaks because you have the luxury of hourly deploys. but on the other side of the spectrum, if you're writing firmware and it's isn't remotely updatable, you don't just sling the code over the wall in the same way. in that realm you have the luxury of an actual spec and a less complicated system.
everyone gets scared. what you do in the face of it is up to you.
I had to deal with some of projects you mention. At least where I'm from (italy), we rely on a bunch of old proprietary and very sh* technologies that I think it's really killing patients (metaphorically speaking... or maybe not...). The thing is that most of people aren't asking AI/the superb cure, but something that just works.
I'm fairly familiar with infusion pumps, where bad software regularly kills patients. Just look up "infusion pump software recall" and you'll find dozens and dozens of very recent examples of how bad software implementations have led to a lot of preventable deaths.
I have some friends trying to fix this[1] and they have amazing tech, but it's a difficult industry to break in to.
I wrote multiple systems that import most of the tax return data for the Finnish Tax Administration, a system that imports payroll data (and helped with the previous version of the system), and tax payer data extraction for other government agencies. Downstream process use this data to automatically fill out taxpayers' tax returns in Finland each year, and individuals only file tax return corrections. So if everything looks good, which happens for 90+% of taxpayers, there's nothing to do each year. We even won a few awards for the project.
I'd love to, this is exactly the use case for digital technology; automate the stuff we can making more time for more meaningful taska for everyone. Finland is ahead of it's time for these kinds of integrations. Problem is, it requires a central authority having all of the data, and the US has absolutely zero trust in it's government to not fuck it up. With good reason
Is that true that one can see everyone's salary in Finland? Or was it only for those above EUR 100k?
Can people outside of Finland see it? Doesnt this attract thieves? They know whom to rob.
What is the impact on dating scene? Do rich people put full names on Tinder?
Not sure in Finland but in Sweden yes you can see everyones salary (or more correctly you can see their income from salary. So if you got salary from two different jobs you just see the aggregate). Doesnt matter how much or little. And yes, it is def being used by criminals (on the other hand I'm sure it isnt hard to figure out in the US who is rich or not based on their lifestyle)
Yes I believe you can look up anyone's salary in Finland, but you have to officially request it, and not sure how that's done. Some organization requests all the high earners and posts them online, so those above that amount can be identified. Everyone knows about it but find Finns are "if you have it, don't show it", and so it's not a problem as far as I know. It's the same as companies being transparent about salaries, it seems absurd to those not exposed to these kinds of companies, but after being part it's not a big deal. You're either not interested, or you use it as a tool to leverage yourself up.
It was waterfall, but a lot of agile inside. Instead of development from waterfall, developers get a proof of concept up in front of the client SMEs as soon as possible, and then get it into their hands testing as soon as possible. In this way, the people working on the requirements were intimately familiar with the inner workings and offering feedback very quickly, to save time if solutions weren't working as intended. Each team would have 3-5 major projects so as soon as the first project didn't fill the full meeting, other priorities started getting their requirements. These meetings would be a touch base and rehash old topics if any solutions needed a pivot.
Once the SMEs and developers signed off on the solution, then it could go to the test part of waterfall, system test, everything launched once during the rollout window. And then maintenance mode.
Old boring tech, VB.NET and t-SQL. Never understood the hate for VB.NET, I swear it's from people misconstruing VBA, which is awful, or they had terrible infra and coding standards. The system we had was a general core product that was configurable (I mean, taxes are the same, they just have different rules), but also customizable. Finland wasn't the first international project, but it was maybe the biggest one, so a lot of the solutions ended up being custom for the project. Unfortunately been difficult to find work with the boring tech background, but it was enjoyable (especially considering it was taxes).
I wrote a Tampermonkey script which more or less was a true 'automate someone out of a job' situation, except it didn't do that at all; it freed up 20+ hours a week that someone had to sit there and do this awful manual thing with vendor portals, csv's, and spreadsheets.
I haven't worked at that job for almost a decade, and last I heard it's continued being used with only a small amount of maintenance.
That's the most compliments I've ever gotten for any software I've ever written and it had very real human impact.
Reminds me of my first job out of college as a data analyst. At least 60% of the work was extremely repetitive spreadsheet work and emails. Wrote some macros and automation scripts to do almost all of it in ~3 minutes instead of 4 hours and spent the saved time doing more interesting things that led to my next job.
In my case, however, I sufficiently automated the job that they didn't replace me when I left. I got a call ~4 years later because one of the macros broke when they finally updated Excel. Fixed it for a small fee, and to my knowledge they're still using it today.
When I started my job as an intern, I was surprised to learn that before each release, the techlead of our team would always manually verify every commit in the release branch to make sure that the issues in the issue tracker that correspond to the commits are actually marked as "to be merged" and greenlit by QA, that there's no commits accidentally merged from other branches which aren't ready for a release yet (juniors often mismerge by accident), he also checked that all commits from the original feature branches were merged and none were missed (happens sometimes) etc. It would take him 1-2 hours to sift through all commits every time (each release would incorporate tons of features/fixes and commits weren't squashed, so there was a ton of work). The techlead also didn't allow anyone to do this work because he feared people wouldn't be as attentive as him. I remember there was one time when it was 11 PM and he was still verifying the commits and the release managers had to wait and couldn't go home.
I wrote a script which finds new commits not present in the master branch and compares them to the corresponding issues in the issue tracker (each commit message has an issue ID as a rule so it's easy to find the connections), and then generates a nice report like "the release branch cannot be released as is because issue 1234 is not marked as ready by QA, while commit 3456 is not present in any of the listed feature branches and could be a result of an accidental merge".
After we started using this script, the time it took to verify release branches decreased to something like 10 minutes. The techlead finally decided to delegate this kind of check to other devs (not a bottleneck anymore).
The idea was then copied by all other teams (web devs, etc.) and the script is still in use today, with many more features than I originally envisioned.
That small silly script was probably my most useful contribution because it saved a lot of time for everyone.
We had something similar at an old job. It was pretty nice as then you were allowed to release your changes whenever as long as all the changes up to yours had been tested.
I was first employee and only software engineer for 12 months at a startup working on increasing large scale solar power penetration in electricity networks globally. Worked there for 4 years solving all sorts of interesting problems working with meteorologists and electricity network specialists to build solar power forecasting systems. Implemented direct integration with several national electricity markets putting forward bids on 5 minute power generation which indirectly controlled many utility scale solar farms. This and more while keeping costs down and whole company to less than 10 people. Put lots of automation in place early on which enabled this as people joined. Having good monitoring solution along with CI from day 1 was a great enabler.
The project moved the needle for the amount of solar power that could be confidently installed into electricity networks in Australia, and many countries around the world. I got heavily burnt out, didn't get any equity, and initially took a substantial pay cut to work there, but on balance still the most impactful work I've done, and will be hard to top.
Working on medical devices. It’s mostly modern C++, it’s demanding, you need to write a lot of unit tests and documentation (it’s the law), and the specs must be good (well, at least better than other software), but it’s really fun and useful in the end, and you learn a lot of things that can make you write better software in other fields.
I really think every SWE should spend a few years writing this kind of thing to be better.
Saying this as someone who's done medical devices for close to 20 years, the only thing we know that you may not is that we have to follow procedures, or else.
I learned writing medical software but I did way different things before. Anyone can learn that too. It’s just "enhanced software development," there is nothing magical about it. We have a healthy mix of young and old people. There are more women than in other software companies. It’s fun and, in the end, we all want to do a good job.
My whole post may be scary but it’s not. It’s still a regular 9 to 5 job and, most of the time, there are healthy boundaries. I’m not working overtime until 2AM, I just organize myself and work better if I’m in a healthy environment, and the well-defined organization is better for my mental health.
As _HeyLaughingBoy_ said, we follow procedures because it’s the law. Most of the time it’s respected by bosses because they know that it can bite them in the ass should a problem happen. If something bad happens, I’m still not legally responsible though but I’ll feel guilty inside, that why it works too for the motivation but I don’t think about it every day, I do my job like a regular job. Also nothing bad ever happened because of my code, the real motivation is the good things that can happen.
You can make mistakes, but if someone is injured because of a bug, the whole company will have to figure out where the process was not followed properly. You still can be fired for various reasons, but I’m pretty sure that someone will notice that I fucked up before it is released.
The main procedure is called the "ISO 62304" and you may find the PDF on pirate sites if you want to see what it is about. Every medical software company tries to follow it because it is mandatory to get all the certifications. Some companies do take it more seriously by paying for training for the devs which is nice.
I interact with real QA people who take their job seriously. They will write Jira tickets for literally anything that is not precisely defined in the spec. Sometimes they will piss me off for small details but I can’t avoid it, they are part of the process and there is no negotiation.
We also have UX teams who define the best colors and placement of the buttons in the final product.
Most of my job is writing standard software, and nothing critical, but the work is the same. If you have a bug, it must be linked to a spec. Sometimes you have to find the spec, write it, or bother your boss until he finds the spec. Then you write the code and the test to cover that spec. A bug is never a simple bug, it’s a deviation from a previously defined feature, and fixing it needs you to interact with different teams as part of the whole process: Did it happen in production or not? Is there a spec? Where is the spec? Fix the bug, write the test, optionally make sure that it has code coverage, annoy the QA team to validate that it has been fixed, and make sure that you have documented your fix in all the web tools (docs, user manual, GitLab PR, Jira, QMS stuff…). The QA team may also write their own automated tests in addition to unit tests.
As an example, I recently had a meeting with my boss and the QA team because I was asked to fix an obvious bug that was not defined in a specification. It looked like a bug BUT if it’s not defined in a requested feature or spec, is it really a bug? Who decides that it’s a bug if the proper behavior is not documented?
I do actually enjoy writing docs, specs, and tests now. And this whole thing made me a better dev.
Everything is not perfect though. Some companies have bad managers, bad planning, deadlines, everything like a regular company, but I can be proud of the result even if it’s a small fix that took me days to make sure that everyone is happy.
Been working on the same project for close to a decade now: remote patient monitoring in the healthcare sector. (Mainly chronic) patients get to live longer and more normal lives knowing that any worsening of their condition is caught early on by clinicians and as a result the national (usually European) healthcare services save a ton of money by avoiding (re)admissions to their hospitals, one of those rare win-win scenarios. Improved the lives of thousands of patients over the years.
911 system for my country. Was part of a small 'special unit' team and we implemented the entire system end to end. Administration, telephony system, even special asset monitoring. Best project I've worked on, and will probably have worked on in my life. Smartest people I've ever worked with.
Readit News
Last year I had to go to the ER it was pretty cool to see that some of the equipment was stuff I've worked on. I needed a CT scan with contrast, I had worked on the standards body that defined the protocol that allowed CT scanner talk to a contrast injector, and they were using the device I worked on with the feature I defined and implemented.
Its pretty cool to see your work keep you alive.
If it's some random cat pic frontend website code and it breaks, yeah whatever, just fix it as it breaks because you have the luxury of hourly deploys. but on the other side of the spectrum, if you're writing firmware and it's isn't remotely updatable, you don't just sling the code over the wall in the same way. in that realm you have the luxury of an actual spec and a less complicated system.
everyone gets scared. what you do in the face of it is up to you.
I have some friends trying to fix this[1] and they have amazing tech, but it's a difficult industry to break in to.
1. https://www.altrainfusion.com/
was this part of the DICOM protocol?
i have worked with medical imaging devices as well, but was not fortunate enough to work with the CT modality. cool stuff!
https://www.pry.fi/en/activities/news/the_finnish_tax_admini...
Once the SMEs and developers signed off on the solution, then it could go to the test part of waterfall, system test, everything launched once during the rollout window. And then maintenance mode.
I haven't worked at that job for almost a decade, and last I heard it's continued being used with only a small amount of maintenance.
That's the most compliments I've ever gotten for any software I've ever written and it had very real human impact.
In my case, however, I sufficiently automated the job that they didn't replace me when I left. I got a call ~4 years later because one of the macros broke when they finally updated Excel. Fixed it for a small fee, and to my knowledge they're still using it today.
I wrote a script which finds new commits not present in the master branch and compares them to the corresponding issues in the issue tracker (each commit message has an issue ID as a rule so it's easy to find the connections), and then generates a nice report like "the release branch cannot be released as is because issue 1234 is not marked as ready by QA, while commit 3456 is not present in any of the listed feature branches and could be a result of an accidental merge".
After we started using this script, the time it took to verify release branches decreased to something like 10 minutes. The techlead finally decided to delegate this kind of check to other devs (not a bottleneck anymore).
The idea was then copied by all other teams (web devs, etc.) and the script is still in use today, with many more features than I originally envisioned.
That small silly script was probably my most useful contribution because it saved a lot of time for everyone.
The project moved the needle for the amount of solar power that could be confidently installed into electricity networks in Australia, and many countries around the world. I got heavily burnt out, didn't get any equity, and initially took a substantial pay cut to work there, but on balance still the most impactful work I've done, and will be hard to top.
I really think every SWE should spend a few years writing this kind of thing to be better.
Honestly, that's what it boils down to.
I learned writing medical software but I did way different things before. Anyone can learn that too. It’s just "enhanced software development," there is nothing magical about it. We have a healthy mix of young and old people. There are more women than in other software companies. It’s fun and, in the end, we all want to do a good job.
My whole post may be scary but it’s not. It’s still a regular 9 to 5 job and, most of the time, there are healthy boundaries. I’m not working overtime until 2AM, I just organize myself and work better if I’m in a healthy environment, and the well-defined organization is better for my mental health.
As _HeyLaughingBoy_ said, we follow procedures because it’s the law. Most of the time it’s respected by bosses because they know that it can bite them in the ass should a problem happen. If something bad happens, I’m still not legally responsible though but I’ll feel guilty inside, that why it works too for the motivation but I don’t think about it every day, I do my job like a regular job. Also nothing bad ever happened because of my code, the real motivation is the good things that can happen.
You can make mistakes, but if someone is injured because of a bug, the whole company will have to figure out where the process was not followed properly. You still can be fired for various reasons, but I’m pretty sure that someone will notice that I fucked up before it is released.
The main procedure is called the "ISO 62304" and you may find the PDF on pirate sites if you want to see what it is about. Every medical software company tries to follow it because it is mandatory to get all the certifications. Some companies do take it more seriously by paying for training for the devs which is nice.
I interact with real QA people who take their job seriously. They will write Jira tickets for literally anything that is not precisely defined in the spec. Sometimes they will piss me off for small details but I can’t avoid it, they are part of the process and there is no negotiation.
We also have UX teams who define the best colors and placement of the buttons in the final product.
Most of my job is writing standard software, and nothing critical, but the work is the same. If you have a bug, it must be linked to a spec. Sometimes you have to find the spec, write it, or bother your boss until he finds the spec. Then you write the code and the test to cover that spec. A bug is never a simple bug, it’s a deviation from a previously defined feature, and fixing it needs you to interact with different teams as part of the whole process: Did it happen in production or not? Is there a spec? Where is the spec? Fix the bug, write the test, optionally make sure that it has code coverage, annoy the QA team to validate that it has been fixed, and make sure that you have documented your fix in all the web tools (docs, user manual, GitLab PR, Jira, QMS stuff…). The QA team may also write their own automated tests in addition to unit tests.
As an example, I recently had a meeting with my boss and the QA team because I was asked to fix an obvious bug that was not defined in a specification. It looked like a bug BUT if it’s not defined in a requested feature or spec, is it really a bug? Who decides that it’s a bug if the proper behavior is not documented?
I do actually enjoy writing docs, specs, and tests now. And this whole thing made me a better dev.
Everything is not perfect though. Some companies have bad managers, bad planning, deadlines, everything like a regular company, but I can be proud of the result even if it’s a small fix that took me days to make sure that everyone is happy.
Sadly there's just only so much of that kind of work to go around and we all have to pay bills
What do you think about the direction medical mo ignoring is going g? Data collection, enshitification etcetera.
Is it a beat up?
Are we correct to be worried?