Lightning Talk: Coding for the Future - A perspective

by Chris Hagmann

In this engaging lightning talk titled 'Coding for the Future - A Perspective,' Chris Hagmann shares valuable insights on coding best practices, emphasizing the importance of ethical considerations in programming. The discussion is framed around the idea of 'Jurassic Park Engineering,' a concept derived from a conversation about the potential pitfalls of coding innovations that may seem enticing but could lead to long-term issues.

The key points covered in the talk include:

- Jurassic Park Engineering: Hagmann highlights the dangers of creating code simply because it's possible, stressing that developers should think critically about whether they should implement it, referencing a personal experience with dynamically created Ruby code that could complicate maintenance in the future.

- Metaprogramming Caution: While metaprogramming in Ruby can be powerful, Hagmann warns against overusing abstraction, advocating for a balanced approach that prioritizes maintainability and clarity.

- Dependency Awareness: A pivotal moment in Hagmann's career involved being impressed by a Ruby gem, 'Perspectives,' which was later found to be unsupported. He reflects on the subsequent challenges of updating the unsupported gem, urging developers to carefully consider the dependencies they introduce into their applications.

- Maintainability of Code: Using the example of a rock-paper-scissors game logic, Hagmann critiques clever but convoluted coding practices, which may lead to difficulties in modifications and maintenance for future developers. He emphasizes the significance of straightforward and comprehensible code.

- Importance of Code Reviews: The speaker discusses the role that code reviews play in maintaining quality code, encouraging developers to voice concerns during reviews to prevent complex and hard-to-manage code from entering the codebase.

In conclusion, Hagmann's talk serves as a cautionary tale for developers, reminding them to prioritize maintainability, think critically about their coding choices, and engage in productive discussions during the code review process. The mantra, 'just because you can, doesn’t mean you should,' encapsulates the essence of this insightful presentation at Blue Ridge Ruby 2024.

00:00:11.960 Hello everyone, my name is Christopher Hagmann. I work at a company called Power Auctions. I literally created these slides over lunch, so this is the first run of this presentation. It should be fun!

00:00:22.960 This talk was inspired by a conversation I had recently, in which I shared a story about one of my bosses. He used the term 'Jurassic Park Engineering' based on the famous quote: 'Your scientists were so preoccupied with whether or not they could, that they didn't stop to think if they should.'

00:00:30.519 He mentioned this in reference to some code I tried to commit, with the caveat that if we merged it in, we would never be able to get rid of it. This was after I had just learned that you could dynamically create code in Ruby, which was really exciting. Of course, I took that idea to its logical extreme; I created an ERB template where I could pass in variables and dynamically generate a Ruby source file that I could then load exactly as intended.

00:01:04.400 It's important to consider that, while things may seem cool and clever, it's hardly appropriate to start making sweeping generalizations. I didn't want to fix everything, so let me stress: just because you can do something, it doesn't mean you should. There are numerous examples of things that slip into our codebases that we could do, but shouldn't have. Please do not take metaprogramming to that extreme and be mindful of your metaprogramming practices and levels of abstraction.

00:01:36.840 Another topic I'd like to address is dependencies. There was a significant moment in my life in 2014 when I had not yet picked up any programming. A presenter gave a talk about using objects for Rails views. He named his proof of concept 'Perspectives,' and one of my future employers attended that talk and was very impressed, immediately implementing it into one of our production applications.

00:02:10.479 As you might guess, it was a pivotal moment at Rails 2014—the event where the person who wrote the gem presented it. Unfortunately, he didn’t update it again. I can almost guarantee that our company is the only one that ever used it in a production application, including him. In 2021, I had the opportunity to update a fork of that gem to Ruby 6, as our client did not want to pay for us to remove it from the many applications where it had been integrated. After careful consideration, I decided not to endorse the gem anymore. This is a reminder to be cautious about what you endorse and include in your applications, especially when it becomes a critical part of your infrastructure.

00:03:30.480 We must consider that someone who may not even be aware of Rails could be tasked with fixing or maintaining your code in the future. While the gem itself is interesting and not inherently bad, it's unsupported and not fully fleshed out. This brings me to an example from a refactoring workshop I attended. Can anyone guess what game we were trying to help score? Yes, it's rock-paper-scissors! In this case, we check the index to determine the winner, which simplifies the logic and reduces the need for comments. However, I would argue that this code is actually not good, even though it may score high on code contests.

00:04:35.120 If someone decides to add a new option to the game, they would have to figure out how it works at the fundamental level. Therefore, sometimes trying to be clever in code can make it less maintainable for future developers. Even your future self may end up resenting that decision.

00:05:06.240 One of the major ways complicated code enters our codebases is during code review. We should be careful not to bypass important discussions about the code. Sometimes, the best thing to do when spotting red flags is to speak up early and often.

00:05:20.199 Thank you for your time, and hold on to your butts! Let's keep our code clean and maintainable.