1. 4
  1.  

  2. 4

    For me the meat of this essay would be this quote:

    Cross-checking is simply asking yourself, perhaps in code, what the minimal solution looks like. Then, no matter what happens later, you know how much work you could have done to get the same result.

    I usually like to ask “what is the stupidest and laziest way we could deliver this feature”, and then jump off from there (see Brooks’ “buukf a test plant”).

    The thing that’s a bit scary about asking that question, especially in orgs with established “modern” devops practices or codebase with deeply entrenched architectural decisions, is that it will inevitably reveal a growing chasm between what would be the fast, simple, and legible way of doing something and the development realities of your org. It will cause SAN damage.

    Expanding a bit, this is a function for senior engineers to really help with, since you can spot (sometimes by just trudging through a thought experiment and using your own experience as a guide) if a given solution is getting off-track.

    1. 3

      I think you completely missed the point of the original post:

      I’m curious if anyone knows of any small/medium-size open source projects written in F# that they think are “really great” from a design and project layout perspective. Bonus points if they use “Railway Oriented Programming” (as Scott calls it). The stuff I’ve written certainly works, but I wouldn’t be surprised at all to find out that my design is not optimal for how it should be in F#, and I’d love to review some good examples of how an F# program should be laid out.

      He’s looking for codebases to study for insight. You response is that because codebases do things, and he might want to do different things, he’s learning in the wrong way. As if he can’t contextualize his learning!

      To use your chess analogy, he asked “what are some good games to study”, and your response was “your games will evolve differently than past games, so don’t study the old games and just focus on playing chess well.”

      “The problem forces the tools” is good and all, but once you’ve figured out the right tools, you still need to know how to use them!

      1. 1

        This is why it’s a difficult discussion. Immediately after you contextualize the problem, say “playing chess”, you already know half the answer.

        But coding problems aren’t/shouldn’t be contextualized until the last possible moment. That’s kinda the point.

        The context is “incrementally growing complexity”, and it exists across all domains. Existing projects are the result of other people, presumably, already doing this for one certain domain (or group of domains). You’re buying into that contextualization once you start using their templates.

        We’re not plying chess, we’re inventing chess. My bad for trying to provide something concrete by way of explanation. By being too concrete, now you’ve already jumped ahead with your reply. You missed it. That’s my fault. Hence the rant. I used chess as an analogy to problem-discovery and solving, not as a specific problem to be solved. My metaphor failed. The puzzle metaphor was probably the better one.

        A friend says, “nobody needs to reinvent another doubly-linked list” Inside certain contexts, we don’t need to re-do things. We don’t have to reinvent computers, but we have to be able to separate the parts of programming that are fixed and the parts that vary over the years. Cross-checking does that.

        Nobody’s saying to re-grow a web server from scratch.

        Let’s say I picked a good project structure and the questioner went and “learned” from it, I’ll never expect them to ever be able to code in a simpler way than that. That’s because I’m already structuring things up before they even started. I can expect they’ll continue to operate in the same way.

        Take apart complex projects, have at it. There are really cool things to learn, sure. It’s just not cross-checking. At some point, perhaps after a dozen or two of these kinds of things, you’ll finally sit down and start doing some cross-checking. Where’s the minimal-coded solution and how does that relate to where I usually end up? At that point, you’ll actually be contextualizing the process of solving problems by programming.

        Put differently, if you don’t know the minimal amount of complexity required to solve the problem in front of you, how can you have any idea whether any project template is a good one for you or not? Popular opinion?

        1. 1

          Let’s say I picked a good project structure and the questioner went and “learned” from it, I’ll never expect them to ever be able to code in a simpler way than that. That’s because I’m already structuring things up before they even started. I can expect they’ll continue to operate in the same way.

          So give them two different projects, and have them compare and contrast the different structures and why the choices are made like they are. You’re assuming learning is just rote memorization.

          We’re not plying chess, we’re inventing chess. My bad for trying to provide something concrete by way of explanation. By being too concrete, now you’ve already jumped ahead with your reply. You missed it. That’s my fault. Hence the rant. I used chess as an analogy to problem-discovery and solving, not as a specific problem to be solved. My metaphor failed. The puzzle metaphor was probably the better one.

          “Inventing chess” doesn’t work either. I have a few friends who are boardgame designers, and a big part of getting good at game design is dissecting existing games to understand how their mechanics do (or don’t!) contribute to the goals of the game. In both of examples of “chess”, the way the actual experts learn is by doing the thing you say not to do!

          1. 1

            You’re assuming learning is just rote memorization.

            Nope. I’m assuming that in most cases your assumptions are not properly understood.

            I agree. Chess was a bad metaphor. Again, my bad.

            Having said that, board games come with their own assumptions: there will be a physical board, there will be a small/finite number of players, the rules are not too complex to be understood, the game is easy to play, difficult to master, and so on. Those are a few of the hidden assumptions of that domain. I’m sure there are many more.

            Cross-check.

            1. 1

              Nope. I’m assuming that in most cases your assumptions are not properly understood.

              I think it’s considerably more likely you did a poor job of explaining yourself. Based on the timelines given in the post, you wrote this start-to-finish in under two hours. It reads like you published your first draft without taking time to revise it.

              1. 1

                I meant “your assumptions are not properly understood” with “you” being our example programmer, not you the internet commenter.

                Thanks for the chat. I appreciate the feedback.

      2. 2

        This reads like Daniel is trying to say something more than just, use the right tools and validate your assumptions. I honestly can’t tell what more than that he’s actually trying to say, though. This is probably because it’s more of a rant than a complete discussion of the subject. I wouldn’t mind knowing more though.

        1. 1

          Thanks. It needs work, hence the rant.

          It occurs to me that there are similar yet different points here:

          1. Keep things simple
          2. Use the right tools
          3. Have some way of judging whether you’re doing 1 and 2 correctly

          Cross-checking, the topic of my essay was #3

          I’ll keep trying. I appreciate the help.