1. 4
  1.  

  2. 3

    I think this is an awesome idea.

    Instead of random potential users, we would need to use other programmers who may need to read the code later.

    Good reminder that “readable” or “understandable” code is subjective, and the opinions that matter are precisely those who will need to read and understand it.

    1. 2

      Interesting concept that I will end up thinking about for a while. However, actually running user studies isn’t the hard part. It’s designing the experiments, and interpreting the results, in a way that will give you useful information. It may turn out that it’s too difficult to design a study that will allow you to extrapolate beyond the code and programmers tested in a meaningful way.

      But you don’t know if you don’t try. Maybe research like this will lead to a usable model of what legible code really is, or new programming paradigms, or the elimination of a whole class of bugs, or anything!

      1. 1

        Another attempt to get away with not commenting code and waste people’s time.

        So, now I have to go through your code and document it for you? Spend 2 extra minutes and write down something comprehensible, I don’t need to care unless you are out of office and we need to fix your stuff.

        1. 1

          That’s not the point. Even if you think you’ve documented your code, the docs you wrote may not actually be useful. This is a test to ensure that they are.

        2. 1

          I really like the theory of the idea. I feel confident (perhaps overconfident) about the results of comparing the solutions to the same problem solved on the one hand with Angular, and the other hand with Vue.

          That said, it sounds like significant effort and time commitment to get even a subset of a real-world team of engineers to agree to do this. I also think that a lot of the benefits from this could be had from code reviews.

          1. 1

            Code reviews are akin to showing the UI to a potential user and asking them if it feels intuitive. They’re absolutely essential for every change to the codebase. But what I propose here will ferret out issues that a code review misses. It’s absolutely the case that it’s a lot more effort and I said as much myself. But so are hackathons and UX tests. The idea is not to do this for every change but to do it occasionally as a fun activity. The correct frequency is likely to be along the lines of every time a new person joins the team.

            1. 2

              Doing it as part of onboarding protocol sounds like one of the best times to do it.