Day 10: Analogies

This morning started off with a difficult and fun kata called the Elevator Problem (thank you to Kay for suggesting it!). The task is to transport 20 people in 60 seconds, going to the floor to pick them up and dropping them off on their desired floor. The problem and simulator can be found here.

We passed the level where the building was 3 stories high, but could not figure out an algorithm quick enough for a building with 4 stories. To be continued… hopefully.

The rest of my day was spent with Haskell, which somehow feels like more of the same. I’m chugging along this part (previously with the topic of Type Classes, and now just starting with functions!!!!!) with the golden promise of Haskellland (yes, 3 ‘l’s) in horizon 😃.

I also started to read some of the Mythical Man-Month, recommended by Wolfram. The first two chapters were a bit tough to read but shared some interesting analogies. One of which compares estimating completion of programming projects to estimating when an omelette will be done. Omelettes require a lot of patience. If the customer wants the omelette in 2 minutes, they have two choices: 1) eat a raw omelette after 2 minutes or 2) wait longer for the omelette to do its thang. The cook similarly has two choices: 1) turn up the heat with the risk of an unsalvageable omelette that is burnt on the outside and runny on the inside or 2) wait for the omelette to do its thang. I thought this was a fun analogy.

There is also another part about the conceptual integrity of churches. The execution of building a church dures hundreds of years. Most of the time, the original plans are mostly adhered to and the architect’s ideas are able to come to life through the hands of hundreds, maybe thousands of builders. Other churches, however, are made up of different parts, with each part representing a different design. I had heard about this analogy to programs in one of my university courses, and it is something that really stuck with me. It is such a good mindset to at least aim to make the concepts of your programs, applications, or systems portray a consistent (and timeless) set of design practices. I think the “quick-fix” mentality creates a mish-mosh product that is hard to pass on to any successor.

That’s all for today 😊