Coding Blocks Podcast

We continue digging into Rob Conery's The Imposter's Handbook as Joe explains Florida time, Allen likes greedy algorithms, and Michael shares his geography knowledge.

Direct download: coding-blocks-episode-85.mp3
Category:Software Development -- posted at: 11:40pm EDT

It's time we discuss algorithms we all need to know as we continue diving into Rob Conery's The Imposter's Handbook while Michael will read anything, Allen questions Greenland's name, and Joe talks wormholes.

Direct download: coding-blocks-episode-84.mp3
Category:Software Development -- posted at: 11:34pm EDT

We're talking databases, indexes, search engines, and why they're basically microwaves in this episode while Joe wears a polo, Allen's quick brown fox jumps over whatever, and Michael gives out fake URLs.

Direct download: coding-blocks-episode-83.mp3
Category:Software Development -- posted at: 9:20pm EDT

Inspired by Rob Conery's The Imposter's Handbook, we take an introspective look at ourselves to find two weaknesses and one strength while Allen shows off his vocal prowess in song, Joe needs a list, and Michael is a dash.

Direct download: coding-blocks-episode-82.mp3
Category:Software Development -- posted at: 1:49pm EDT

This episode we talk complexity theory while digging into Rob Conery's The Imposter's Handbook as Allen channels his inner Austin Powers, Michael finds linearly to complex to pronounce, and Joe ruins Batman for the rest of us.

Direct download: coding-blocks-episode-81.mp3
Category:Software Development -- posted at: 10:09pm EDT

This episode we're talking about server naming conventions, confusing command line arguments, and how high we can get our voices. Huge thanks to the NSA and the freedom of information act for making this episode possible.

Direct download: codingblocks-episode-080.mp3
Category:Software Development -- posted at: 10:07pm EDT


Get the Book Practical Test-Driven Development Using C# 7 on Amazon


God Object

  • Concentrating too many functions in a single part of the design (class)
  • Typically knows everything about what’s happening in the application and knows how to interact with all the data in the application
  • Often gets incredibly difficult to maintain over time because making changes to the God object has far-reaching side-effects
  • Overly complicated because it knows about and maintains the state for much of the application - becomes a mediator of all things in the app
  • Pattern is used in micro-controllers where centralized control is more important than elegance and ease of maintainability

Object Cesspool

  • Reusing objects whose state does not conform to the (possibly implicit) contract for re-use
  • This happens when you’re re-using objects (for example Pooling/Flyweight) and you either don’t fully clean up before/after
  • Example: I get a db connection from the pool, set the command timeout really high, use it, then return it…if my code doesn’t reset that…then every other call that uses that object may have that new timeout
  • Example: You install a blog engine like WordPress, create a new post and save it…then you go to write your second post and some of the information is not reset between uses…so you may end up setting a category, tag etc that you didn’t realize
  • Can also get into this problem if you’re working in a multi-thread environment and aren’t being thread-safe
  • How do you know when you’re doing this? Are you re-using objects or creating them on the fly? Do your objects have a “reset” method?
  • What to do about it? Try to centralize “reset” type code, use thread-safe tools/practices

Object Orgy

  • Failing to properly encapsulate objects permitting unrestricted access to their internals
  • Meaning, that other objects are able to “reach” into parts of your object that they really shouldn’t be able to
  • The worst consequence is that it becomes difficult to maintain and change.
  • An example of how this happens would be by declaring internal members public or providing public getter/setter methods on your properties.
  • This anti-pattern could be a symptom of coding to an immature design, laziness or haste while implementing the design, and/or reluctance to refactor the design as it matures.
  • How to fix this? Recognize the problem and refactor. This will be especially easier before any interfaces are made public.
  • favor private over public
  • OCP maybe?
  • The example we talked about with the RGB color space is directly to Joe’s own creation:

Please leave us a review!


  • Objects whose sole purpose is to pass information to another object
  • Also known as: Gypsy , Proliferation of Classes , and Big Do It Controller Class
  • Typical cause is poor object design
  • Often found by names like manager, controller, startProcess, initialize…
  • They are short lived objects that have no apparent reason to exist other than to initialize a class or invoke a method in a more useful object
  • To remove one - get rid of it and move its functionality into the invoked class, through either inheritance or as a mixin
    A mixin can be viewed as an interface with implemented methods

Sequential Coupling

  • A class that requires its methods to be called in a particular order
  • Imagine an SDK like a credit card processor where you have to…Initialize your sdk, Create an Order, Add Items To the Order, Submit the Order for Authorization, Submit a Capture
  • How do you know when you’re doing this? If you catch you’re self saying “Oh, it’s because you didn’t…”, if you have an “Initialize” method, if you feel obligated to look for an example of how to do something
  • How do you fix it? Consider the template method pattern, create one method that does that stuff and have hooks like “initialize” and “before” / “after” events that implimenters can fill in - but not be responsible for calling

Yo-Yo Problem

  • A structure (e.g., of inheritance) that is hard to understand due to excessive fragmentation
  • Ever read some code, program, etc. that was so complicated you had to bounce between files, classes, etc. to understand it? That’s the yo-yo problem.
  • How can we avoid this?
    ** Maybe the S from SOLID to (help) keep your objects smaller?
    ** Favor composition over inheritance to keep the inheritance tree as shallow as possible.

Resources We Like

Tip of the Week

Direct download: codingblocks-episode-079-64.mp3
Category:Software Development -- posted at: 8:00pm EDT

It's time for more cowbell as we have a special guest in the studio, Will Madison (@IAmWillMadison), join us as Allen finally gets tripped up trying to pronounce a name, Joe teaches us the value of practice, and Michael evacuates in a rainbow colored straight line.

Direct download: coding-blocks-episode-78.mp3
Category:Software Development -- posted at: 10:49pm EDT

We're back with our last deep dive into Robert C. Martin's latest book, Clean Architecture, while Allen suffers from sleep deprivation, Joe shows us his dance moves, and Michael's mind is blown on how to unit test.

Direct download: coding-blocks-episode-77.mp3
Category:Software Development -- posted at: 10:15pm EDT

It's time for another deep dive into Robert C. Martin's Clean Architecture as Joe puts us on the spot, Allen has a new mission, and Michael shares his Easter eggs.

Direct download: coding-blocks-episode-76.mp3
Category:Software Development -- posted at: 10:32pm EDT