Cover image of Coding Blocks

Rank #82 in Technology category

How To

Coding Blocks

Updated 2 months ago

Rank #82 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

736 Ratings
Average Ratings


By akirakinski - May 22 2020
Read more
Thanks to these guys my blocks are THOROUGHLY coded. The only podcast I listen to at 1X speed. Some of my favorite nerds and ain’t sure they’ll be yours too.

Grocery store

By index out of range - Mar 08 2020
Read more
This podcast is like a big American grocery store that sells developer centric “food for thought”.

iTunes Ratings

736 Ratings
Average Ratings


By akirakinski - May 22 2020
Read more
Thanks to these guys my blocks are THOROUGHLY coded. The only podcast I listen to at 1X speed. Some of my favorite nerds and ain’t sure they’ll be yours too.

Grocery store

By index out of range - Mar 08 2020
Read more
This podcast is like a big American grocery store that sells developer centric “food for thought”.
Cover image of Coding Blocks

Coding Blocks

Latest release on Aug 03, 2020

Read more

Become the best software developer you can be

Rank #1: 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


Rank #2: 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


Rank #3: Clean Code – Objects vs Data Structures

Podcast cover
Read more
This week we’re drawing a line in the sand between objects and data structures. Who will win? Take a listen and decide for yourself! For the full show notes visit: Podcast News iTunes Reviews: DelBoyeire, nullthecode, Ser_j, Pneema, matthew.watkins, JC_JavaScripter, Connor Phee, Stratodavius, GS Leonric, dmitry.gokun, MobileMon, vasyl shcherbatjuk Stitcher Reviews: tommyrush, DoNotAsk, nullthecode, […]

Dec 13 2016


Rank #4: 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


Rank #5: 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


Rank #6: 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


Rank #7: We’re Testing Your Patience…

Podcast cover
Read more
I figured this title was appropriate considering it's been a month since our last episode.  We've all been incredibly busy so we hope you've been patient waiting and maybe, just maybe it was worth the wait!  We've crammed quite a bit into this episode which is all about testing.  Follow the more link to see the show notes for this particular episode and don't forget to click one of the share buttons there to let all your friends know about the podcast!

Dec 15 2014

1hr 26mins


Rank #8: 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.

Nov 25 2019

2hr 2mins


Rank #9: 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


Rank #10: 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


Rank #11: 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


Rank #12: 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


Rank #13: 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


Rank #14: 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


Rank #15: 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.

Oct 28 2019



Rank #16: 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


Rank #17: 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


Rank #18: 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



Rank #19: 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


Rank #20: 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


The DevOps Handbook – The Technical Practices of Feedback

Podcast cover
Read more

It’s all about telemetry and feedback as we continue learning from The DevOps Handbook, while Joe knows his versions, Michael might have gone crazy if he didn’t find it, and Allen has more than enough muscles.

For those that use their podcast player to read these show notes, did you know that you can find them at Well, you can. And now you know, and knowing is half the battle.


  • Datadog – Sign up today for a free 14 day trial and get a free Datadog t-shirt after your first dashboard.
  • Secure Code Warrior – Start gamifying your organization’s security posture today, score 5,000 points, and get a free Secure Code Warrior t-shirt.

Survey Says

Anonymous VoteSign in with Wordpress
Which one?
  • Coca Cola, because I'd like to teach the world to sing.
  • Pepsi, it's hair on fire good.


  • We give a heartfelt thank you in our best announcer voice to everyone that left us a new review!
    • iTunes: TomJerry24, Adam Korynta
    • Stitcher: VirtualShinKicker, babbansen, Felixcited
  • Cost of a Data Breach Report 2020 (IBM)
  • Garmin Risks Repeat Attack If It Paid $10 Million Ransom (Forbes)
  • Almost 4,000 databases wiped in ‘Meow’ attacks (

The Second Way: The Principles of Feedback

Implementing the technical practices of the Second Way

  • Provides fast and continuous feedback from operations to development.
  • Allows us to find and fix problems earlier on the software development life cycle.

Create Telemetry to Enable Seeing and Solving Problems

  • Identifying what causes problems can be difficult to pinpoint: was it the code, was it networking, was it something else?
  • Use a disciplined approach to identifying the problems, don’t just reboot servers.
  • The only way to do this effectively is to always be generating telemetry.
    • Needs to be in our applications and deployment pipelines.
    • More metrics provide the confidence to change things.
  • Companies that track telemetry are 168 times faster at resolving incidents than companies that don’t, per the 2015 State of DevOps Report (Puppet).
    • The two things that contributed to this increased MTTR ability was operations using source control and proactive monitoring (i.e. telemetry).

Create Centralized Telemetry Infrastructure

  • Must create a comprehensive set of telemetry from application metrics to operational metrics so you can see how the system operates as a whole.
    • Data collection at the business logic, application, and environmental layers via events, logs and metrics.
    • Event router that stores events and metrics.
      • This enables visualization, trending, alerting, and anomaly detection.
      • Transforms logs into metrics, grouping by known elements.
    • Need to collect telemetry from our deployment pipelines, for metrics like:
      • How many unit tests failed?
      • How long it takes to build and execute tests?
      • Static code analysis.
  • Telemetry should be easily accessible via APIs.
  • The telemetry data should be usable without the application that produced the logs

Create Application Logging Telemetry that Helps Production

  • Dev and Ops need to be creating telemetry as part of their daily work for new and old services.
Should at least be familiar with the standard log levels
  • Debug – extremely verbose, logs just about everything that happens in an application, typically disabled in production unless diagnosing a problem.
  • Info – typically action based logging, either actions initiated by the system or user, such as saving an order.
  • Warn – something you log when it looks like there might be a problem, such as a slow database call.
  • Error – the actual error that occurs in a system.
  • Fatal – logs when something has to exit and why.
Using the appropriate log level is more important than you think
  • Low toner is not an Error. You wouldn’t want to be paged about low toner while sleeping!
  • Examples of some things that should be logged:
    • Authentication events,
    • System and data access,
    • System and app changes,
    • Data operations (CRUD),
    • Invalid input,
    • Resource utilization,
    • Health and availability,
    • Startups and shutdowns,
    • Faults and errors,
    • Circuit breaker trips,
    • Delays,
    • Backup success and failure

Use Telemetry to Guide Problem Solving

  • Lack of telemetry has some negative issues:
    • People use it to avoid being blamed for problems, which can be due to a political atmosphere and SUPER counter-productive.
  • Telemetry allows for scientific methods of problem solving to be used.
    • This approach leads to faster MTTR and a much better relationship between Dev and Ops.

Enable Creation of Production Metrics as Part of Daily Work

  • This needs to be easy, one-line implementations.
  • Use data to generate graphs, and then overlay those graphs with production changes to see if anything changed significantly.
    • This gives you the confidence to make changes.

Create Self-Service Access to Telemetry and Information Radiators

  • Make the data available to anyone in the value stream without having to jump through hoops to get it, be they part of Development, Operations, Product Management, or Infosec, etc.
  • Information radiators are displays which are placed in highly visible locations so everyone can see the information quickly.
    • Nothing to hide from visitors OR from the team itself.

Resources We Like

  • The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations (Amazon)
  • The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win (Amazon)
  • The Unicorn Project: A Novel about Developers, Digital Disruption, and Thriving in the Age of Data (Amazon)
  • 2015 State of DevOps Report (Puppet)
  • StatsD (GitHub)
  • Graphite (
  • Grafana (
  • The Twelve-Factor App (
    • The Twelve-Factor App: Codebase, Dependencies, and Config (episode 32)
    • The Twelve-Factor App: Backing Services, Building and Releasing, Stateless Processes (episode 33)
    • The Twelve-Factor App: Port Binding, Concurrency, and Disposability (episode 35)
    • The Twelve Factor App: Dev/Prod Parity, Logs, and Admin Processes (episode 36)
  • Break Up With IE8 (

Tip of the Week

  • Bookmarks for VS Code (GitHub, Visual Studio Marketplace)
  • Pwn your zsh! (
  • Use Docker BuildKit’s experimental features to enable and use build caches (GitHub)
  • Disable all of your VS Code extensions and then re-enable just the ones you need using CTRL+SHIFT+P. (
  • Color code your environments in Datagrip! Right click on the server and select Color Settings. Use green for local and red for everything else to easily differentiate between the two. Can be applied at the server and/or DB levels. For example, color your default local postgres database orange. This color coding will be applied to both the navigation tree and the open file editors (i.e. tabs).

Aug 03 2020

1hr 51mins


The DevOps Handbook – Architecting for Low-Risk Releases

Podcast cover
Read more

Our journey into the world of DevOps continues with The DevOps Handbook as Michael doesn’t take enough tangents, Joe regrets automating the build, err, wait never regrets (sorry), and ducks really like Allen.

If you’re reading these show notes via your podcast player, you can find this episode’s full show notes at, where you can be a part of the conversation.


  • Datadog – Sign up today for a free 14 day trial and get a free Datadog t-shirt after your first dashboard.
  • Secure Code Warrior – Start gamifying your organization’s security posture today, score 5,000 points, and get a free Secure Code Warrior t-shirt.

Survey Says

Anonymous VoteSign in with Wordpress
What is your meeting limit?
  • One is too many. There is a reason I work with computers.
  • Less than 5 hours/week is okay, so I still have plenty of "me" time.
  • I can handle 10 hours a week, but ain't nobody happy about it.
  • Bring it on! The trick is to mute when you go to the bathroom.


  • Thank you to everyone that left us a new review!
    • iTunes: justsomedudewritingareview, stupub, andrew.diamond, scipiomarcellus
    • Stitcher: Bicycle Repairman, BrunoLC
  • Using Bazel to build and test software of any size, quickly and reliably. (
  • Reflections on Trusting Trust (
  • Build your own Linux distro! (
  • That System76 Oryx Pro keyboard though? (System76)

I really hope laptop manufacturers stop putting numpads on laptops so we can stop the left justification madness.

— Michael Outlaw (@iamwaltuo) July 17, 2020

Fast, Reliable. Pick Two

Continuously Build, Test, and Integrate our Code and Environments

  • Build and test processes run constantly, independent of coding.
  • This ensures that we understand and codify all dependencies.
  • This ensures repeatable deployments and configuration management.
  • Once changes make it into source control, the packages and binaries are created only ONCE. Those same packages are used throughout the rest of the pipeline to ensure all environments are receiving the same bits.
  • What does this mean for our team culture?
    • You need to maintain reliable automated tests that truly validate deploy-ability.
    • You need to stop the “production pipeline” when validation fails, i.e. pull the andon cord.
    • You need to work in small, short lived batches that are based on trunk. No long-lived feature branches.
      • Short, fast feedback loops are necessary; builds on every commit.

Integrate Performance Testing into the Test Suite

  • Should likely build the performance testing environment at the beginning of the project so that it can be used throughout.
  • Logging results on each run is also important. If a set of changes shows a drastic difference from the previous run, then it should be investigated.

Enable and Practice Continuous Integration

  • Small batch and andon cord style development practices optimize for team productivity.
  • Long lived feature branches optimize for individual productivity. But:
    • They require painful integration periods, such as complex merges, which is “invisible work”.
    • They can complicate pipelines.
    • The integration complexity scales exponentially with the number of feature branches in play.
    • They can make adding new features, teams, and individuals to a team really difficult.
  • Trunk based development has some major benefits such as:
    • Merging more often means finding problems sooner.
    • It moves us closer to “single piece flow”, such as single envelope at a time story, like one big assembly line.

Automate and Enable Low-Risk Releases

  • Small batch changes are inherently less risky.
  • The time to fix is strongly correlated with the time to remediate, i.e. the mean time to find (MTF) and the mean time to remediate (MTR).
  • Automation needs to include operational changes, such as restarting services, that need to happen as well.
  • Enable “self-service” deployments. Teams and individuals need to be able to dynamically spin up reliable environments.

Decouple Deployments from Releases

  • Releases are marketing driven and refer to when features are made available to customers.
  • Feature flags can be used to toggle the release of functionality independent of their deployments.
  • Feature flags enable roll back, graceful degradation, graceful release, and resilience.

Architect for Low-Risk Releases

  • Don’t start over! You make a lot of the same mistakes, and new ones, and ultimately end up at the same place. Instead, fix forward!
  • Use the strangler pattern instead to push the good stuff in and push the bad stuff out, like how strangler vines grow to cover and subsume a fig tree.
  • Decouple your code and architecture.
  • Use good, strong versioned APIs, and dependency management to help get there.

Resources We Like

  • The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations (Amazon)
  • The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win (Amazon)
  • The Unicorn Project: A Novel about Developers, Digital Disruption, and Thriving in the Age of Data (Amazon)
  • Andon (manufacturing) (Wikipedia)
  • LEGO Nintendo Entertainment System (
  • Comparing Git Workflows (episode 90)
  • StranglerFigApplication (

Tip of the Week

  • Be sure to check out the gaming channel in Slack to find and connect with some great people for your next game.
    • Also, look up in the Slack channel. There may be cool information in the channel’s description.
  • Within JetBrains IDEs, such as Datagrip and IntelliJ, press CTRL+SHIFT+V to see and choose from the list of items recently copied to the clipboard.
  • Tired of working from home? Work from a park!

Just a thought. I know lots of people who contemplate paying for shared workspaces to get out of the house. Maybe all you need is a tethering plan for your phone, a nice butt pad, and a pretty park near you. #myofficetoday

— Allen Underwood (@theallenu) July 2, 2020
  • Save your sanity by customizing your Macbook Pro Touchbar in Chrome by going to View -> Customize Touchbar.

Jul 20 2020

2hr 5mins


The DevOps Handbook – The Technical Practices of Flow

Podcast cover
Read more

We begin our journey into the repeatable world of DevOps by taking cues from The DevOps Handbook, while Allen loves all things propane, Joe debuts his “singing” career with his new music video, and Michael did a very bad, awful thing.

These show notes can be found at for those reading this via their podcast player.


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

Survey Says

Anonymous VoteSign in with Wordpress
When you do listen to music, how do you do it?
  • Amazon Music
  • Apple Music
  • Spotify
  • YouTube Music
  • Pandora
  • Google Play Music
  • iHeartRadio
  • *The* radio
  • CDs
  • Vinyl


  • We’re very thankful for all of the new reviews!
    • iTunes: galTheJewishHammer, Ragnaroekk, Marcel7473826, rkosko31
    • Stitcher: Bicycle Repairman, BrunoLC
  • Joe serenades us in song! (YouTube)
  • Congratulations Allen on his renewed MVP status!

I am truly, humbly honored to have been awarded the @MVPAward again. Being a part of such an amazing community of folks offering their time and experience is just incredible. #MVPBuzz

Huge thanks to @iamwaltuo @THEjoezack and @CodingBlocks for helping make this happen.

— Allen Underwood (@theallenu) July 2, 2020

What is The DevOps Handbook?

  • It’s a collection of arguments and high level guidance for understanding the spirit of DevOps.
  • It’s light on specifics and heavy on culture. The tools aren’t the problem here, the people need to change.
  • It’s also a book about scaling features, teams, people, and environments.

The First Way: The Principles of Flow

The Deployment Pipeline is the Foundation

Continuous delivery:

  • Reduces the risk associated with deploying and releasing changes.
  • Allows for an automated deployment pipeline.
  • Allows for automated tests.

Environments on Demand

  • Always use production like environments at every stage of the stream.
  • Environments must be created in an automated fashion.
  • Should have all scripts and configurations stored in source control.
  • Should require no intervention from operations.

The reality though …

  • Often times the first time an application is tested in a production like environment, is in production.
  • Many times test and development environments are not configured the same.

Ideally though …

  • Developers should be running their code in production like environments from the very beginning, on their own workstations.
    • This provides an early and constant feedback cycle.
  • Rather than creating wiki pages on how to set things up, the configurations and scripts necessary are committed to source control. This can include any of all of the following:
    • Copying virtualized environments.
    • Building automated environments on bare metal.
    • Using infrastructure as code, i.e. Puppet, Chef, Ansible, Salt, CFEngine, etc.
    • Using automated OS configuration tools.
    • Creating environments from virtual images or containers.
    • Creating new environments in public clouds.

All of this allows entire systems to be spun up quickly making this …

  • A win for operations as they don’t have to constantly battle configuration problems.
  • A win for developers because they can find and fix things very early in the development process that benefits all environments.

“When developers put all their application source files and configurations in version control, it becomes the single repository of truth that contains the precise intended state of the system.”

The DevOps Handbook

Check Everything into One Spot, that Everybody has Access to

Here are the types of things that should be stored in source control:

  • All application code and its dependencies (e.g. libraries, static content, etc.)
  • Scripts for creating databases, lookup data, etc.
  • Environment creation tools and artifacts (VMWare, AMI images, Puppet or Chef recipes).
  • Files used to create containers (Docker files, Rocket definition files, etc.)
  • All automated tests and manual scripts.
  • Scripts for code packaging, deployments, database migrations, and environment provisioning.
  • Additional artifacts such as documentation, deployment procedures, and release notes.
  • Cloud configuration files, such as AWS CloudFormation templates, Azure ARM templates, Terraform scripts, etc.)
  • All scripts or configurations for infrastructure supporting services for things like services buses, firewalls, etc.

Make Infrastructure Easier to Rebuild than to Repair

  • Treat servers like cattle instead of pets, meaning, rather than care for and fix them when they’re broken, instead delete and recreate them.
  • This has the side effect of keeping your architecture fluid.
  • Some have adopted immutable infrastructure where manual changes to environments are not allowed. Instead, changes are in source control which removes variance among environments.

The Definition of Done

  • “Done” means your changeset running in a production-like environment.
  • This ensures that developers are involved in getting code to production and bring operations closer to the code.

Enable Fast and Reliable Automated Testing

  • Automated tests let you move faster, with more confidence, and shortens feedback cycles for catching and fixing problems earlier.
  • Automated testing allowed the Google Web Server team to go from one of the least productive, to most productive group in the company.

Resources We Like

  • The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations (Amazon)
  • The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win (Amazon)
  • The Unicorn Project: A Novel about Developers, Digital Disruption, and Thriving in the Age of Data (Amazon)
  • Kubernetes Failure Stories (

Tip of the Week

  • Press SHIFT twice to search everywhere in your IntelliJ project: Search for a target by name (Search everywhere) (JetBrains)
  • Use ALT+F1 in Datagrip to see available options for a schema object such as navigating to it in the left pane.

Jul 06 2020

1hr 50mins


Survey Says … 2020 Stack Overflow Developer Survey

Podcast cover
Read more

We review the Stack Overflow Developer Survey in the same year it was created for the first time ever, while Joe has surprising news about the Hanson Brothers, Allen doesn’t have a thought process, and Michael’s callback is ruined.

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


Survey Says

Anonymous VoteSign in with Wordpress
How do you feel about semi-colons?
  • Sadly, they're a necessary evil for my language.
  • My language doesn't require them and I'm a better dev for it.
  • There's only a finite number of keystrokes you'll type in your lifetime, and since they're optional in my language of choice, I'm not wasting keystrokes.
  • They might be optional but as a wise man once said: Never Gonna Give You Up.


  • Thank you, we appreciate the latest reviews:
    • iTunes: Akma12345678843225, Rdudek101, SuperGoodDave, vis_1, Asaurus Rex, Brainswart, pr0ph3t, JoesGotTalent, RunsWithScissors
    • Stitcher: TheDude01, barnabasj, oneWithTwoDotsOverTheO, MustardMakerDeluxe, OnlyRaul, _agentShrapnel, yael, d3v3l0p3r, eats_glue
  • Zoom says free users will get end-to-end encryption after all (The Verge)
  • AMD Ryzen 4000-Powered Asus Mini PC Challenges Intel’s NUC (Tom’s Hardware)
  • Joe was a guest on Gaming Fyx!
    • Gaming Fyx – Episode 125! (Cloudy With A Chance Of PS5!!) (

Resources We Like

Tip of the Week

  • Firefox now has their own VPN service: Firefox Private Network. (
  • SDKMAN! The software development kit manager for managing parallel versions of multiple SDKs on most Unix based systems. (
  • What is Scaffolder, and how you can use it to increase your team dev velocity (
  • Fast, repeatable, simple, local Kubernetes development. (

Jun 22 2020

2hr 7mins


Google’s Engineering Practices – How to Navigate a Code Review

Podcast cover
Read more

As we learn from Google about how to navigate a code review, Michael learns to not give out compliments, Joe promises to sing if we get enough new reviews, and Allen introduces a new section to the show.

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


Survey Says

Anonymous VoteSign in with Wordpress
How many hours per week do you work on average?
  • Strictly 40. Work life balance is a must.
  • Less than 40. I value my time.
  • More than 40 but less than 60. Why do I do this to myself?
  • More than 60. Please help me.


  • Thank you, we appreciate the latest reviews:
    • Stitcher: Jean Guillaume Misteli, gitterskow


Navigating a CL in Review

A couple starting questions when reviewing a CL (changelist):

  • Does the change make sense?
  • Does the CL have a good description?

Take a broad view of the CL

  • If the change doesn’t make sense, you need to immediately respond with WHY it shouldn’t be there.
    • Typically if you do this, you should probably also respond with what they should have done.
    • Be courteous.
    • Give a good reason why.
  • If you notice that you’re getting more than a single CL or two that doesn’t belong, you should consider putting together a quick guide to let people know what should be a part of CL’s in a particular area of code
    • This will save a lot of work and frustration.

Examine the main parts of the CL

  • Look at the file with the most changes first as that will typically aid in figuring out the rest of the CL quicker.
    • The smaller changes are usually part of that bigger change.
  • Ask the developer to point you in the right direction.
  • Ask to have the CL split into multiple smaller CL’s
  • If you see a major problem with the CL, you need to send that feedback immediately, maybe even before you look at the rest of the CL.
    • Might be that the rest of the CL isn’t even legit any longer if the major problem ends up being a show stopper.
  • Why’s it so important to review and send out feedback quickly?
    • Developers might be moving onto their next task that built off the CL in review. You want to reduce the amount of wasted effort.
    • Developers have deadlines they have to meet so if there’s a major change that needs to happen, they need to find out about it as soon as possible.

Look at the rest of the CL in an appropriate sequence

  • Looking at files in a meaningful order will help understanding the CL.
    • Reviewing the unit tests first will help with a general understanding of the CL.

Speed of Code Reviews

  • Velocity of the team is more important than the individual.
  • The individual slacking on the review gets other work done, but they slow things down for the team.
    • Looking at the other files in the CL in a meaningful order may help in speed and understanding of the CL.
  • If there are long delays in the process, it encourages rubber stamping.
  • One business day is the maximum to time to respond to a CL.
  • You don’t have to stop your flow immediately though. Wait for a natural break point, like after lunch or a meeting.
  • The primary focus on response time to the CL.
  • When is it okay to LGTM (looks good to me)?
    • The reviewer trusts the developer to address all of the issues raised.
    • The changes are minor.

How to write code review comments

  • Be kind.
  • Explain your reasoning.
  • Balance giving directions with pointing out problems.
  • Encourage simplifications or add comments instead of just complaining about complexity.
  • Courtesy is important.
    • Don’t be accusatory.
    • Don’t say “Why did you…”
    • Say “This could be simpler by…”
  • Explain why things are important.
  • It’s the developer’s responsibility to fix the code, not the reviewer’s. It’s sufficient to state the problem.
  • Code review comments should either be conveyed in code or code comments. Pull request comments aren’t easily searchable.

Handling pushback in code reviews

  • When the developer disagrees, consider if they’re right. They are probably closer to the code than you.
  • If you believe the CL improves things, then don’t give up.
  • Stay polite.
  • People tend to get more upset about the tone of comments, rather than the reviewers insistence on quality.
  • The longer you wait to clean-up, the less likely the clean-up is to happen. Better to block the request up front then move on.
  • Having a standard to point to clears up a lot of disputes.
  • Change takes time, people will adjust.

Resources We Like

Tip of the Week

  • Build your own Pi-hole for network-wide ad blocking (
    • Joe’s Pi-picks:
      • Vilros Raspberry Pi 4 4GB Complete Kit with Clear Transparent Fan Cooled Case – $99.99 (Amazon)
      • Ubiquiti Networks EdgeRouter 12 – $228.99 (Amazon)
      • GeeekPi New Raspberry Pi Cluster Case – $39.99 (Amazon)
    • uBlock Origin – Browser based plug-in for content-filtering, including ad-blocking. (Wikipedia)
  • FREE (!!!) O’Reilly site reliability engineering books made available by Google. (
  • Remove *all* background noise with your NVIDIA RTX card, using NVIDIA RTX Voice (
  • scoop – A command-line installer for Windows. (
  • kubefwd – Kubernetes bulk service port-forwarding (

Jun 08 2020

1hr 42mins


Google’s Engineering Practices – What to Look for in a Code Review

Podcast cover
Read more

We learn what to look for in a code review while reviewing Google’s engineering practices documentation as Michael relates patterns to choo-choos, Joe has a “weird voice”, and Allen has a new favorite portion of the show.

Are you reading this via your podcast player? You can find this episode’s full show notes at where you can also join the conversation.


Survey Says

Anonymous VoteSign in with Wordpress
How likely are you to advocate for working from home in the future?
  • After this pandemic? Every. Opportunity. I. Get.
  • After this pandemic? Never.
  • Work from home? Is that even an option?


  • Thank you to everyone that left us a review:
    • iTunes: codewith_himanshu, SpaceDuckets, akirakinski
    • Stitcher: Anonymous (from Croatia), Llanfairpwllgwyngyll (Wikipedia), Murali Suriar
  • Watch Joe solve LeetCode Problems (YouTube)
Regarding the OWNERs file …

// TODO: Insert Clever Subtitle Here


  • This is the MOST IMPORTANT part of the review: the overall design of the changelist (CL).
  • Does the code make sense?
  • Does it belong in the codebase or in a library?
  • Does it meld well with the rest of the system?
  • Is it the right time to add it to the code base?


  • Does the CL do what it’s supposed to do?
  • Even if it does what it’s supposed to do, is it a good change for the users, both developers and actual end-users?
  • As a reviewer, you should be thinking about all the edge-cases, concurrency issues, and generally just trying to see if any bugs arise just looking at the code.
  • As a reviewer, you can verify the CL if you’d like, or have the developer walk you through the changes (the actual implemented changes rather than just slogging through code).
  • Google specifically calls out parallel programming types of issues that are hard to reason about (even when debugging) especially when it comes to deadlocks and similar types of situations.


  • This should be checked at every level of the change:
    • Single lines of code,
    • Functions, and
    • Classes
  • Too complex is code that is not easy to understand just looking at the code. Code like this will potentially introduce bugs as developers need to change it in the future.

A particular type of complexity is over-engineering, where developers have made the code more generic than it needs to be, or added functionality that isn’t presently needed by the system. Reviewers should be especially vigilant about over-engineering. Encourage developers to solve the problem they know needs to be solved now, not the problem that the developer speculates might need to be solved in the future. The future problem should be solved once it arrives and you can see its actual shape and requirements in the physical universe.

Google’s Engineering Practices documentation


  • Usually tests should be added in the same CL as the change, unless the CL is for an emergency.
  • Make sure the tests are correct and useful.
  • Will the tests fail if the code is broken?
  • Are the assertions simple and useful?
  • Are the tests separated appropriately into different test methods?


  • Were good names chosen?
    • A good name is long enough to be useful and not too long to be hard to read,


  • Were the comments clear and understandable, in English?
  • Were the comments necessary?
    • They should explain WHY code exists and NOT what it’s doing.
    • If the code isn’t clear enough on its own, it should be refactored.
      • Exceptions to the rule can include regular expressions and complex algorithms.
  • Comments are different than documentation of code. Code documentation expresses the purpose, usage and behavior of that code.


  • Have a style guide. Google has one for most of the languages they use.
  • Make sure the CL follows the style guide.
  • If something isn’t in the style guide, and as the reviewer you want to comment on the CL to make a point about style, prefix your comment with “Nit”.
    • DO NOT BLOCK PR’s based on personal style preference!
  • Style changes should not be mixed in with “real” changes. Those should be a separate CL.


  • Google indicates that if existing code conflicts with the style guide, the style guide wins.
  • If the style guide is a recommendation rather than a hard requirement, it’s a judgement call on whether to follow the guide or existing code.
  • If no style guide applies, the CL should remain consistent with existing code.
  • Use TODO statements for cleaning up existing code if outside the scope of the CL.


  • If the CL changes any significant portion of builds, interactions, tests, etc., then appropriate README’s, reference docs, etc. should be updated.
  • If the CL deprecates portions of the documentation, that should also likely be removed.

Every Line

  • Look over every line of non-generated, human written code.
  • You need to at least understand what the code is doing.
  • If you’re having a hard time examining the code in a timely fashion, you may want to ask the developer to walk you through it.
    • If you can’t understand it, it’s very likely future developers won’t either, so getting clarification is good for everyone.
  • If you don’t feel qualified to be the only reviewer, make sure someone else reviews the CL who is qualified, especially when you’re dealing with sensitive subjects such as security, concurrency, accessibility, internationalization, etc.


  • Sometimes you need to back up to get a bigger view of what’s changing, rather than just looking at the individual lines that changed.
    • Seeing the whole file versus the few lines that were changed might reveal that 5 lines were added to a 200 line method which likely needs to be revisited.
  • Is the CL improving the health of the system?
  • Is the CL complicating the system?
  • Is the CL making the system more tested or less tested?
  • “Don’t accept CLs that degrade the code health of the system.”
    • Most systems become complex through many small changes.

Good Things

  • If you see something good in a CL, let the author know.
  • Many times we focus on mistakes as reviewers, but some positive reinforcement may actually be more valuable.
    • Especially true when mentoring.

Resources We Like

Tip of the Week

  • List of common misconceptions (Wikipedia)
  • The unofficial extension that integrates into VS Code. (
  • Use Dataproc’s Cluster properties to easily update XML settings. (
  • Bonus tip: Include a Dockerfile (or Docker Compose) file with your open source project to help it gain traction.

May 26 2020

1hr 41mins


Google’s Engineering Practices – Code Review Standards

Podcast cover
Read more

We dig into Google’s engineering practices documentation as we learn how to code review while Michael, er, Fives is done with proper nouns, Allen can’t get his pull request approved, and Joe prefers to take the average of his code reviews.

In case you’re reading this via your podcast player, this episode’s full show notes can be found at Be sure to check it out and join the conversation.


Survey Says

Anonymous VoteSign in with Wordpress
Do you *always* include (new or updated) unit tests with your pull requests?
  • Yes, always, of course. I'm not a psychopath.
  • Not with *every* pull request, but more often than not. I mean, what kind of psychopath has the time to do them for *every* pull request?
  • No, I rarely include any tests with my pull requests. My friends think I'm crazy.


  • Thank you to everyone that left us a review:
    • iTunes: Jbarger, Podcast Devourer, Duracce
    • Stitcher: Daemyon C

How to Code Review

Code Review Developer Guide

Q: What is a code review?

A: When someone other than the author of the code examines that code.

Q: But why code review?

A: To ensure high quality standards for code as well as helping ensure more maintainable code.

What should code reviewers look for?

  • Design: Is the code well-designed and appropriate for your system?
  • Functionality: Does the code behave as the author likely intended? Is the way the code behaves good for its users?
  • Complexity: Could the code be made simpler? Would another developer be able to easily understand and use this code when they come across it in the future?
  • Tests: Does the code have correct and well-designed automated tests?
  • Naming: Did the developer choose clear names for variables, classes, methods, etc.?
  • Comments: Are the comments clear and useful?
  • Style: Does the code follow our style guides?
  • Documentation: Did the developer also update relevant documentation?

Picking the Best Reviewers

  • Get the best reviewer you can, someone who can review your code within the appropriate time frame.
    • The best reviewer is the one who can give you the most thorough review.
      • This might or might not be people in the OWNERS file.
      • Different people might need to review different portions of your changes for the same pull request.
    • If the “best” person isn’t available, they should still be CC’d on the change list.

In Person Reviews

  • If you pair-programmed with someone who was the right person for a code review, then the code is considered reviewed.
  • You can also do code reviews where the reviewer asks questions and the coder only speaks when responding to the questions.

How to do a Code Review

The Standard of a Code Review

The purpose of the code review is to make sure code quality is improving over time.

  • There are trade-offs:
    • Developers need to actually be able to complete some tasks.
    • If reviewers are a pain to work with, for example they are overly critical, then folks will be less incentivized to make good improvements or ask for good reviews in the future.
  • It is still the duty of the reviewer to make sure the code is good quality. You don’t want the health of the product or code base to degrade over time.
  • The reviewer has ownership and responsibility over the code they’re reviewing.

Reviewers should favor approving the changes when the code health is improved even if the changes aren’t perfect. There’s no such thing as perfect code, just better code.

  • Reviewers can actually reject a set of changes even if it’s quality code if they feel it doesn’t belong in “their” system.
  • Reviewers should not seek perfection but they should seek constant improvement.
    • This doesn’t mean that reviewers must stay silent. They can point out things in a comment using a prefix such as “Nit”, indicating something that could be better but doesn’t block the overall change request.

Code that worsens the overall quality or health of a system should not be admitted unless it’s under extreme/emergency circumstances.

What constitutes an emergency?

A small change that:

  • Allows a major launch to continue,
  • Fixes a significant production bug impacting users,
  • Addresses a legal issue, or
  • Patches a security hole.
What does not constitute an emergency?
  • You want the change in sooner rather than later.
  • You’ve worked hard on the feature for a long time.
  • The reviewers are away or in another timezone.
  • Because it’s Friday and you want the code merged in before the weekend.
  • A manager says that it has to be merged in today because of a soft deadline.
  • Rolling back causes test failures or breaks the build.

Code reviews can absolutely be used as a tool for mentoring, for example teaching design patterns, explaining algorithms, etc., but if it’s not something that needs to be changed for the PR to be completed, note it as a “Nit” or “Note”.

  • Technical facts and data overrule opinions and/or preferences.
  • The style guide is the authority. If it’s not in the style guide, it should be based on previous coding style already in the code, otherwise it’s personal preference.
  • The reviewer may request the code follow existing patterns in the code base if there isn’t a style guide.
Resolving Conflicts
  • If there are conflicts between the coder and reviewer, they should first attempt to come to a consensus based on the information discussed here as well as what’s in the CL Author’s Guide or the Reviewer Guide.
  • If the conflict remains, it’s probably worth having a face to face to discuss the issues and then make sure notes are taken to put on the code review for future reference and readers.
  • If the conflict still remains, then it’s time to escalate to a team discussion, potentially having a team leader weigh in on the decision.

NEVER let a change sit around just because the reviewer and coder can’t come to an agreement.

Resources We Like

  • Google Engineering Practices Documentation (GitHub)
  • Code Review Developer Guide (GitHub)
  • How to do a code review (GitHub)
  • The Standard of Code Review (GitHub)
  • Emergencies (GitHub)
  • The CL author’s guide to getting through code review (GitHub)
  • Technical Writing Courses (
  • Ruffles Potato Chips, Cheddar and Sour Cream (Amazon)
Flawless Execution

Tip of the Week

  • William Lin’s competitive programming channel (YouTube)
  • Register for the free Microsoft Build digital event, May 19-20. (
  • Apple to host virtual Worldwide Developers Conference beginning June 22 (Apple)
  • Checkstyle helps Java developers adhere to a coding standard. (
    • CheckStyle-IDEA – An IDEA plugin that uses Checkstyle but isn’t officially part of it. (
  • Black – The uncompromising code formatter for Python. (

May 11 2020

1hr 39mins


Big Data – How Far is Too Far?

Podcast cover
Read more

We gather around the water cooler at 6 foot distances as Michael and Joe aren’t sure what they streamed, we finally learn who has the best fries, at least in the US, and Allen doesn’t understand evenly distributing your condiments.

For those reading this via their podcast player, this episode’s full show notes can be found at Stop by and join in on the conversation.

Survey Says

Anonymous VoteSign in with Wordpress
Are you staying sane during these stay-at-home orders?
  • Yes. Or so the voices tell me.
  • No. But was I ever sane?


  • We really appreciate the latest reviews, so thank you!
    • iTunes: Braver1996summer, eleneshector, Dis14Joe
    • Stitcher: Nik P, Anonymous, Please HelP, Dis14Joe, thephdwasamistake
  • Be on the lookout for live streams of Joe on YouTube or Twitch!

Heard Around the Water Cooler

  • COVID-19 Pushes Up Internet Use 70% And Streaming More Than 12%, First Figures Reveal (Forbes)
  • Security at Zoom (Zoom)
  • Joe has been busy live streaming (YouTube)
    • Come learn Apache Drill with us! (YouTube)
  • Cmder – Portable console emulator for Windows.
    • We’re still learning the keyboard shortcuts.
  • 30-Day LeetCoding Challenge (
  • Coding Interview Tips, How to get better at technical interviews without practicing (
True descriptions of languages (Reddit)

Tip of the Week

  • Interested in COBOL, game development, and Dvorak keyboards? Check out Joe’s new favorite streamer Zorchenhimer. (Twitch)
  • Using helm uninstall doesn’t remove persistent volumes nor their claims.
    • After doing helm uninstall RELEASE_NAME, delete the persistent volume claim using kubectl delete pvc PVC_NAME to remove the claim, which depending on the storage class and reclaim policy, will also remove the persistent volume. Otherwise, you’d need to manually remove the persistent volume using kubectl delete pv PV-NAME.
  • kafkacat – A generic non-JVM producer and consumer for Apache Kafka. (GitHub)

Apr 27 2020

1hr 51mins


Designing Data-Intensive Applications – To B-Tree or not to B-Tree

Podcast cover
Read more

We dig into the details of how databases use B-trees as we continue our discussion of Designing Data-Intensive Applications while Michael’s description of median is awful, live streaming isn’t for Allen, and Joe really wants to bring us back from the break.

For those reading this via their podcast player, this episode’s full show notes can be found at in all their glory. Check it out, as Joe would say, and join the conversation.


  • – Sign up today for a free 14 day trial and get a free Datadog t-shirt after install the agent.

Survey Says

Anonymous VoteSign in with Wordpress
What tools are you using to ease WFH?
  • RDP
  • VPN
  • Citrix
  • Zoom
  • Skype
  • Slack
  • Webex
  • Hangouts
  • Teams
  • Discord
  • Pidgin
  • Jitsi
  • Messages
  • FaceTime
  • GoToMyPC


  • We really appreciate the latest reviews, so thank you!
    • iTunes: Anips79, Jacobboyd23, LoadedGalaxy, JenT Avid Listener
  • Pluralsight is free for the month of April! (Pluralsight)
  • TechSmith is offering Snagit and Video Review for free through June 2020. (TechSmith)
  • Remember when we gushed over Zoom?
    • Zoom: Every security issue uncovered in the video chat app (CNET)
    • Zoom Go Boom (TWiT)
  • Maybe should use Jitsi instead of Zoom. (Jitsi)
  • Be on the lookout for live streams of Joe on YouTube or Twitch!

B-Trees are Awesome

  • B-trees are the most commonly used indexing structure.
  • Introduced in 1970, and called ubiquitous 10 years later.
  • They are the implementation used by most relational database systems, as well as a number of non-relational DB’s.
  • “Indexing” is the way databases store metadata about your data to make quick look ups.
  • Like the SSTable, the B-tree stores key/value pairs sorted by key. This makes range query look ups quick.
  • B-trees use fixed block sizes, referred to as pages, that are usually 4 KB in size which (generally) map well to the underlying hardware because disks are typically arranged in fixed block sizes.
  • Every page has an address that can be referenced from other pages. These are pointers to positions on a disk.
  • Knowing (or being able to quickly find) which page the data you are looking for is in, drastically cuts down on the amount of data you have to scan through.
  • B-trees start with a root page. All key searches start here.
    • This root will contain references to child pages based off of key ranges.
    • The child pages might contain more references to other child pages based off of more narrowly focused key ranges.
    • This continues until you reach the page that has the data for the key you searched for.
      • These pages are called leaf pages, where the values live along with the key.
  • The branching factor is the number of references to child pages in one page of a B-tree.
    • The branching factor is tied to the space needed to store the page references and the range boundaries.
      • The book states that it’s common to have a branching factor of several hundred, some even say low thousands!
    • The higher the branching factor means the fewer levels you have to go through, i.e. less pages you have to scan, when looking for your data.
  • Updating a value in a B-tree can be complicated.
    • You search for the leaf node containing the key and then update the value and write it to disk.
      • Assuming everything fits in the page, then none of the upstream references change and everything is still valid.
    • If you are inserting a new key, you find the leaf node where the key should live based on the ranges and then you add the key and value there.
      • Again, if everything fits in the page, then similar to the update, none of the upstream references need to change.
      • However, if the key/value would exceed the size of the page, the page is split into two half-pages, and the parent page’s references are updated to point to the new pages.
        • This update to the parent page might require it to also be split.
        • And this update/split pattern might continue up to and including the root page.
  • By splitting the pages into halves as data is added that exceeds the page size, this keeps the tree balanced.
  • A balanced tree is the secret to consistent lookup times.
  • It terms of big-O, a B-tree with n keys has a depth of O(log n).
  • Most DB’s only go 3 to 4 levels deep.
    • A tree with four levels, using a 4 KB page size, and a branching factor of 500 can store up to 256 TB!

Making B-Trees Reliable

  • The main notion is that writes in a B-tree occur in the same location as the original page, that way no references have to change, assuming the page size isn’t exceeded.
    • Think of this as a hardware operation.
      • These actually map to spinning drives better than SSD’s. SSD’s must rewrite large blocks of a storage chip at a time.
  • Because some operations require multiple pages to be written, in the case of splitting full pages and updating the parent, it can be dangerous because if there is a DB crash at any point during the writing of the pages, you can end up with orphaned pages.
    • To combat this, implementations usually include a write-ahead log (WAL, aka a redo log).
      • This is an append-only file where all modifications go before the tree is updated.
      • If the database crashes, this file is read first and used to put the DB back in a good, consistent state.
  • Another issue is that of concurrency.
    • Multiple threads reading and writing to the B-tree at the same time could read things that would be in an inconsistent state.
      • In order to counter this problem, latches, or lightweight locks, are typically used.

B-Tree Optimizations

  • Some databases use a copy-on-write scheme. This alleviates the need to write to an append only log like previously mentioned and instead you write each updated page to a new location including updated parents that point to it.
  • In some cases, abbreviated keys can be stored which saves space and would allow for more branching but fewer node levels, which is fewer hops to get to the leaf nodes.
    • This is technically a B+ tree.
  • Some implementations attempt to keep leaf pages next to each other in sequential order which would improve the seek speed to the data.
  • Some implementations keep additional pointers, such as references to the previous and next sibling pages so it’s quicker to scan without having to go back to the parent to find the pointer to those same nodes.
  • Variants like fractal trees, use tactics from log-structured ideas to reduce disk seeks.

Comparing B-Trees and LSM-Trees

  • B-trees are much more common and mature. We’ve ironed out the kinks and we understand the ways people use RDBMSes.
  • LSM-trees are typically faster for writes.
  • B-trees are typically faster for reads because LSM-trees have to check multiple data-structures, including SSTables that might be at different levels of compaction.
  • Use cases vary, so benchmarking your use cases are important.

LSM-Tree Advantages

  • The write amplification problem:
    • B-trees must write all data at least twice, once to the WAL and another to the page (and again if pages are split). Some storage engines go even further for redundancy.
    • LSM-trees also rewrite data, due to compaction and tree/SSTable merging.
      • This is particularly a problem for SSDs, which don’t do so well with repeated writes to the same segment.
    • LSM-trees typically have better sustained write throughput because they have lower write amplification and because of they generally sequentially write the SSTable files, which is particularly important on HDDs.
  • LSM-trees can be compressed better, and involve less space on disk.
  • LSM-trees also have lower fragmentation on writes.

LSM-Tree Downsides

  • Compaction of the SSTables can affect performance, even though the compaction can happen in another thread, because takes up disk I/O resources, i.e. the disk has a finite amount of I/O bandwidth.
  • It’s possible that the compaction can not be keep up with incoming events, causing you to run out of disk space, which also slows down reads as more SSTable files need to be read.
    • This problem is magnified in a LSM-tree because a key can exist multiple times (before compaction) unlike B-trees which have just one location for a given key.
  • The B-tree method for updating also makes it easier for B-trees to guarantee transactional isolation.

Resources We Like

  • Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems by Martin Kleppmann (Amazon)
  • Data Structures – (some) Trees (episode 97)
  • B-Tree Visualization (USFCA)
  • SQL Server Transaction Log Architecture and Management Guide (
  • Log-structured merge-tree (Wikipedia)
  • Postgres Indexes Under the Hood (
  • Is Docker the new Git? (Coding Blocks)

Tip of the Week

  • Chocolatey adds a PowerShell command Update-SessionEnvironment or refreshenv for short, that you can use to update the environment variables in your current PowerShell session, much like . $HOME/.profile for MacOS/Linux. (Chocolatey)
  • Use docker stats to monitor the usage of your running Docker containers. It’s like top for Docker. (Docker)
  • Click the Equivalent REST or command line link at the bottom of the Google Cloud Console to get the equivalent as a command you can script and iterate on.
  • Jupyter has a Docker image for you: Jupyter Docker Stats. (
  • Apache Drill is an amazing schema-free SQL query engine for Hadoop, NoSQL, and Cloud Storage. (
  • Presto, aka Presto DB, not to be confused with Presto SQL, is distributed SQL query engine for big data originally developed by Facebook. (

Apr 13 2020

1hr 56mins


How to Work Remote Effectively

Podcast cover
Read more

Since we can’t leave the house, we discuss what it takes to effectively work remote while Allen’s frail body requires an ergonomic keyboard, Joe finally takes a passionate stance, and Michael tells them why they’re wrong.

Reading these show notes via your podcast player? You can find this episode’s full show notes at and be a part of the conversation.


Survey Says

Anonymous VoteSign in with Wordpress
What's your preferred method to increase your productivity?
  • Code to music in the background. Is that freedom rock? Well turn it up man ...
  • Absolute silence. Except for that annoying buzz coming from my UPS. And monitor. And LEDs.
  • Netflix and code. That's a thing, right?
  • Treadmill or Bike desk. Tone my brain and my glutes.
  • Pomodoro. I live my life one quarter hour at a time.
  • Pajamas. All. Day. Long.
  • Take a break. Go for a walk. Eat lunch. Anything to reboot.


  • Thank you, krauseling, for the latest iTunes review.
  • TechSmith is offering Snagit and Video Review for free through June 2020. (TechSmith)

How to WFH

The Essentials

  • First and foremost, get a quality internet connection.
    • For video calls, favor lower latency over higher bandwidth.
  • Turn your camera on.
  • Use a comfortable headset with a good microphone
    • Wired headphones are definitely the way to go. Better audio quality, fewer problems, and no battery life issues to worry about.
  • Mute unless talking.
  • Not all video sharing is equal. Know which to use when screen sharing.
    • Screen sharing in Zoom is much better than in Hangouts. The text on the screen is crisp and readable and the screen sharing session is responsive.
  • Communicate when you will be away during normal hours.
  • Make sure your IM application status and/or availability is accurate.

Sound Good

PriceDescription$30Sony MDRXB50AP Extra Bass Earbuds Headset with mic (Amazon)$149SteelSeries Arctis 7 Gaming Headphones (Amazon)$18Apple EarPods with 3.5mm Headphone Plug (Amazon)
Avoid these headphones
DescriptionPriceSennheiser SC 130 USB Single Sided Headset (Amazon)NASennheiser SC 160 USB Double-Sided Headset (Amazon)$65

Look Good, too

PriceDescriptionNA Logitech c930e WebCam (Amazon)

Digging Deeper

  • Don’t be afraid to spend time on calls just chatting about non work related stuff.
    • Working from home means there’s little opportunity to connect personally and that is sorely needed when working from home. Taking time to chat will help to keep the team connected.
    • Keep it light and have fun!
  • Be available and over communicate.
    • During business hours make sure you’re available. That doesn’t mean you need to be in front of your computer constantly, but it does mean to make sure you can be reached via phone, email, or chat and can participate when needed.
    • Working from home also means it is super important to communicate status and make sure people feel like progress is being made.
    • Also, if you need to be offline for any reason, send up a flare, don’t just disappear.
    • Make sure your chat application status is really your status. People will rely on you showing “Active” meaning that you are available. Don’t game your status. Take a break if you need to but if you aren’t available, don’t show available. Also, if you don’t show “Active” many will assume that you aren’t available or online.
    • We’ve also found that sometimes it is good to show “offline” or “unavailable” to give us a chance to get into a flow and get things done, so don’t be afraid to do that. Having this be a “known agreement” will signal to others that they may just want to send you an e-mail or schedule a conference later.
    • If something is urgent in email, make sure to send the subject with a prefix of “URGENT:”
      • But beware the an “urgent” email doesn’t mean you’ll get an instant reply. If you need an answer right now, consider a phone call.
      • An “urgent” email should be treated as “as soon as you read this”, knowing that it might not be read for a while.
    • Make sure your calendar is up to date. If you are busy or out of the office (OOO) then make sure you schedule that in your calendar so that people will know when they can meet with you.
    • Along with the above, when scheduling meetings, check the availability of your attendees.
  • Be flexible.
    • This goes with things mentioned above. As a manager especially, you need to be flexible and recognize that working from home sometimes means people need to be away for periods of time for personal reasons. Don’t sweat that unless these people aren’t delivering per the next point.
    • Favor shorter milestones or deliverables and an iterative approach.
      • This helps keep people focused and results oriented. Science projects are easy to squash if you define short milestones that provide quick wins on the way to a longer term goal.
        • We use the term “fail fast” a lot where we break projects into smaller bits and try to attack what’s scariest first in an effort to “fail fast” and change course.
      • We use JIRA and work in 2 week sprints.
        • Define work in small enough increments. If something exceeds two weeks, it means it needs to be reviewed and refined into smaller work streams. Spend the time to think through it.
    • Require estimates on work items to help keep thing on track.
  • Allow and encourage people to work in groups or teams if appropriate, for things like:
    • Brainstorming sessions.
    • Mini-scrums that are feature or project based.
    • Pair programming. Use of the proper video application for screen sharing is important here.
  • Conference etiquette:
    • Mute. If you’re not talking, mute.
      • Lots of participants? Mute.
      • Smaller/Team meeting? Up to you. But probably best to mute.
    • Use a microphone and verify people hear you okay. Don’t forgo a real headset or microphone and instead try to use your internal laptop microphone and speakers. You will either be super loud with background noise, for example people just hear you typing the whole time or hear your fan running, or people won’t hear you at all.
    • When you start presenting, it is a good practice to ask “can you see my screen?”
    • Give others opportunities to talk and if someone hasn’t said anything, mention it and ask for their feedback especially if you think their opinion is important on the subject at hand.
  • Use a tool to help you focus.
    • It is easy to get distracted by any number of things.
    • A technique that works well for some is the Pomodoro Technique. There’s also nifty applications and timers that you can use to reinforce it.
  • Music may not be the answer.
    • For some people just putting on noise-cancelling headphones helps with external noise (kids, TV, etc.)
  • Choose the right desktop sharing tool when needed.
    • We’ve found that Hangouts is a great tool to meet quickly and while it does provide for screen sharing, the video quality isn’t great. It does not allow people who are viewing your screen to zoom in and if you have a very high resolution monitor, people may find it hard to read/see it.
    • While Webex is a little more challenging to use, it does provide the ability for others to zoom in when you share, and the shared screens are more clear than Hangouts.
    • Additionally, Webex allows you to view all participants in one gallery view, thus reinforcing team cohesion.
    • That said though, we’ve found Zoom to be far superior to it’s competitors.
  • Develop a routine.
    • Get up and start working at roughly the same time if you can.
    • Shower and dress as if you’re going out for errands at least.
    • If possible, have a dedicated workspace.
    • Most importantly, make sure you stop work at some point and just be home. If at all possible, coupled with the dedicated workspace tip, if you can have a physical barrier, such as a door, use it, i.e close the door and “be home” and not “at work”.
    • It’s hard not to overeat at first, but try to avoid the pantry that is probably really close to your workspace.
    • Try to get out of the house for exercise or errands in the middle of day to break things up.
    • Working from home is much more sedentary than working in an office. Make it a point to get up from your desk and walk around, check the mail, do whatever you can to stretch your legs.

Resources We Like

Tip of the Week

  • Unity Learn is free for 3 months! (
  • Use GitHub Learning Lab to grow your skills (
  • VS Code Remote Development allows you to use a container, remote machine, or WSL as a full-featured development environment. (
    • You’ll need the Remote Development extension pack from the marketplace.

Amateur tip: need to kick a build? Gonna squash anyway? Use –allow-empty to do a commit with no files added or actual changes.

— Nick Craver (@Nick_Craver) March 21, 2020

Need to take a break from Netflix before you binge-watch the entire library? Introducing our brand new concert series: #MetallicaMondays, debuting tonight on our YouTube channel and on Facebook!

Tune in at 8 PM EDT to watch Metallica: Live at Slane Castle – June 8, 2019!

— Metallica (@Metallica) March 23, 2020

Mar 30 2020

2hr 10mins


Designing Data-Intensive Applications – SSTables and LSM-Trees

Podcast cover
Read more
It's time to learn about SSTables and LSM-Trees as Joe feels pretty zacked, Michael clarifies what he was looking forward to, and Allen has opinions about Dr Who.

Mar 16 2020

1hr 38mins


Designing Data-Intensive Applications – Storage and Retrieval

Podcast cover
Read more
In this episode, Allen is back, Joe knows his maff, and Michael brings the jokes, all that and more as we discuss the internals of how databases store and retrieve the data we save as we continue our deep dive into Designing Data-Intensive Applications.

Mar 02 2020

2hr 15mins


Why Attend Developer Conferences and What were the Hot Topics at NDC London 2020?

Podcast cover
Read more
Jamie from and Allen, ya know, from Coding Blocks, sat down together at NDC London to talk about the hot topics from the conference as well as how to get the most out of any conference you attend. If you’re reading this episodes show notes via your podcast player, you can find this episode’s […]

Feb 17 2020

1hr 16mins


Designing Data-Intensive Applications – Data Models: Query Languages

Podcast cover
Read more
We dive into declarative vs imperative query languages as we continue to dive into Designing Data-Intensive Applications while Allen is gallivanting around London, Michael had a bullish opinion, and Joe might not know about The Witcher.

Feb 03 2020

1hr 38mins


Designing Data-Intensive Applications – Data Models: Relationships

Podcast cover
Read more
While we continue to dig into Designing Data-Intensive Applications, we take a step back to discuss data models and relationships as Michael covers all of his bases, Allen has a survey answer just for him, and Joe really didn't get his tip from Reddit.

Jan 20 2020

2hr 14mins


Designing Data-Intensive Applications – Data Models: Relational vs Document

Podcast cover
Read more
We're comparing data models as we continue our deep dive into Designing Data-Intensive Applications as Coach Joe is ready to teach some basketball, Michael can't pronounce 6NF, and Allen measured some geodesic distances just this morning.

Jan 06 2020

1hr 53mins


Designing Data-Intensive Applications – Maintainability

Podcast cover
Read more
We dig into what it takes to make a maintainable application as we continue to learn from Designing Data-Intensive Applications, as Allen is a big fan of baby Yoda, Michael's index isn't corrupt, and Joe has some latency issues.

Dec 23 2019

2hr 6mins


Designing Data-Intensive Applications – Scalability

Podcast cover
Read more
We continue to study the teachings of Designing Data-Intensive Applications, while Michael's favorite book series might be the Twilight series, Joe blames his squeak toy chewing habit on his dogs, and Allen might be a Belieber.

Dec 09 2019

1hr 52mins


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.

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.

Nov 12 2019

2hr 32mins


iTunes Ratings

736 Ratings
Average Ratings


By akirakinski - May 22 2020
Read more
Thanks to these guys my blocks are THOROUGHLY coded. The only podcast I listen to at 1X speed. Some of my favorite nerds and ain’t sure they’ll be yours too.

Grocery store

By index out of range - Mar 08 2020
Read more
This podcast is like a big American grocery store that sells developer centric “food for thought”.