It's been a minute since my last post and also since the last time I wrote Ruby for a living. After a five-month-or-so React Native binge, I'm back on the Rails, and wow, I literally typed const yesterday when defining a variable. By which I mean it's going great, how are you?
So understandably, I was really excited when a coworker of mine at Home Chef started a casual book club-style reading of 99 Bottles of OOP by Sandi Metz and Katrina Owen. Not that I've been far from OOP in Reactville, but the book goes through a lot of useful principles of refactoring, naming, increasing flexibility, and other things I didn't have much time to ponder when I was busy churning out mobile apps on rush deadlines —in Ruby!
We recently finished the starting exercise as well as the first chapter, and here are some first impressions / takeaways / quotes I really liked.
Writing code is like writing a book; your efforts are for other readers.
I could not agree more! Partly, I think this is why my editing background keeps coming to bear in my coding life. Questions of audience and readability are still incredibly relevant, and I will continue to shout them from the rooftops.
DRY promises that if you put a chunk of code into a method and then invoke that method instead of duplicating the code, you will save money later if the behavior of that chunk changes. Recognize, though, that DRYing out code is not free. It adds a level of indirection, and layers of indirection make the details of what's happening harder to understand.
Recognizing that the SOLID principles and other tenets of programming are the result of cost-benefit analysis is super valuable. Too many "rules" out there are blindly followed without understanding the critical thinking behind them, and sometimes mis-applying those rules can result in code that is more convoluted than when you started. I'm certainly not advocating that DRY code isn't better than "wet" code, but stopping to ask yourself why that's true is a good use of your brain.
Again, we're always thinking about who is going to come along and read our code after we've moved on to some other problem.
As programmers grow, they … become comfortable with complexity. This higher level of comfort sometimes leads to the belief that complexity is inevitable … [but] infinitely experienced programmers do not write infinitely complex code; they write code that’s blindingly simple.
I love this. I love it so much. One of the things writers and editors learn as they grow, too, is how often cleverness can obscure meaning. It can manifest as "this word, I do not think it means what you think it means" syndrome, or as long and convoluted sentence structure that's hard to follow. (I used to think of this as "where is the subject and where is the verb?" syndrome.) Code can come in these same flavors, and us juniors sometimes start to think of complex code as being written by someone "better" than us — when really it's the simple code that's hardest to write.
Hopefully this summary of Chapter One was interesting, and you're inspired to pick up a copy of 99 Bottles of OOP for yourselves. I'm really looking forward to diving into the practical chapters on refactoring and arriving at that "blinding" simplicity myself. I might even let you know what I find out. Happy reading!