Main image of article Engineers Can Learn a Lot from.... Nurses
Nursing is far afield from software engineering -- you can't argue that. My mom's a nurse and she's far better with blood than I am though I'm far better with computers than she is. But over the years I've learned a lot from her, and a lot of it has helped me be a better engineer. So for those of you who don't have a nurse for a mother, here's some advice:
  1. Checklists matter. A checklist is a quick set of reminders that help you make sure you do everything you need to do. Whether that checklist is for releasing software, or training a new team member, or remembering to look for everything during a code review, use it religiously. Sure, you don't think you'll forget things, and most of the time you won't forget anything. A checklist will make sure of that.
  2. Sometimes we need the human touch. It's tempting as an engineer to write code to solve every problem. If we do it twice, we figure we should probably script it. That's a good idea for a lot of things, but remember that humans use our system, too. Take some time to use your system manually, as a user would. You'll learn what it's really like to be them, and it'll make you write software that's easier to use.
  3. There are several possible explanations. A patient presents symptoms and frequently those symptoms could indicate several different underlying diseases. The same is true in software. One symptom (e.g., system stops logging) could be an indicator of several problems (e.g., full disk, logger crashed). Look at all the symptoms and consider multiple explanations. It's not always the first one you think of!
  4. Sometimes the only difference is time. Over time, patients and their conditions change. Sometimes simply waiting will cause a problem to get better or worse. The same is true for software. Sometimes if you can wait, a problem will go away on its own (think high load scenarios). Other times, if you wait, a problem will get worse (think unindexed database table). Time is frequently a factor in changing problems.
What advice did you get from an unusual quarter? How did it apply to your career as a software engineer?