1. 37
  1.  

  2. 5

    I can totally relate to that. I’ve been writing research-oriented software, very productively, but now I’m trying to help fellow researchers modify and adopt the code and it’s not always easy to realize how much I internalized the code. It’s 2 projects of > 30kloc OCaml and of course it must be a bit maze-like for them.

    1. 3

      I am interested in what happens when the hyperproductive developer (i.e. inventor of the system) leaves. That is a position I find myself in often in my professional career and I would love to know how others deal with it.

      1. 1

        Lots of good advice, though I think tests would slow everything down too much when my types already enforce the same invariants in a better way.

        1. 3

          Perhaps your types are more sophisticated than I envision, but it seems that there are contracts that the types can not represent and would benefit from test verification.

          1. 2

            Occasionally there’s actual logic that you can’t confidently describe in general and need to give specific example cases for - that’s the scenario where I find tests useful. But I find such cases are very much the exception rather than the rule; most of the time once you structure the problem in the right way the answer ends up following directly, to the point that it never seems like you actually needed any logic at all.