Today’s episode of Evil Geniuses is spent looking back on the lessons we have learned so far in this series. Through all of the evil problems and scary paths we’ve had to walk, there have been some invaluable takeaways that we have been able to share with our listeners.

9. Lessons Learned

Every two weeks we break down solutions to code problems, talking about the decisions that got us where we are. We reveal our thinking and discuss trade-offs. Evil devs. Evil problems. Evil code.

Technology

Tech News

Podcasting

Gadgets

Software How-To

This short episode of the podcast serves as a farewell to the one and only Meredith Edwards. Meredith has unfortunately recently acquired some angel wings and can no longer be an evil genius alongside Emmanuel! So today we are just wrapping up what the journey thus far has taught our two hosts and bidding Meredith a very fond farewell. We briefly look back at some of the key lessons we have covered so far as well as reminisce on the benefits of hosting the show. Tune in hear it all!   Talking Points  What a wild ride it’s been! How I’ve enjoyed working with Emmanuel What I’ve learned from the podcast. Goodbye from Meredith!      Links Mentioned in Today’s Episode: Evil Geniuses on Twitter Ruby Sandi Metz

16. Meredith Farewell

Welcome back to another episode of Evil Geniuses. Today on the show we welcome back Kirsten Nordine. The last time Kirsten was on the show was a little over a month ago and we talked a little bit about an open source contribution we’re working on but we also talked a lot about her experience going to a POOD Workshop by Sandi Metz in Durham, North Carolina. In today’s episode, we are talking all about Kirsten and the little vacation she took. Well, not necessarily a vacation but time away from clients to learn more about software development. Kirsten and Emanuel attended Sandi Metz’s new three-day workshop titled POODR Two: Practical Object-Oriented Design in Ruby. We dive into why they went, what they learned, and the biggest takeaways from the workshop that each of them had. Keep listening to hear more!   Key Points From This Episode:  Wanting steps like rules to architect a solution to something. Learning more about how objects work together and the design. Day 1 working on a bowling exercise — website code kata and sequence diagrams. Day 2 focusing away from the code and more towards drawing and talking. Designs centered around what message the objects sent and received. Sandi’s helpful way of simplifying things. Why code is easy and organizing code is hard. The role of TDD and design. Finding our where the first test should be. Designing a new story, finding a way to communicate and start writing code. And much more!    Talking Points  Why did you go? What did you do? What is special about learning from Sandi? What are we going to do after? How are we going to practice until we’ve fully learned the  things introduced at the class? What is the main takeaway? What are some things you would change about the class?    Links Mentioned in Today’s Episode: Evil Geniuses on Twitter Kirsten Nordine Kristin on Twitter Sandi Metz Stride Ruby

15. POO-ing in Durham, With Kirsten Nordine - Part 2

Welcome back to another episode of the Evil Geniuses Podcast. We are coming at you with something new this week! This episode will be the first time that we are not talking about a code problem that we’ve solved because we are going to take a stand, and our stand is about testing. We are diving into the ins and outs of how you describe your test. Here at Evil Geniuses, we believe that the description of a test should describe business value not implementation. So stay tuned as we unpack the differences between business value and implementation descriptions, the opportunities that can come from rewriting code, and why naming your tests can take quite some time to fully master. For all this and more, keep listening!   Key Points From This Episode:  Specific examples describe business value versus implementation. How the description sets you up to know what to look for when reading the test. Why a misdescription can make it hard to see if the test was successful. Understanding exactly who the test naming is for. Rewriting code allows you to know enough to better write business value descriptions. Why naming your tests takes a long time to master. And much more!    Talking Points Tests should describe the business value and not the implementation  Different types    Test that describes implementation:        describing that a method or attribute returns a certain value    “it should equal 20” “it should call YouTube API” “it should call the render_text method”     Test that describes business value     describing the reason to return a certain value     “it should have the amount given by the user” “it should return video stats” “it should render text”    Who are the tests for?    Other developers reading the code Future you if you’re refactoring    Following this practice results in better tests    Bad: “it should raise a PriceError” Good: “it should return an error when value exceeds max price” Not only about raising the error; it’s about notifying the developer and user that something exceeded the max price    Supports Refactoring    clarifies the objective this makes it easy to change implementation because you aren’t confused about why a certain piece of code was written Ex: feel confident to refactor as long an error is raised when the max price is exceeded    Supports Feature Changes    Feel more confident changing or removing test related to max price with description instead of just “exceeds 100”     Links Mentioned in Today’s Episode: Evil Geniuses on Twitter The Stand Stride

14. How to Describe Tests

On this episode of the Evil Geniuses Podcast, we continue our series on a first example of the video checkout system. To start off we recap some of the points from the first two parts and then move into the final stretch! We talk about the two main patterns that are present in this code, namely base charge for rental and extra charge for rental before getting into renaming decoupling and calculating a final cost. We add in some reminders about primitive obsession and take some handy lessons from the idea of a library and borrowing books, so stay tuned for that! For all this, and much more be sure to listen in as we go deep!   Key Points From This Episode:  Recapping the patterns from the first two parts of this series. Base charge for rental and extra charge for rental as the two patterns. Renaming a commit and why it is more accurate now. The meaning of the number two in this context. Making it obvious that new movies have a base rental period. Looking to the library for an analogy on extra charges and new movies. Finally calculating the whole charge for the rental. Figuring out the title of the movie by removing a coupling. Writing exemplary code for others to follow. An HTML challenge to the listeners! And much more!    Commits   rename element to rental   Make the code tell a story    rename base_cost_of_rental to base_charge_for_rental   Making the code tell a consistent story    extract #points_for_rental. remove comments, no longer necessary   Repeat the pattern of the previous extractions    extract base_rental_period from extra_charge_for_rental   A new pattern spotted    new releases do not have the concept of base rental period   Trying to figure out what base_rental_period for new release movies is    or maybe new releases have infinty base_rental_period   I think we’ve  got it!   base_charge_for_rental can include extra_charge_for_rental   Consolidating ideas    rename base_charge_for_rental to chare_for_rental   Consolidated idea    extract base_charge_for_rental. It's also become obviou   Doing the obvious move    move base_charge to rental   More obvious   move extra_charge to Rental   More obvious moves    add Rental#charge method. Only public method necessary   Pretty obvious    move points to Rental   More obvious moves    some general cleanup   Cleaning    add Rental#title. This finally makes it so that Customer   Avoiding the train-wreck   some light cleaning   Some light dusting      Links Mentioned in Today’s Episode: Evil Geniuses on Twitter Stride GangofFour Ruby JavaScript Sandi Metz Primitive Obsession Refactoring  

13. A First Example - Part 3

Welcome to another episode of Evil Geniuses. Last time we teased you but we’re back and this time we’re actually going to deliver the goods, no more click bait. We are working with a video checkout store type software where our classes are a movie, a rental, and a customer. We’ve given you insight into what our test look like and today we want to talk about the code that does tester testing. The theme of this discussion is you have to do two things. One, you have to introduce duplication in order to identify the right obstruction because you can’t always trust the obstruction that is present and then two, stop being obsessed with primitives. No more primitives. Keep listening, there’s, even more, coming up in the next episode!   Key Points From This Episode:  The quality of your code and when it matters. Understanding a primitive obsession. Introducing temporary duplication to find sameness. Extra charge for rental versus base cost of rental. Returning the same type of object regardless of the output of your method. Eliminating the case statement. And much more!  Talking Points  Work hard to be lazy Duplication leads to the removal of duplication  Commits   rename element to rental   Make the code tell a story    extract base_cost_of_movie concept   Add duplication    remove duplicate base_cost_of_movie calls   Remove duplication    rename method to tell a more accurate story   Make the code tell a story part 2    extract the #extra_charge_for_rental method   This refactoring showed there are two kinds of charges for a movie Exposed an error    remove duplicate extra_charge_for_rental calls   Remove Duplication part 2      Links Mentioned in Today’s Episode: Evil Geniuses on Twitter Stride Ruby Sandi Metz Primitive Obsession Basic Instinct Sharon Stone

9. Lessons Learned

Download our free app to listen on your phone