On the way to Manhattan I reviewed the code of a Scheme to Lua compiler by Adam. I wanted to do a code review although I am no expert in the theory of compilers, nor do I know Haskell well. But that was the challenge! One of my goals is to get better at these kinds of challenges: Go to an unknown terrain and try to find out what is going on. Then try to find a way to improve it, because that’s what the reviewee is looking for. Without doing bikeshedding. There it is again, see my thoughts on reviews on Monday. I feel I’m thinking a lot about bikeshedding lately. Maybe because I’m reviewing a lot. That would be a good sign.

So I think Adams code was very nice and clear. It turned out that some parts that I marked as “what is this doing here?”, were removed by the time I arrived at RC. I think good, readable code depends a lot on good structuring and good variable naming. I think Adam’s code has these properties. So, as I don’t know any details about Haskell, I concentrated on the names an the structure. I was reading the code for one hour or so and it was a fun, interesting read and I started to see what was going on.

Next on the schedule was pairing with Elias. He had asked me before if we could find something to pair on, and yes we did. This was the first lesson: Just ask for pairing, even if you don’t know what it could be. We worked on Zulip development and digged into some weird bug regarding Emoji pasting. It turned out that handling these is not a simple thing – because the Unicode standard is not really standardised at some points. It was fun to pair with Elias, because he had a very clear idea what he wanted to work on. And I knew some of the Zulip codebase and environment, so could give some recommendations. Apart from that it was nice to see his working environment and approach.

I continued on working on one of the Zulip bugs. It turned out that the area where this bug was happening is quite complicated. The maintainer wrote some documentation to explain this to me. That was impressive to see. I’m not a fast writer, but I can see the benefits of beeing one. Focusing the fast writing to a special form (documentation), can then lead to a very well documented piece of software. The workflow works in the following way: If you have to explain your system to somebody, don’t do that in an email or some other form of (semi-)private communication, but directly write it to be published. It’s ok to be raw or unfurbished, because cleaning it up is way easier when there is something.

The evening was spent on the CTM reading group. We were a small group of three. The motivation of this group is diminishing, as in the beginning we were eight participants. I was also hesitating whether to participate the meeting, but I’m glad I was there, to see that I’m not the only one who’s a bit frustrated. We decided to start some strategic discussion, to see where people would like to go from here.