Simplicity Matters by Rich Hickey (optional)

[rrgayhart]

Simplicity Matters by Rich Hickey

As we move into working on larger and more sophisticated systems, some of the approaches that have worked on smaller projects may no longer be so effective.

What does Rich Hickey say about the common pitfalls of Ruby and Rails applications?

[s-espinosa]

• Overall Impression - Enjoyed this talk and made me think of times that I was able to be faster than my colleagues in my previous job. Most often it wasn't because I was better on the keyboard, smarter, or more insightful, but because I had taken the time early on to organize the work I was doing even if I wasn't sure that I would have to redo it/adjust it in the future. Taking that time meant that when I returned to a problem I was able to quickly get up to speed on how I had done something and make the necessary adjustments. I'm still working to be able to do the same thing in my code.
• Around the 20 minute mark Hickey started to lose me a little bit, which frustrates me because it seems like this was where he was really getting to the heart of his argument in concrete terms.
• 22:30 - Think this oversimplifies the agile statement a little bit. I would argue that he’s advocating for less work in the future through careful and thoughtful decision making in the present. Minimize the amount of work, but take the long view when you’re thinking about what less work means. Working harder today (taking the time to learn my tools, organize my thoughts and code, etc.) will enable me to be more productive tomorrow without constantly fighting with my tools/the code I’ve already written. See also: a stitch in time, marshmallows.
• 25:00 - Love this example because it demonstrates how decisions at even the most basic level can result in unforeseen complexity.
• 27:30 - Call chains: I’m guilty of this. Just did this last week. Wondering how this works in a functional paradigm.
• 29:30 - Hashes: It’s interesting to think through this a little bit. My default position is to use an array, but I think that’s more to do with my sense that their more often the appropriate data structure. I’m not sure I can fully parse Hickey’s argument here, and I wonder what he would do with users pulled from a database. If I’m putting together a show page with little concern for the order of the users being shown, would Hickey recommend putting those users into a hash and then iterating through it? Going through the trouble of putting users into a hash and creating a key for them (likely a user_id) is more cumbersome than putting them into an array, but also slightly more complex. Is this because I’m simply more comfortable with arrays than hashes? Possibly. An array in this case (unlike the width depth height example he gives) is a fairly agnostic choice, but maybe not. I’m trying to think of a case where future-me would wish that I had used a hash instead of an array to temporarily store Users after pulling them from a DB, and I can’t think of one.

[Jbern16]

I really love Rich Hickey's motivation to make simple easy. From talking to alumni and reading about how large companies websites work, it seems extremely convoluted. Multiple messages being passed all around to different frameworks. It doesn't seem like a linear solution or one one could easily understand whats happening. The many pitfalls of Rails app usually end up with plugged solutions, more gems, other databases, complicated frontend, etc. And many times, we don't know how those "solutions" are actually working or how they can screw us up.