Thread by @Lynoure

I am figuring out what useful being in a hospital can teach me about software development.
I will post my observations into this thread
1/n

Introducing yourself helps to put people at ease and build trust. Don't be a random person asking questions, make sure people understand why you have interest in those questions
2/n

People wait more patiently after you have established the trust that you are busy doing important things and not goofing around
3/n

Staying open to outside inputs helps the hospital rooms and your design to stay fresh and non-pathogenic. If you only rely on internal inputs, stagnation and staleness will easily ensue.
4/n

Seemingly same problematic symptom might result from different causes. If the inputs are unknown, judging the importance of fixing the problem is very hard.

Be conscious about test setups. Comparing data is easy when the xray series is always from the same angle, or the load tests have all same background conditions.

To see the effect of a change clearly, try to have a setup where no other changes randomly take place.

Do not schedule major operations when short on staff or when the staff needs to be busy with something else.

Design software to work without network when possible. The users will love you for it.

Thank you @netflix and @ExpanseSYFY for making my hospital stay more pleasant!

Name things clearly but do not relay on naming alone. Design in a way that makes accidental misuse difficult or impossible.
#hospitals #softwaredevelopment

Also, in hospitals, the more often an operation is performed, the less scary it becomes. In IT, that applies not only to releases but also to code reviews, demos, usability testing and so on.

Informed consent is essential in health care. GDPR made it very important when it came to users of software as well, yet we could do better at improving customers about the potential consequences of their feature requests or technical preferences.

When a procedure or project requires cooperation from multiple people, get everyone informed, and committed to the planned timeline. "Need to know" is only a good strategy when some people need to not know.

Surface level observation is often insufficient to reveal what something actual is about. Use the context for hints and examine things critically. Ask questions. (Unfortunately this is not water, but luckily it's not lye either.)

Know how your scheduled activities affect your load. After meals there seems to be more call buttons pressed. After an upgrade, there will be more contacts to the customer service.

When fixing a live system with the customer screaming next to you, it's likely that the fix ends up less than ideal. Hospitals really cannot avoid fixing problems in the production environment, but you probably can. Always aim to calm down the customer, too.

The human body has two of many parts, yet, for most of those, both instances are needed for full functionality.

When adding replication for reliability, do not let using replication for scaling run you into a situation where you need have all of the instances running.

Speaking in a way the patient understands is life-or-death important in health care. It's also essential in software development to keep the outcomes healthy.

Symptoms and complaints can easily cover other symptoms and complaints. A patient might not notice their pain if they are busy feeling nauseated. A customer doesn't feel the bad UX when the site is down.