tychof

Please understand that something you think is helpful may not be. You should assume it isn't unless you have specific knowledge of the person involved.

In general, the bereaved don't need platitudes which cheapen their loss or try to fast-forward them through the grieving process. Don't presume to know what the deceased _or_ the bereaved feel or _should_ feel, and don't assume they share/d your beliefs.

Instead of 'comfort and a kind word', try 'comfort' until you are asked for more. Be present for those who are grieving. Offer to help in any way you can if you can, and help when called upon.

Just listening is profoundly useful. Often, they're not really listening to you anyway.

The types of your nodes probably don't have much to do with any algorithms you may be writing. Consider your algorithms as functions which act on an interface. Keep your graph data within a type which adheres to that interface. Then you only have to duplicate the type and not the algorithms, and you can easily create new types which the algorithms can use.

Even if you stuff the algorithms into the same type you have your data in (like most generic languages seem to encourage you to do), you still only have to type-cast/type-switch on getters and callbacks. And the only major missing requirement I can think of is that your nodes aren't guaranteed to be of homogeneous types (and you can hack that with a callback if you want).

One benefit to TDD is that you become a user for your API much more quickly, and so your API doesn't need to change as much.

TDD suggests 3 steps: 1. Write one test 2. Write the minimal code to make it pass 3. Refactor the code you've got.

Try not to think of tests as immutable. You can throw away tests when they don't provide value.

Finally, make sure you're using an IDE with refactoring support. That helps immensely when you make an API change which will affect your tests.