Advent of Code day 16: Curses!

I knew it had to come someday: those puzzles where you run around on a character-based grid. Day 15 was one of those. I’m definitely not one of those people who just pull maze traversal algorithms out of thin air, and to learn them I read an overview of the algorithm and then try to implement is. And then start with the headache of why things aren’t working, or your robot just walks up and down along 2 coordinates, etc. etc.

Read more →

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 (, 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)

    # 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?

Dealing with emergencies in Agile teams

Every Agile team has to deal with whatever they’ve put out in the wild next to their “regular” work. How to handle the – by definition – unknown load of production emergencies when you’re trying to achieve a stable pace? You can deal with emergencies by performing triage to either reject, defer or accept. You can set up a buffer to absorb some of the uncertainty, and finally you should make sure that you take the time to reduce the number of emergencies by building quality in. If you find you are mostly doing maintenance, you can consider doing Kanban.
Read more →

Fixing the Cause-Effect Trap in User Stories

If you write user stories, it is very likely that you have been using the “As a… I want… So That…” stanza. What you might also have found is that it is hard to fill the “So That” clause with something that makes sense. “As A User I Want a button So That I can go to the next screen”… that is pretty naff, isn’t it? So how do you fix it? Ask “Why” several times!
Read more →

“Committing” to a Sprint and failing is a GOOD thing!

What does it mean when a Scrum team “commits to a Sprint”? There is a subtlety in the English language that leads to misinterpretation and misuse of the verb “to commit”. I have seen too many cases where a team is held accountable (“bad team, bad!”) because they did not achieve their Sprint goal in some way. And it will be accompanied by the accusation: “…but you committed to the Sprint, didn’t you?”. As a coach, this is the moment I step in to explain what “to commit” really means, and that you want to fail every now and then: succeeding every time is a failure mode all of its own.
Read more →

The READY Kanban: the Product Owners’ Scrum Board

In my previous posts about the definition of READY and Flow to Ready, Iterate to Done I have tried to shed some light on the Big Black Hole of Scrum: the Product Owner. This is number three in the series.

In my previous blog post I presented the stages that a backlog item flows through before it gets to Ready. But those were the ideas behind it: in this blog post I’ll show how I’ve implemented them in practice. I’ll show you two interesting examples.

Read more →