Cover image of Coding Blocks

Rank #66 in Technology category

How To

Coding Blocks

Updated 5 days ago

Rank #66 in Technology category

How To
Read more

Become the best software developer you can be

Read more

Become the best software developer you can be

iTunes Ratings

676 Ratings
Average Ratings

Superb podcast for developers

By vasul007 - Dec 03 2019
Read more
This podcast is really good for software developers. It covers wide range of topics and explain really well. I definitely recommend to give it a try !!!

The best

By bobby_richard - Nov 25 2019
Read more
Hands down the best podcast for developers that want to improve at their craft

iTunes Ratings

676 Ratings
Average Ratings

Superb podcast for developers

By vasul007 - Dec 03 2019
Read more
This podcast is really good for software developers. It covers wide range of topics and explain really well. I definitely recommend to give it a try !!!

The best

By bobby_richard - Nov 25 2019
Read more
Hands down the best podcast for developers that want to improve at their craft

Listen to:

Cover image of Coding Blocks

Coding Blocks

Updated 5 days ago

Read more

Become the best software developer you can be

Algorithms, Puzzles and the Technical Interview

Podcast cover
Read more
On this episode we discuss algorithms, puzzles and how to approach them when asked to solve one in the interview process. We discuss many of the problems programmers face when being asked to solve these types of problems as well as steps to alleviate some of these common issues. We also provide a number of resources for sharpening your problem solving skills as well as a number of resources, and of course our favorite tips!

Apr 19 2015

1hr 26mins


How to be an Advanced Programmer

Podcast cover
Read more
Are you an Advanced Programmer? We dig into the final section of Robert Read’s fantastic writing: How to be a programmer. Also, how to cheat at Jira, a lazy butcher and if learning web development is worth it. Link to Episode 40’s Full Show Notes This Episode’s Survey To squash, or not to squash, […]

Mar 20 2016

2hr 23mins


Algorithms You Should Know

Podcast cover
Read more
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.

Jun 25 2018

2hr 15mins


Design Patterns Part 1 – You Create Me!

Podcast cover
Read more
This week we’re tackling the first section of seminal Design Patterns book: Creational Patterns. We discuss factories of factories, “bullet hell” games, pathological liars, and Allen’s lack of voice. Big thanks to @rajsotweet for calling us out and getting us motivated to record! Points of Interest .NET Framework 4.5.2 is out! ASP vNext Awesome stats […]

Jun 07 2014

1hr 37mins


The Pragmatic Programmer – Investing in Your Knowledge Portfolio

Podcast cover
Read more
We begin our journey into the wisdom of The Pragmatic Programmer, which as Joe puts it, it’s less about type-y type-y and more about think-y think-y, while Allen is not quite as pessimistic as Joe, and Michael can’t wait to say his smart words. If you’re reading these show notes via your podcast player, you […]

Apr 29 2019

2hr 36mins


Clean Code – Error Handling

Podcast cover
Read more
This week, we continue our Clean Code discussion as we dive into the joys and pains of error handing.

Dec 28 2016

1hr 25mins


Object Oriented Mistakes

Podcast cover
Read more
Allen brings the dad jokes, Michael unplugs, and Joe gets a second wind as we discuss the anti-patterns found in object oriented programming.

Sep 18 2017

1hr 55mins


Software Architecture – The Domain in Domain Driven Design

Podcast cover
Read more
We continue our Domain Driven Design conversation this week as Allen is indecisive, Michael decides for him, and Joe can't handle the night life.

May 29 2017

1hr 41mins


What programmer do you want to be?

Podcast cover
Read more
“Water Cooler” episode talking about sweet sugary C# kisses, JavaScript as a first language, T-shaped developers, how to get addicted to drugs and…Where in the World is Carmen Sandiego? Points of Interest Keep the keys! Go follow @trentapple and check his site out at! A year’s worth of tech podcasts! from @patrikdahlen NativeScript – Cross […]

Jun 22 2014

1hr 8mins


How to Jumpstart Your Next App

Podcast cover
Read more
We’re back with another exciting episode as Michael questions Hollywood, Allen dreams of his Hackintosh, and Joe is surrounded by Star Wars as we talk about how to jumpstart your next app with Michael Crump (@mbcrump) and Clint Rutkas (@clintrutkas). If you’re reading these show notes via your podcast player, you can find this episode’s full […]

May 11 2017

1hr 27mins


Source Control Etiquette

Podcast cover
Read more
This episode is all about source control etiquette. It’s a bit different from the last two podcasts we released and we’d love to hear how you liked it! Subscribe on iTunes or Stitcher and make sure to send us your feedback! Show Notes Duration ~56 Discussion on Source Control Etiquette 00:00 – 25:09 A tale […]

Oct 12 2013



Back to Basics – Encapsulation for Object Oriented Programming

Podcast cover
Read more
It's time to get back to basics. It's easy as a software developer to be working on the latest and greatest frameworks, using the best methodologies, trying out new things. Sometimes it's a good idea to get a refresher on the very basic fundamentals. In this episode we go over the access modifiers that are common in C# and Java as well as ways to emulate these types of behaviors in Javascript. And let's be honest - encapsulation is only effective if you're providing programmers that come after you with a roadmap of how things should work. For that reason we also discuss Command Query Separation and some other ideas and practices that are a part of good programming practices. Be sure to head over to and leave us a review on your favorite podcasting platform!

Feb 10 2015

1hr 7mins


How to be a Programmer: Personal and Team Skills

Podcast cover
Read more
Talking about the short book “How to be a Programmer”, which covers a huge spectrum of important topics for developers of all levels. The Puddle Poll! Thanks for the share pwright08! News Thanks for the reviews! JKCooper2, CSharpest, Joopkins, NickStuer How’d you get into programming? Join! Survey – Star Wars wins! Check out Allen […]

Jan 28 2016

2hr 26mins


Software Design Anti-patterns

Podcast cover
Read more
We've discussed design patterns too much. Now it's time for some discussion about anti-patterns as Joe has dark visions about robots, Allen has to take sensitivity training, and Michael picks Arial.

Aug 21 2017

2hr 4mins


How to be an Intermediate Programmer

Podcast cover
Read more
In Episode 38, we dug into the first section of the essay by Robert Read on what it takes to be a programmer.  In that episode there was a lot of great information on what to expect and what should be expected of you as a developer.  In this episode, we go into the second […]

Feb 27 2016

2hr 50mins


How to Learn Programming Skills

Podcast cover
Read more
We continue our dive into how to learn things while Michael's voice sounds an awful lot like Joe's, Joe says it's a square, and Allen says it's a triangle ... oh, and Google Feud is back!

Oct 08 2018

1hr 12mins


Deliberate Practice for Programmers

Podcast cover
Read more
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.

Apr 03 2018

2hr 16mins


Clean Architecture – Programming Paradigms

Podcast cover
Read more
Michael forgets what his favorite part of the show is, Joe makes us wait to learn what his favorite part is, and Allen pronounces it "pair-a-dig-'ems" as we continue our deep dive into Uncle Bob's latest book: Clean Architecture.

Oct 30 2017

2hr 8mins


Data Structures – Primitives

Podcast cover
Read more
We begin our journey into data structures by taking a deep dive into primitives while Allen makes Michael blush and Joe crashes his browser.

Nov 19 2018

2hr 42mins


Clean Architecture – Fight for Architecture

Podcast cover
Read more
Joe learns of our harebrained idea, Michael learns of Eisenhower’s matrix, and Allen explains polyfills as we begin our dive into Uncle Bob’s latest book, Clean Architecture. Prefer to read these show notes on something other than your podcast player? You can find the full show notes for this episode at Sponsors Linode – Use code […]

Oct 02 2017

1hr 37mins


Designing Data-Intensive Applications – Reliability

Podcast cover
Read more

We start our deep dive into Joe’s favorite new book, Designing Data-Intensive Applications as Joe can’t be stopped while running downhill, Michael might have a new spin on #fartgate, and Allen doesn’t quite have a dozen tips this episode.

If you’re reading this via your podcast player, you can always go to to read these show notes on a larger screen and participate in the conversation.


Survey Says

Anonymous VoteSign in with Wordpress
What is the single most important piece of your battlestation?
  • The keyboard of course. Johnny Five need input.
  • The mouse. My clicking game is on point.
  • The monitor. I see dead pixels.
  • Obviously not the peripherals. It's all about the tower o' power!
  • The chair. Or should I say the CEO chair.
  • It's all about the desk. Nothing else matters if it's sitting on a TV tray.


  • Thank you to those that took time out of their day to leave us a review:
    • Stitcher: Anonymous, jeoffman
  • How to get started with a SQL Server database using Docker:
    • SQL Server Tips – Run in Docker and an Amazing SSMS Tip (YouTube)
    • Sample SQL Server Database and Docker (YouTube)
  • Come see Allen at NDC { London } for your chance to kick him in the shins, where he will be giving his talk Big Data Analytics in Near-Real-Time with Apache Kafka Streams. (
  • John Deere – Customer Showcase: Perform Real-time ETL from IoT Devices into your Data Lake with Amazon Kinesis (YouTube)
  • There’s a new SSD sheriff in town and it’s the Seagate Firecuda 520 with a reported maximum 5,000 MB/s sequential reads and 4,400 MB/s sequential writes!!! (Amazon)
    • Seagate Firecuda 520 1TB NVMe PCIe Gen4 M.2 SSD Review (TweakTown)
  • Get 40% off your Pluralsight subscription! (Pluralsight)
  • Joe was a guest on The Waffling Taylors, episode 59. (

Designing Data-Intensive Applications

About this book

What is a data-intensive application per the book?

Any application whose primary challenge is:

  • The quantity of data.
  • The complexity of the data.
  • The speed at which the data is changing.

That’s in contrast to applications that are compute intensive.

Buzzwords that seem to be synonymous with data-intensive

  • NoSQL
  • Message queues
  • Caches
  • Search indexes
  • Batch / stream processing

This book is …

This book is NOT a tutorial on how to do data-intensive applications with a particular toolset or pure theory.

What the book IS:

  • A study of successful data systems.
  • A look into the tools / technologies that enable these data intensive systems to perform, scale, and be reliable in production environments
  • Examining their algorithms and the trade-offs they made.

Why read this book?

The goal is that by going through this, you will be able to understand what’s available and why you would use various methods, algorithms, and technologies.

While this book is geared towards software engineers/architects and their managers, it will especially appeal to those that:

  • Want to learn how to make systems scalable.
  • Need to learn how to make applications highly available.
  • Want to learn how to make systems easier to maintain.
  • Are just curious how these things work.

“[B]uilding for scale that you don’t need is wasted effort and may lock you into an inflexible design.”

Martin Kleppmann
  • While building for scale can be a form of premature optimization, it is important to choose the right tool for the job and knowing these tools and their strengths and weaknesses can help you make better informed decisions.

Most of the book covers what is known as “big data” but the author doesn’t like that term for good reason: “Big data” is too vague. Big data to one person is small data to someone else.

Instead, single node vs distributed systems are the types of language used in the book.

The book is also heavily biased towards FOSS (Free Open Source Software) because it’s possible to dig in and see what’s actually going on.

Are we living in the golden age of data?

  • There are an insane number of really good database systems.
  • The cloud has made things easy for a while, but tools like K8s, Docker, and Serverless are making things even easier.
  • Tons of machine learning services taking care of common use cases, and lowering the barrier to entry: NLP, STT, and Sentiment analysis for example.


  • Most applications today are data-intensive rather than compute-intensive.
    • CPU’s are usually not the bottleneck in modern day applications – size, complexity, and the dynamic nature of data are.
  • Most of these applications have similar needs:
    • Store data so the application can find it again later.
    • Cache expensive operations so they’ll be faster next time.
    • Allow user searches.
    • Sending messages to other processes – stream processing.
    • Process chunks of data at intervals – batch processing.
  • Designing data-intensive applications involve answering a lot of questions:
    • How do you ensure the data is correct and complete even when something goes wrong?
    • How do you provide good performance to clients even as parts of your system are struggling?
    • How do you scale to increase load?
    • How do you create a good API?

While reading this book, think about the systems that you use: How do they rate in terms of reliability, scalability, and maintainability?

What does it mean for your application to be reliable?

  • The application performs as expected.
  • The application can tolerate a user mistake or misuse.
  • The performance is good enough for the expected use case.
  • The system prevents any unauthorized access or abuse.

So in short – the application works correctly even when things go wrong.

When things go wrong, they’re called “faults”.

  • Systems that are designed to work even when there are faults are called fault-tolerant or resilient.

Faults are NOT the same as failures: a fault did something not to spec, a failure means a service is unavailable.

  • The goal is to reduce the possibility of a fault causing a failure.
  • It may be beneficial to introduce or ramp up the number of faults thrown at a system to make sure the system can handle them properly.
    • You’re basically continually testing your resiliency.
    • Netflix’s Chaos Monkey is an example.
  • The book prefers tolerating faults over preventing them (except in case of things like security), and is mostly aimed at building a system that is self healing or curable.

Hardware Faults

Typically, hardware failures are solved by adding redundancies:

  • Dual power supplies,
  • RAID configuration,
  • Hot swappable CPUs or other components.

As time has marched on, single machine resiliency has been deprioritized in favor of elasticity, i.e. the ability to scale up / down more machines. As a result, systems are now being built to be fault tolerant of machine loss.

Software Errors

Software errors usually happen by some weird event that was not planned for and can be more difficult to track down than hardware errors. Examples include:

  • Runaway processes can use up shared resources,
  • Services slow down,
  • Cascading failures that trigger a fault(s) in another component(s).

Human Errors

Humans can be the least reliable part of any system. So, how can we make systems reliable in spite of our best efforts to crash them?

  • Good UI’s, APIs, etc.
  • Create fully featured sandbox environments where people can explore safely.
  • Test thoroughly.
  • Allow for fast rollbacks in case of problems.
  • Amazing monitoring.
  • Good training / practices.

How important is reliability?

  • Obviously there are some situations where reliability is super important (e.g. nuclear power plant).
  • Other times we might choose to sacrifice reliability to reduce cost.
  • But most importantly, make sure that’s a conscious choice!

Resources We Like

  • Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems by Martin Kleppmann (Amazon)
  • Stefan Scherer has a Docker image for all your Windows needs (
  • Aspectacular with Vlad Hrybok – You down with AOP? (episode 9)
  • Grokking the System Design Interview (
    • Designing a URL Shortening service like TinyURL (
  • Looking for inspiration for your battlestation? Check out r/battlestations! (Reddit)
  • Chaos Monkey by Netflix (GitHub)
  • Pokemon Sword and Shield Are Crashing Roku Devices (GameRant)
  • #140 The Roman Mars Mazda Virus by Reply All (Gimlet Media)
  • Troubleshoot .NET apps with auto-correlated traces and logs (Datadog)
  • Your hard drives and noise:
    • Shouting at disks causes latency (Reddit, YouTube)
    • A Loud Sound Just Shut Down a Bank’s Data Center for 10 Hours (Vice)
    • Beware: Loud Noise Can Cause Data Loss on Hard Drives (Ontrack)
  • Backblaze Hard Drive Stats Q2 2019 (Backblaze)
  • Failure Trends in a Large Disk Drive Population (

Tip of the Week

  • When using NUnit and parameterized tests, you should prefer IEnumerable over something like IEnumerable because TestCastData includes methods like .Explicit() giving you more control over each test case parameter. (NUnit wiki on GitHub)
  • Not sure which DB engine meets your needs? Check out
  • Search your command history with CTRL+R in Cmder or Terminal (and possibly other shells). Continue pressing CTRL+R to “scroll” through the history that matches your current search.
  • Forgo the KVM. Use Mouse without Borders instead. (Microsoft)
    • Synergy – The Mac OS X version that Michael was referring to. Also works across Windows and Linux. (Synergy)
  • usql – A universal command-line interface for PostgreSQL, MySQL, Oracle, SQLite3, SQL Server, and others. (GitHub)

Nov 25 2019

2hr 2mins


Developer Shopping Spree 2019

Podcast cover
Read more

We discuss this year’s shopping spree only to learn that Michael spent too much, Allen spent too much, and Joe spent too much.

This episode’s show notes can be found at, where you can join in on the conversation, in case you’re reading this via your podcast player.


Survey Says

Anonymous VoteSign in with Wordpress
How often do you replace your computer?
  • Every few years. My guild needs me.
  • After every Apple announcement.
  • I upgrade it until I no longer can and can't stand the wait.
  • Never. And this 486 is still rocking Doom.
  • Every time my company gives me a new computer. When I change jobs.


  • A huge thank you to everyone that left us a review:
    • iTunes: Rwerikson181, harbinger2009, ar_dove, porkNubbins
    • Stitcher: SpartanFanDMD

Who Spent it Better? img {
float: right;
} img {
float: left;
} td:last-child {
text-align: right;

Michael’s Stormtrooper Build

Price Description
CORSAIR CRYSTAL 570X RGB Mid-Tower Case, 3 RGB Fans, Tempered Glass – White (CC-9011110-WW) (Amazon)

Honorable mention: Fractal Design Meshify C – Compact Mid Tower Computer Case – Airflow/Cooling – 2X
Fans Included – PSU Shroud – Modular Interior – Water-Cooling Ready – USB3.0 – Tempered Glass Side Panel
– White

CORSAIR RMX White Series, RM750x, 750 Watt, 80+ Gold Certified, Fully Modular Power Supply- White (Amazon)

CORSAIR Vengeance RGB Pro 64GB (4 x 16GB) 288-Pin DDR4 SDRAM DDR4 3200 (PC4 25600) Desktop Memory Model
CMW64GX4M4C3200C16W (Amazon)

CORSAIR H100i RGB PLATINUM SE AIO Liquid CPU Cooler,240mm,Dual LL120 RGB PWM Fans, Intel 115x/2066,AMD
AM4/TR4 (Amazon)

Intel – Core i9-9900K Octa-Core 3.6 GHz Desktop Processor (Amazon)

Arctic Silver 5 AS5-3.5G Thermal Paste (Amazon)

Samsung 970 EVO Plus Series – 2TB PCIe NVMe – M.2 Internal SSD (MZ-V7S2T0B/AM) (Amazon)

GIGABYTE Z390 AORUS Ultra (Intel LGA1151/Z390/ATX/3xM.2 Thermal Guard/Onboard AC Wi-Fi/RGB Fusion/Gaming
Motherboard) (Amazon)

Gigabyte AORUS GeForce RTX 2080 Ti Xtreme 11G Graphics Card, 3X Stacked Windforce Fans, 11GB 352-bit
GDDR6, Gv-N208TAORUS X -11GC Video Card (Amazon)

Allen’s Build?, err Purchase

Price Description
Gigabyte Aero 15 RTX 2070 / 32GB Ram / 1Tb SSD (Amazon)

Intel 660p 2Tb NVME SSD (Amazon)

XP-PEN Deco Pro Medium Graphics Tablet (Amazon)

Desk Undermount PC Holder (Amazon)

4k 60Hz Mini Display Port to HDMI Adapter (Amazon)

Universal Desktop TV / Monitor Stand (Amazon)

Portable Full HD 1080p Display USB-C, HDMI, Mini Display Port (Amazon)

Logitech c930e Webcam – Video Encoding Handled in Camera (Amazon)

USB3 Multi-Card Reader / Writer (Amazon)

Grizzy Conductonaut Liquid Metal Thermal Compound (Amazon)
*** Not for the faint of heart ***

Oculus Quest no PC Required VR (Amazon)

Joe’s Clampett Build

Price Description
Intel Core i9-9900K (Amazon)

MSI MPG Z390 Gaming Edge AC LGA1151 (Amazon)

EVGA GeForce RTX 2080 XC (Amazon)

Corsair Vengeance LPX 64GB DDR4 2666 (Amazon)

CORSAIR RMX Series, RM750x (Amazon)

Samsung SSD 970 EVO 2TB (Amazon)

Seagate BarraCuda 2TB (Amazon)

Be quiet! Dark Rock 4, BK021, 200W TDP, CPU Cooler (Amazon)

Resources We Like

Tip of the Week

  • Find a new color theme for every season. (
  • Filter only the requests with errors – Google chrome network (Stack Overflow)
  • So many reasons to join ACM.
  • Take control of Chrome discarding/reloading your currently open tabs with chrome://discards/.
  • Build Your Own X (GitHub)
  • Material Theme UI, the only IntelliJ theme you will ever need. (
  • Joe’s reasons to use Kotlin:
    • Reason #417 – apply
      • Consider these examples:
        • C# var p = new Person { firstName = "Joe", lastName = "Zack" };
        • Kotlin: val p = getPerson().apply { firstName = "Joe"; lastName = "Zack" }
      • Unlike C#’s object initializers that can only be called when new‘ing up an object, Kotlin’s apply method can be called at any time.

Nov 12 2019

2hr 32mins


DevOps: Job Title or Job Responsibility?

Podcast cover
Read more

We debate whether DevOps is a job title or a job responsibility as Michael finally understands‘s name, Allen is an infosec expert, and Joe wears his sunglasses at night.

If you aren’t already viewing this episode’s show notes in your browser, you can find these show notes at and join the conversation.


  • – Sign up today for a free 14 day trial and get a free Datadog t-shirt after creating your first dashboard.
  • WayScript – Sign up and build cloud hosted tools that seamlessly integrate and automate your tasks.
  • – Level up your coding skills, quickly and efficiently. Visit to get 20% off any course.

Survey Says …

Anonymous VoteSign in with Wordpress
Is DevOps a ...
  • A job title ... now hiring!
  • A job function ... get back to work!


  • We appreciate everyone that took a moment to leave us a review and say thanks:
    • iTunes: kevo_ker, Cheiss, MathewSomers
    • Stitcher: BlockedTicket

Is DevOps a Job Title or Company Culture?

  • What is DevOps?
  • What isn’t DevOps?
  • How do you learn DevOps?
  • How mature is your DevOps?
  • The myths of DevOps …

Resources We Like

  • What Is DevOps? (New Relic)
  • The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win (Amazon)
  • The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations (Amazon)
  • The Unicorn Project: A Novel about Developers, Digital Disruption, and Thriving in the Age of Data (Amazon)
  • DevOps is a culture, not a role! (Medium)
  • Why is kubernetes source code an order of magnitude larger than other container orchestrators? (Stack Overflow)
  • Welcoming Molly – The DEV Team’s First Lead SRE! (, Molly Struve)
  • The DevOps Checklist (
  • Vagrant (

Tip of the Week

  • Edit your last Slack message by pressing the UP arrow key. That and more keyboard shortcuts available in the Slack Help Center. (Slack)
  • Integrate Linux Commands into Windows with PowerShell and the Windows Subsystem for Linux (
  • Use readlink to see where a symlink ultimately lands. (
  • What are Durable Functions? (
  • Change your Cmder theme to Allen’s favorite: Babun. (
  • My favourite Git commit (

Oct 28 2019



3factor app – Async Serverless

Podcast cover
Read more

We take an introspective look into what’s wrong with Michael’s life, Allen keeps taking us down random tangents, and Joe misses the chance for the perfect joke as we wrap up our deep dive into Hasura’s 3factor app architecture pattern.

For those reading these show notes via their podcast player, this episode’s full show notes can be found at


  • – Sign up today for a free 14 day trial and get a free Datadog t-shirt after creating your first dashboard.
  • O’Reilly Software Architecture Conference – Microservices, domain-driven design, and more. The O’Reilly Software Architecture Conference covers the skills and tools every software architect needs. Use the code BLOCKS during registration to get 20% off of most passes.
  • – Level up your coding skills, quickly and efficiently. Visit to get 20% off any course.

Survey Says …

Anonymous VoteSign in with Wordpress
Which relational database is your go to?
  • Postgres, the elephant in the room.
  • MySQL, the digital adventures of Flipper.
  • SQL Server. _It looks like you're trying to create a database._ -Clippy
  • Oracle, the big red box.
  • RDBMS? pfft ... NoSQL.
  • Graph databases are where it's at.


  • Thank you to everyone that left us a review:
    • iTunes: codeand40k, buckrivard
    • Stitcher: Jediknightluke, nmolina

Factor Tres – Async Serverless

The first two factors, realtime GraphQL and reliable eventing, provide the foundation for a decoupled architecture that paves the way for the third factor: async serverless.

These serverless processes meet two properties:

  • Idempotency: Events are delivered at least once.
  • Out of order messaging: The order the events are received is not guaranteed.

Traditional vs 3factor app

Traditional application3factor applicationSynchronous procedure code.Loosely coupled event handlers.Deployed on VMs or containers.Deployed on serverless platforms.You manage the platform.The platform is managed for you.Requires operational expertise.No operational expertise necessary.Auto-scale when possible.Auto-scales by default.

Benefits of serverless architectures

  • No-ops: no run time to manage.
  • Free scale: scales based on utilization.
  • Cost: you pay for utilization.

Sample serverless providers

When to use the 3 Factor app?

  • Multiple subsystems that need to subscribe to the same events.
  • Low latency events.
  • Complex event processing.
  • High volume, velocity data.


  • Producers and consumers are decoupled.
  • No point-to point-integrations.
  • Consumers can respond to events immediately as they arrive.
  • Highly scalable and distributed.
  • Subsystems have independent views of the event stream.


  • Guaranteed event delivery.
  • Processing events in order.
  • Processing events exactly once.
  • Latency related to initial serverless start up time.
The five key phases of software development.

Resources We Like

Tip of the Week

  • Keep your email address private in your GitHub repo’s git log by setting your email address to like git config (GitHub)
  • Darknet Diaries: True stories from the dark side of the Internet (
  • ARM Template Viewer for VS Code displays a graphical preview of Azure Resource Manager (ARM) templates. (
  • WSL Support Framework for IntelliJ and RubyMine (
    • Visual Studio Code Remote – WSL extension lets you use the Windows Subsystem for Linux as your development environment within VS Code. (
  • What is Azure Data Studio? (
  • The DevOps Handbook is available on Audible! And iTunes! (Audible, Amazon, iTunes)

Oct 14 2019

1hr 31mins


3factor app – Reliable Eventing

Podcast cover
Read more

We discuss the second factor of Hasura’s 3factor app, Reliable Eventing, as Allen says he still _surfs_ the Internet (but really, does he?), it’s never too late for pizza according to Joe, and Michael wants to un-hear things.

This episode’s full show notes can be found at, just in case you’re using your podcast player to read this.


Survey Says …

Anonymous VoteSign in with Wordpress
What's the first thing you do when picking up a new technology or stack?
  • Take a course, like on
  • Google the pros and cons. Share the ones that support your opinion.
  • Bing the best practices. Pray there are some.
  • Find the Stack Overflow answer that you most agree with and supports your theory.


  • Thank you to everyone that left us a review:
    • iTunes: !theBestCoder, guacamoly, Fishslider
    • Stitcher: SpottieDog
  • We have photographic evidence that we were in the same room with Beej from Complete Developer at Atlanta Code Camp.

@BowtieBeej hanging out with @THEjoezack @theallenu @iamwaltuo from @CodingBlocks #atlcodecamp

— Complete Developer #MusicCityTech (@CompleteDevPod) September 14, 2019

The Second Factor – Reliable Eventing

  • Don’t allow for mutable state. Get rid of in memory state manipulation in APIs.
  • Persist everything in atomic events.
  • The event system should have the following characteristics:
    • Atomic – the entire operation must succeed and be isolated from other operations.
    • Reliable – events should be delivered to subscribers at least once.

Comparing the 3factor app Eventing to Traditional Transactions

Traditional application3factor applicationRequest is issued, data loaded from various storage areas, apply business logic, and finally commit the data to storage.Request is issued and all events are stored individually.Avoid using async features because it’s difficult to rollback when there are problems.Due to the use of the event system, async operations are much easier to implement.Have to implement custom recovery logic to rewind the business logic.Recovery logic isn’t required since the events are atomic.

Benefits of an Immutable Event Log

  • Primary benefit is simplicity when dealing with recovery. There’s no custom business logic because all the event data is available for replayability.
  • Due to the nature of persisting the individual event data, you have a built in audit trail, without the need for additional logging.
  • Replicating the application is as simple as taking the events and replaying the business logic on top of them.

Downsides of the Immutable Event Log

  • Information isn’t (instantly) queryable, not taking into account snapshotting.
    • CQRS (command query responsibility segregation) helps to answer this particular problem.
  • Forcing event sourcing on every part of the system introduces significant complexity where it may not be needed.
  • For evolving applications, changing business needs require changes to the event schema and this can become very complex and difficult to maintain.
    • Upcasting: converting an event record on the fly to reflect a newer schema. Problem with this is you’ve now defeated the purpose of immutable events.
    • Lazy upcasting is evolving the event records over time, but that means you’re now maintaining code that knows how to understand each version of the event records in the system, making it very difficult to maintain.
    • Converting the entire set of data any time a schema needs to change. Keeps things in sync but at a potentially large cost of taking the hit to update everything.
  • Considerations of event granularity, i.e. how many isolated events are too much and how few are not enough?
    • Too many and there won’t be enough information attached to the event to be meaningful and useful.
    • Too few and you take a major hit on serialization/deserialization and you run the risk of not having any domain value.
    • So what’s the best granularity? Keep the events closely tied to the DDD intent.
  • Fixing bugs in the system may be quite a bit more difficult than a simple update query in a database because events are supposed to be immutable.

Resources We Like

Tip of the Week

  • Use docker system to manage your Docker environment.
    • Use docker system df to see the the disk usage.
    • Use docker system prune to clean up your environment.
  • How To View Clipboard History On Windows 10 (
  • Use docker-compose down -v to also remove the volumes when stopping your containers.
  • Intel 660p M.2 2TB NVMe PCIe SSD (Amazon)
  • Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems (Amazon)

Sep 30 2019

2hr 3mins


3factor app – Realtime GraphQL

Podcast cover
Read more

We begin to twitch as we review the first factor of Hasura’s 3factor app, Realtime GraphQL, while Allen gets distrac … SQUIRREL!, Michael might own some bell bottoms, and Joe is stuck with cobalt.

If you’re reading these notes via your podcast app, you can find this episode’s full show notes and join in on the conversation at


  • – Sign up today for a free 14 day trial and get a free Datadog t-shirt after creating your first dashboard.
  • O’Reilly Software Architecture Conference – Microservices, domain-driven design, and more. The O’Reilly Software Architecture Conference covers the skills and tools every software architect needs. Use the code BLOCKS during registration to get 20% off of most passes.
  • – Level up your coding skills, quickly and efficiently. Visit to get 20% off any course.

Survey Says …

Anonymous VoteSign in with Wordpress
Would you be interested in doing a Coding Blocks Fantasy Football League?
  • How has this not been a thing for six years?! YES!!!
  • Sportsball ... puuuuuhhhhhhhleasssseeeee ... NO!!!
  • A fantasy game for soccer? Silly Americans ...


  • To everyone that took a moment to leave us a review, thank you. We really appreciate it.
    • iTunes: Zj, Who farted? Not me., Markus Johansson, this jus10, siftycat, Runs-With-Scissors
    • Stitcher: wuddadid, unclescooter
  • Zach Ingbretsen gives us a Vim tutorial: RAW Vim Workshop/Tutorial (YouTube)

3factor app and the First Factor

3factor app

  • The 3factor app is a modern architecture for full stack applications, described by the folks at Hasura.
  • High feature velocity and scalability from the start:
    • Real time GraphQL
    • Reliable eventing
    • Async serverless
  • Kinda boils down to …
    • Have an API gateway (for them, GraphQL).
    • Store state in a (most likely distributed) store.
    • Have services interact with state via an event system.
  • Versus how did we used to do things using a REST API for each individual entity.
    • Let’s be honest though. We probably created a single very specialized REST API for a particular page all in the name of performance. But it was only used for that page.
  • Related technologies:
    • Web Sockets
    • Serverless
    • Lambda / Kappa – Types Streaming architectures
    • Event based architectures
    • Microservices

Factor 1 – Realtime GraphQL

Use Realtime GraphQL as the Data API Layer
  • Must be low-latency.
    • Less than 100 ms is ideal.
  • Must support subscriptions.
    • Allows the application to consume information from the GraphQL API in real-time.
Some Comparisons to Typical Backend API Calls
Traditional application3factor applicationUses REST calls.Uses GraphQL API.May require multiple calls to retrieve all data (customer, order, order details) – OR a complex purpose built call that will return all three in one call. Uses GraphQL query to return data needed in a single call defined by the caller.Uses something like Swagger to generate API documentation.GraphQL will auto-generate entire schema and related documents.For realtime you’ll set up WebSocket based APIs.Use GraphQL’s native subscriptions.Continuously poll backend for updates.Use GraphQL’s event based subscriptions to receive updates.

Major Benefits of GraphQL
  • Massively accelerates front-end development speed because developers can get the data they want without any need to build additional APIs.
  • GraphQL APIs are strongly typed.
  • Don’t need to maintain additional documenting tools. Using a UI like GraphiQL, you can explore data by writing queries with an Intellisense like auto-complete experience.
  • Realtime built in natively.
  • Prevents over-fetching. Sorta. To the client, yes. Not necessarily so though on the server side.
A Little More About GraphQL
  • GraphQL is a Query Language for your API.
  • It isn’t tied to any particular database or storage engine.
  • It’s backed by your existing code and data.
  • Queries are all about asking for specific fields on objects.
  • The shape of your query will match the shape of the results.
  • Queries allow for traversing relationships, so you can get all the data you need in a single request.
    • Every field and nested object has its own set of arguments that can be passed.
      • Many types are supported, including enums.
  • Aliases
    • GraphQL has the ability to alias fields to return multiple results of the same type but with different return names (think of aliasing tables in a database query).
  • Fragments
    • Fragments allow you to save a set of query fields to retrieve, allowing you to later reuse those fragments in simpler queries. This allows you to create complex queries with a much smaller syntax.
    • There’s even the ability to use variables within the fragments for further queries requiring more flexibility.
  • Operations
    • Three types of operations are supported: query, mutation, and subscription.
    • Providing an operation name is not required, except for multi-operation documents, but is recommended to aid debugging and server side logging.
  • Variables
    • Queries are typically dynamic by way of variables.
    • Supported variable types are scalars, enums, and input object types.
      • Input object types must map to server defined objects.
    • Can be optional or required.
    • Default values are supported.
    • Using variables, you can shape the results of a query.
  • Mutations
    • Mutations allow for modifying data.
    • Nesting objects allows you to return data after the mutation occurs,
    • Mutations, unlike queries, run sequentially, meaning mutation1 will finish before mutation2 runs.
      • In contrast, queries run in parallel.
  • Meta fields
    • GraphQL also provides meta fields that you can use to inspect the schema that are part of the introspection system.
    • These meta fields are preceded by a double underscore, like __schema or __typename.
  • GraphQL schema language
    • Objects are the building blocks of a schema.
    • Fields are properties that are available on the object.
    • Field return types are defined as well – scalar, enum or objects.
      • Scalar types: Int, Float, String Boolean, ID (special use case), or User Defined – must specify serializer, deserializer and validator.
    • Fields can also be defined as non-nullable with an exclamation after the type like String!.
      • This can be done on array types as well after the square brackets to indicate that an array will always be returned, with zero or more elements, like [String]!.
    • Each field can have zero or more arguments and those arguments can have default values.
    • Lists are supported by using square brackets.
    • GraphQL’s type system supports interfaces.
    • Complex objects can also be passed as input types, however, they are defined as input rather than type.

Resources We Like

Tip of the Week

  • From Google’s Engineering Practices documentation: How to do a code review (
    • This is part of the larger Google Engineering Practices Documentation (
  • Use CTRL+SHIFT+V to access Visual Studio’s Clipboard Ring.
  • Take control of your tab usage in your browser with Workona.
  • Theme your Chrome DevTools!

TIL you can add custom themes to Chrome’s DevTools!

— Ali Spittel (@ASpittel) September 5, 2019

Sep 17 2019

2hr 21mins


The Pragmatic Programmer – How to Build Pragmatic Teams

Podcast cover
Read more

We learn how to apply the concepts of The Pragmatic Programmer to teams while Michael uses his advertisement voice, Joe has a list, and Allen doesn’t want anyone up in his Wheaties.

In case you’re using your podcast player to read these show notes, you can find this episode’s full show notes and join the conversation at


Survey Says …

Anonymous VoteSign in with Wordpress
What's your favorite type of swag?
  • Stickers, because they make my laptop go faster.
  • Shirts, because I wear them pretty often and they make me look pretty.
  • Water bottles. Gotta stay hydrated. And then run to the bathroom inbetween talks.
  • Coffee cups. Coding requires coffee.
  • Hats, because everyone has a bad hair day every now and then.
  • Socks. Everyone loves super cute socks. Except Florida man.
  • Bags, because they cost the most.
  • Pens/notebooks, in case I need to write something down super quick!


Building Pragmatic Teams

  • The methods learned so far from this book can be applied to teams in addition to the individual.
  • By working on a “pragmatic team”, the advantages of practicing the methods of the book are multiplied many times over.
  • However, these methods are only a starting point. Pragmatic teams will evolve, adapt, and refine these practices to best fit their environment.

No Broken Windows

  • Everyone on the team should care about quality.
  • Pragmatic teams can not accept broken windows.
  • Quality needs to come from every team member.

Boiled Frogs

  • It is easy for an individual to overlook the overall big picture environment while in the heat of a project’s development. It’s even easier for teams.
    • Team members can easily assume that someone else is addressing a bug, or that some environmental change was OK’d.
    • Keep in mind, environment changes don’t necessarily have to mean hardware or configuration. It could mean, bringing in a new technology for example.
  • Everyone should be on the lookout for changes to the environment.
    • The authors suggest appointing a chief water tester to monitor scope creep, timelines, and environments … anything that wasn’t originally agreed upon.
  • Keep metrics on new requirements.
  • Pragmatic teams shouldn’t reject new feature requests outright.
    • Instead, be aware when and that they occur.
    • Otherwise, you might be the one boiling.


  • Pragmatic teams need to communicate clearly to the everyone else as one voice.
  • The worst teams are those that bad tempered or difficult to get information from.
    • Their meetings have no structure. No one wants to talk.
    • Their documentation is awful. No two documents have the same format and each use different terminology, i.e. no ubiquitous language.
  • Great teams have a personality.
    • You look forward to meeting with them because they are organized.
    • Their presentations are well-prepared.
    • Their documentation is consistent. Current. Accurate. Concise.
    • All members of the team use the same ubiquitous language and speak with one voice.
      • Externally. Internally, they have lively debates, where strong opinions are expressed.
        • Good developers are passionate developers.
  • The simple marketing trick to communicate as one: generate a brand.
    • Create a team name and logo.
    • When communicating with others, use the name/logo.
      • It builds an identity for your team to build on.
      • As well as something memorable for others to associate your work with.

Don’t Repeat Yourself

  • Duplication is wasted effort.
  • This duplicated effort can create maintenance headaches.
  • Good communication between teams can help reduce duplication.
  • A project librarian can coordinate documentation and repositories.
    • Other’s can go to the librarian when they’re looking for something.
    • And the librarian can spot duplication when they’ve been given something new.
  • However, if the project is too big for one librarian, appoint a few people as the primary contacts for various functional areas of the project.
  • And don’t forget the value of online user groups, mailing lists, forums, wikis, etc. for archiving questions/answers, and discussions.


  • Traditional teams are organized such that individuals are assigned roles based on their job function.
    • The Rational Unified Process: An Introduction (Amazon) identifies 27 different roles within a project!
  • Roles have an implicit hierarchy: the closer the role is to the user, the more senior the role.
  • Some development environments have strict divisions of responsibility.
    • You might not be able to talk to the testers or the chief architect, for example.
    • To make matters worse, some organizations might have different sub-teams report to different management chains.
  • Don’t fall victim to thinking that the various tasks for a project can happen in isolation, because they can’t.
  • Analysis, design, coding, testing – These are all different perspectives of the same problem.
  • Developers that are two or three levels removed from the user will likely not be aware of how their code is used and therefore not able to make informed decisions while developing it.
Tip 60
  • Organize Around Functionality, Not Job Functions.

Team Division

  • The authors prefer to split teams up by functionality.
  • Each (small) team should be responsible for a small aspect of the overall system.
  • And each team is responsible to each other.
  • Commitments change with each project and so do the people per team.
  • Splitting the teams up by functionality doesn’t need to translate to use cases though.
    • The DB can count as a team. The help subsystem can count as a team.
  • Look for largely self-contained groups of people.
    • This is similar to how we’d break up code into modules.
      • Use the same techniques, such as by contract, decoupling, and orthogonality.
      • By doing so, we help isolate the entire team from changes outside it.
  • When done properly, this can reduce interactions, reduce time scales, increase quality, and reduce bugs.
  • Developers will be more committed.
  • Teams will feel more ownership because they know they alone are responsible for their part.
  • But this approach will only work with responsible developers and strong project management.

Two heads

  • Each project has two heads: one technical and other other administrative.
  • The technical head is responsible for the development style, assigns responsibilities, and arbitrates discussions.
    • All that while always keeping an eye on the big picture, removing unnecessary commonality among teams to maintain high orthogonality.
  • This person is the lead architect.
  • The administrative head is the project manager.
    • They schedule necessary resources, monitor and report on progress to the stakeholders, and might also act as the PR representative when communicating outside of the teams.

Additional Resources for Larger Teams

  • Librarian – Indexes and stores code and documentation.
  • A tool builder – Someone that provides the tools, environments, and support.


  • The best way to ensure consistency and accuracy is to automate everything that can be automated.
    • That bash script, makefile, etc. isn’t going to change itself. Typically.
    • And it can be versioned.
  • Automation is an essential element of a Pragmatic Team.
  • Appoint one or more people as the tool builders to build and deploy tools that automate the project’s boring parts.

Know When to Stop Adding Paint

  • Pragmatic teams give each member the opportunity to shine.
  • They provide team members with enough structure to support them and ensure the project delivers against those requirements.
  • And then resist the urge to add more paint.

Resources We Like

Tip of the Week

  • Git tips:
    • Undo your last commit: git reset HEAD~ (Stack Overflow)
    • Undo all of your current changes and reset the environment back to the last commit: git reset --hard HEAD
    • Remove all untracked files: git clean -f
      • Remove untracked directories, too: git clean -f -d
  • Joe’s reasons to use Kotlin (in no particular order):
  • Overview of Microsoft Authentication Library (MSAL) (

Sep 03 2019

2hr 7mins


The Pragmatic Programmer – How to use Exceptions

Podcast cover
Read more

After 112 episodes, Michael can’t introduce the show, Allen pronounces it “ma-meee”, and don’t make Joe run your janky tests as The Pragmatic Programmer teaches us how we should use exceptions and program deliberately.

How are you reading this? If you answered via your podcast player, you can find this episode’s full show notes and join the conversation at


  • – Sign up today for a free 14 day trial and get a free Datadog t-shirt after creating your first dashboard.

Survey Says …

Anonymous VoteSign in with Wordpress
When you want to bring in a new technology or take a new approach when implementing something new or add to the tech stack, do you ...?
  • a.) Ask peer's if it's a good idea before implementing it? The voice of many carries more weight.
  • b.) Ask the relative team lead if you can implement it? If the boss doesn't like it, it doesn't matter.
  • c.) Implement a proof-of-concept and get stakeholders to weigh in? Because they don't know about it, they need to be sold on it.
  • d.) Just do it. I can't waste precious time checking if other's like my idea.
  • e.) Abandon it. It's already too much effort.


  • Thank you for taking a moment out of your day to leave us a review.
    • iTunes: MatteKarla, WinnerOfTheRaceCondition, michael_mancuso
    • Stitcher: rundevcycle, Canmichaelpronouncethis, WinnerOfTheRaceCondition, C_Flat_Fella, UncleBobsNephew, alexUnique
  • Autonomous ErgoChair 2 Review (YouTube)
  • Come see us Saturday, September 14, 2019 at the Atlanta Code Camp 2019 (
  • Are they cakes, cookies, or biscuits? (Wikipedia)

Intentional Code

When to use Exceptions

  • In an earlier chapter, Dead Programs Tell No Lies, the book recommends:
    • Checking for every possible error.
    • Favor crashing your program over running into an inconsistent state.
  • This can get really ugly! Especially if you believe in the “one return at the bottom” methodology for your methods.
  • You can accomplish the same thing by just catching an exception for a block of code, and throwing your own with additional information.
  • This is nice, but it brings up the question? When should you return a failed status, and when should you throw an exception?
  • Do you tend to throw more exceptions in one layer more than another, such as throwing more in your C# layer than your JS layer?
  • The authors advise throwing exceptions for unexpected events.
  • Ask yourself, will the code still work if I remove the exception handlers? If you answered “no”, then maybe your throwing exceptions for non-exceptional circumstances.
Tip 34
  • Use exceptions for exceptional problems

Exceptions vs Error Handling

  • Should you throw an exception if you try to open a file, and it doesn’t exist?
    • If it should be there, i.e. a config, yes, throw the exception.
    • If it might be OK for it not to be there, i.e. you’re polling for a file to be created, then no, you should handle the error condition.
  • Is it dangerous to rely on implicit exception throwing, i.e. opening a file that isn’t there?
    • On the one hand, it’s cleaner without checking for the exceptions, but there’s no signaling to your co-coders that you did this intentionally.
    • Exceptions are a kind of coupling because they break the normal input/output contract.
  • Some languages / frameworks allow you to register error handlers that are outside the flow of the normal problem.
    • This is great for certain types of problems, like serialization problems, particularly when there is a prescribed flow, such as error pages, serialization, or SSL errors.

Programming by Coincidence

  • What does it mean to “program by coincidence”?
    • Getting lured into a false sense of security and then getting hit by what you were trying to avoid.
  • Avoid programming by coincidence and instead program deliberately. Don’t rely on being lucky.
  • Writing code and seeing that it works without fully understanding why is how you program by coincidence.
    • This really becomes a problem when something goes wrong and you can’t figure out why because you never knew why it worked to start off with.
  • We may not be innocent …
    • What if you write code that adheres to some other code that was done in error … if that code is eventually fixed, your own code may fail.
  • So if it’s working, why would you touch it?
    • It might not actually be working …
      • Maybe it doesn’t work with a different resolution.
      • Undocumented code might change, thus changing your “luck”.
      • Unnecessary method calls slow down the code.
      • Those extra calls increase the risk of bugs.
  • Write code that others implement with well documented code that adheres to a contract.

Accidents of Context

  • You can also make the mistake that you assume certain things are a given, such as that there’s a UI or that there’s a given language.

Implicit Assumptions

  • Don’t assume something, prove it.
  • Assumptions that aren’t based on fact become a major sticking point in many cases.
Tip 44
  • Don’t Program by Coincidence

How to Program Deliberately

  • Always be aware of what you’re doing.
  • Don’t code blindfolded, Make sure you understand what you’re programming in, both business domain related and programming language.
  • Code from a plan.
  • Rely on reliable things. Don’t code based on assumptions.
  • Document assumptions.
  • Test your code _and_ your assumptions.
  • Prioritize and spend time on the most important aspects first.
  • Don’t let old code dictate new code. Be prepared to refactor if necessary.

Resources We Like

  • The Pragmatic Programmer by Andrew Hunt, David Thomas (Amazon)
  • The Pragmatic Bookshelf (
  • Oh mother… | Family Feud (YouTube)
    • OMG! It’s here! Oh mother… the ON-AIR VERSION!!! | Family Feud (YouTube)
  • Thunder Talks (episode 87)
  • Spotify engineering culture (part 1) (

Tip of the Week

Aug 20 2019

1hr 54mins


The Pragmatic Programmer – How to Generate Code

Podcast cover
Read more

We continue our dive into The Pragmatic Programmer and debate when is it text manipulation vs code generation as Joe can’t read his bill, Michael makes a painful recommendation, and Allen’s gaming lives up to Southern expectations.

In case you’re reading these show notes via your podcast player, you can find this episode’s full show notes at and join in on the conversation.


  • Clubhouse – The first project management platform for software development that brings everyone on every team together to build better products. Sign up for two free months of Clubhouse by visiting
  • – Sign up today for a free 14 day trial and get a free Datadog t-shirt after creating your first dashboard.

Survey Says …

Anonymous VoteSign in with Wordpress
What native language are you most interested in?
  • Rust, because safety first.
  • Go, because I wanna be fast and parallel.
  • C, the old ways are best.
  • C++, the good parts.
  • No thanks, I have deadlines.
  • You forgot mine, you expletives.


  • We really appreciate every review we get. Thank you for taking the time.
    • iTunes: AsIRoseOneMorn, MrBramme, MP7373, tbone189, BernieF1982, Davidwrpayne, mldennison
    • Stitcher: Ben T, moreginger, Tomski, Java Joe

Blurring the Text Manipulation Line

Text Manipulation

  • Programmers manipulate text the same way woodworkers shape wood.
    • Text manipulation tools are like routers: noisy, messy, brutish.
  • You can use text manipulation tools to trim the data into shape.
    • Once you master them, they can provide an impressive amount of finesse.
  • Alternative is to build a more polished tool, check it in, test it, etc.
Tip 28
  • Learn a Text Manipulation Language.

Code Generators

  • When you have a repetitive task, why not generate it?
  • The generated code takes away complexity and reduces errors.
  • And it’s reuse has little to no additional cost.
Tip 29
  • Write Code That Writes Code.

There are two types of code generators:

  1. Passive code generators are run once (scaffolding).
  2. Active code generators are used each time they are required.

Passive code generators save typing by automating…

  • New files from a template, i.e. the “File -> New” experience.
  • One off conversions (one language to another).
    • These don’t need to be completely perfect.
  • Producing lookup tables and other resources that are expensive to compute.
  • Full-fledged source file.

You get to pick how accurate you want the generators to be. Maybe it writes 80% of the code for you and you do the rest by hand.

Active code generators

  • Active code generators are necessary if you want to adhere to the DRY principle.
    • This form is not considered duplication because it’s generated as needed by taking a single representation and converting it to all of the forms you need.
  • Great for system boundaries (think databases or web services).
  • Great for keeping things in sync.
  • Recommend creating your own parser.

Why generate when you can just … program?

  • Scaffolding, so it’s a starting off point that you edit.
  • Performance.
  • System boundaries.
  • Some uses work best when built into your build pipeline.
    • Think about automatically generating code to match your DB at compile time, like a T4 generator for Entity Framework.
  • It’s often easier to express the code to be generated in a language neutral representation so that it can be output in multiple languages.
    • Something like System.CodeDom comes to mind.
  • These generators don’t need to be complex.
  • And the output doesn’t always need to be code. It could be XML, JSON, etc.

Resources We Like

Tip of the Week

  • Within Visual Studio Code, after you use CTRL+F to find some text in your current document, you can take it a step further by pressing ALT+ENTER to enter into block selection/edit mode.
  • Turn learning Vi into a game with VIM Adventures. (
  • Never confuse forward Slash with back Slash again.

know the difference between forward and back slash

— David Neal (@reverentgeek) October 20, 2016

Aug 05 2019

2hr 2mins


The Pragmatic Programmer – How to Debug

Podcast cover
Read more

It’s about time we finally learn how to debug by taking take a page from The Pragmatic Programmer playbook, while Michael replaces a developer’s cheat sheet, Joe judges the H-O-R-S-E competition for VI, and Allen stabs you in the front.

If you’re reading these show notes via your podcast player, be sure to check out where you can find this episode’s full show notes, as well as previous episodes, and be part of the conversation.


  • Clubhouse – The first project management platform for software development that brings everyone on every team together to build better products. Sign up for two free months of Clubhouse by visiting
  • – Sign up today for a free 14 day trial and get a free Datadog t-shirt after creating your first dashboard.

Survey Says …

Anonymous VoteSign in with Wordpress
What your favorite shell of choice?
  • bash
  • ksh
  • ash
  • Dash
  • zsh
  • fish
  • Command Prompt
  • PowerShell


  • We take a moment to thank everyone that left us a review:
    • iTunes: Sebastian Schrodinger, drakegens, svolvovsky, Bert1994DK, -Branford-, MikeMac-AU, dylan w roberts, ManYouFactSharingEngineEar, Jahn_08
    • Stitcher: i_dare_you_to_try_fsharp, geoffster, Mr Maladroit, Stickersoft, InfinitePumpkin, SPACEDANCE
  • The authors of The Pragmatic Programmer, Andrew Hunt and David Thomas, discuss the 20th Anniversary Edition on episode 352 of The Changelog.

The Meat and Potatoes

Power Editing

  • Learn one editor very well and use it for everything.
Tip 22: Use a Single Editor Well
  • If you use a single editor for everything, the keystrokes, commands, shortcuts, etc. will become second nature for various tasks.

Features to look for in your editor

  • Configurable. You should be able to configure all aspects of the editor to your preferences.
  • Extensible. You should be able to configure/integrate with the compiler of your choice.
  • Programmable. You should be able to program the IDE to perform complex tasks (i.e. macros).

Source Control

  • Gives you a giant UNDO button that you can use to rewind days, weeks, or longer!
  • Allows you to see who changed something.
  • Commenting allows you to see the why something changed.
  • Lets you see the differences between versions.
  • You can track which files change the most.
  • Using source control properly allows you to go back to a specific release version in time.
  • Allow for concurrent changes to files.
Tip 23: Always Use Source Control
  • Even if you’re the only one working on the project.
  • Put everything in source control: documentation, memos, phone numbers, etc.

Source Code and Builds

  • Using source control allows for automated code pulls and builds.
  • Additionally if you have automated tests set up, those can be run through as well.


  • The term bug is credited to Rear Admiral Dr. Grace Hopper, inventor of COBOL.
  • Debugging will consume the majority of your day. Accept it.

Psychology of Debugging

  • Accept that debugging is just another form of probem solving.
  • It doesn’t matter who’s to fault for the origin of the bug. It’s your problem now.
Tip 24: Fix the Problem, Not the Blame.

A Debugging Mindset

  • Adopt the right mindset before you start.
  • Drop your defences and forget your ego.
  • Forget about the project pressures and get comfortable.
Tip 25: Don’t Panic
  • Take a step back and think about what conditions might cause the bug.
  • Don’t waste any brain cells on thoughts like “that can’t happen” because it has.
  • Don’t just fix the bug though.
    • Determine the root cause and fix that so that it doesn’t happen again.

Where to Start

  • Before you start, first make sure your environment compiles.
  • Set your compiler to treat warnings as errors so that you can focus on the more difficult problems.
  • Talk to the user that reported the bug (if possible). You may be able to get more information.
  • Test boundary conditions and realistic usage patterns.
  • “The best way to start fixing a bug is to make it reproducible.”
    • Create a unit test that reproduces the bug when applicable.


  • Debuggers focus on the state of the application now, but sometimes you need to watch the state over time.
  • Tracing statements are diagnostic messages printed out that say something like got here or value of x = 2.
    • When doing this, sometimes it’s helpful to add the fully qualified method name (like class::method()) to remove ambiguity.
  • Tracing can be invaluable when time itself is a factor.
  • These tracing statements should be in a consistent format.

Rubber Ducking

  • Simply talk through the problem to someone else. Seems silly, but it often works.
  • The simple act of describing step-by-step what is supposed to happen often causes the problem to leap out as you explain it.
  • By forcing yourself to explain it verbally to someone else, you have to state things that you might otherwise take for granted.

Process of Elimination

  • While it might be possible that a bug exists in a 3rd party library or the OS, this shouldn’t be your first thought.
    • Assume that the problem is in your code first.
    • Even if the library does have a bug, you will still need to eliminate the possibility of an issue in your code first before submitting the bug report.
Tip 26: “select” Isn’t Broken
  • If you changed one thing and things stopped working, guess what? It’s probably that one thing.
  • If you don’t have an idea of where to start, a binary search can help.

The Element of Surprise

  • When you find yourself surprised by a bug saying something like “that’s impossible”, you must reevaluate what you know as true.
  • The amount of surprise you have is directly proportional to the amount of trust you have in that particular code.
  • You must accept that one or more of your assumptions is wrong.
  • Don’t gloss over a piece of code because you “know” it works.
    • Prove that it works. In this situation. With this data. And these conditions.
Tip 27: Don’t Assume It – Prove It
  • Determine why this bug wasn’t caught before.
  • Create or update unit tests so that it is caught in the future.
  • Ask yourself: “Are there other places that might have this same bug?” If so, fix them, too.
  • If it took a while to fix this bug, ask yourself why?
    • Is there anything you can do (i.e. refactor) that would make it easier in the future.
  • If the bug is due to someone else’s wrong assumption, discuss the issue with the whole team.
    • If one person misunderstood, it’s likely that others did, too.
  • Part of your debugging checklist should include: Are your tests complete?

Resources We Like

  • The Pragmatic Programmer by Andrew Hunt, David Thomas (Amazon)
  • The Pragmatic Bookshelf (

Tip of the Week

  • Preview your markdown in VS Code by using CMD+K V on macOS or CTRL+K V on Windows.
  • Use LINQPad as your ultimate .NET scratchpad. (LINQPad)
  • Use vimtutor to learn VI.
  • Reversee – The super simple reverse proxy web debugger.

Jul 23 2019

1hr 53mins


The Pragmatic Programmer – Know Thy Tools

Podcast cover
Read more
We dig into the details of the basic tools while continuing our journey into The Pragmatic Programmer while Joe programs by coincidence, Michael can't pronounce numbers, and Allen makes a point.

Jul 08 2019

2hr 3mins


The Pragmatic Programmer – How to Estimate

Podcast cover
Read more
Joe is distracted by all of the announcements from E3, Allen is on the run from the Feebs, and Michael counts debugging as coding. All this and more as we continue discussing The Pragmatic Programmer.

Jun 24 2019

1hr 58mins


The Pragmatic Programmer – Tracer Bullets and Prototyping

Podcast cover
Read more
The Pragmatic Programmer teaches us how to use tracer bullets versus prototyping while Joe doesn't know who won the Game of Thrones, Allen thought he knew about road numbers, and Michael thinks 475 is four letters.

Jun 10 2019

1hr 45mins


The Pragmatic Programmer – Is Your Code Orthogonal?

Podcast cover
Read more
The dad jokes are back as we learn about orthogonal code while JZ (the 8-mile guy) has spaghetti on him, Michael's Harry Potter references fail, and Allen voice goes up a couple octaves.

May 27 2019

2hr 1min


The Pragmatic Programmer – The Evils of Duplication

Podcast cover
Read more
We take a deep dive into the various forms of duplication and jump aboard the complain train as Allen complains about Confluent's documentation, Michael complains about Docker's documentation, and Joe complains about curl.

May 13 2019

1hr 46mins


The Pragmatic Programmer – Investing in Your Knowledge Portfolio

Podcast cover
Read more
We begin our journey into the wisdom of The Pragmatic Programmer, which as Joe puts it, it’s less about type-y type-y and more about think-y think-y, while Allen is not quite as pessimistic as Joe, and Michael can’t wait to say his smart words. If you’re reading these show notes via your podcast player, you […]

Apr 29 2019

2hr 36mins


Should Your Web App be a Progressive Web App (PWA)?

Podcast cover
Read more
We dig into the nitty gritty details of what a Progressive Web App (PWA) is and why you should care, while Allen isn't sure if he is recording, Michael was the only one prepared to talk about Flo and the Progressive Price Gun, and Joe has to get his headphones.

Apr 15 2019

1hr 58mins


The Second Date is Always Easier

Podcast cover
Read more
The Date deep dive continues as we focus in on C# and JavaScript, while Michael reminisces about the fluorescent crayons, Joe needs a new tip of the week, and Allen confuses time zones.

Apr 01 2019

1hr 38mins


Why Date-ing is Hard

Podcast cover
Read more
We take a deep dive into understanding why all Date-s are not created equal while learning that Joe is not a fan of months, King Kong has nothing on Allen, and Michael still uses GETDATE(). Oops.

Mar 18 2019

1hr 46mins


What Should You Learn Next?

Podcast cover
Read more
After being asked to quiet down, our friend, John Stone, joins us again as we move the conversation to the nearest cubicle while Michael reminds us of Bing, Joe regrets getting a cellphone, and Allen's accent might surprise you.

Mar 04 2019

1hr 14mins