Advent of Code Day 7: share your workflow

As we’re getting into the flow of things again, I notice that there’s a rhythm to approaching a puzzle that is just as much a part of solving a puzzle neatly and efficiently as the puzzle itself. Here’s my workflow, what’s yours?

I start by creating two files: a .py file with the template shown below (AoC-2019-7.py), and an empty text file for the puzzle (AoC-2019-input-7.txt). Then I start reading the puzzle. By the time I get to the puzzle input link, I can then just Ctrl+A Ctrl+V the data into the input file.

#!/usr/bin/env python3
"""Solution for Advent of Code challenge 2019 - Day X"""
__author__ = "Serge Beaumont"
__date__ = "December 2019"
def load_input(day):
    with open(f"AoC-2019-input-{day}.txt") as infile:
        return [[int(y) for y in x.split(',')] for x in infile.readlines()]
def do(data):
    return False
if __name__ == '__main__':
    # Run tests
    # assert do(XXX) == YYY
    # Load data
    data = load_input(0)
    print(data)
    # Solve puzzle
    result = do(data)
    # Output
    print(f"Part 1: {result}")

The very first thing is to make sure that the data loads correctly. The print(data) statement in the .py file is there for that specific purpose: I tend to remove it later. Based on the need I might need to split lines, strip whitespace, and split data into tuples. The template above shows one of the more involved versions: read all lines, split along comma boundaries, and convert all numbers to ints. Come to think of it, this year hasn’t been so regex heavy as other years – so far…

The next step is to copy all the examples into assert do(example input) == expected output lines. There are two things that are important to me in my testing approach:

• having all the examples execute before the actual puzzle: by the time all tests run the actual puzzle tends to execute cleanly, which is a big time saver when processing takes a longer time, and
• using a do() function so the puzzle can be transparently called either from a test or with the actual puzzle data.

When I try a solution on the puzzle page and it’s wrong, you get a page with some information, sometimes even if the answer was to high or too low. I add these as assert statements at the end of the file.

When I solve part 1 correctly, I first read Part 2 before I decide if I integrate the solution of Part 2 into the Part 1 code, or if I use a separate .py file.

This year I even split out the full IntCode computer in its own library. I’ve seen people complain about having that computer in there for three days, but I’m curious to see what Eric The Puzzle Master Wastl has up his sleeve. What I like about the three days of IntCode computer is that it has allowed/forced me to refactor the code, which is an interesting change to the throwaway code you can write if it’s only for a single day…

If there’s anything else that’s consistent in my approach it’s my timing of shower and breakfast. I intentionally read the puzzle before shower and breakfast, try at a solution, and then force myself to my daily routine. I’ve found it helps me a lot if I mull over the puzzle for a bit while I’m not staring at the screen. I think 80% of my breakthroughs are during that “away time”.

That’s my approach. What’s yours?