[Writing this on my phone, sorry for the mess] I learned writing medical software but I did way different things before. Anyone can learn that too. It’s just "

[Writing this on my phone, sorry for the mess] 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.