| .. | ||
| day1 | ||
| day2 | ||
| day3 | ||
| day4 | ||
| day5 | ||
| day6 | ||
| day7 | ||
| day8 | ||
| day9 | ||
| day10 | ||
| day11 | ||
| day12 | ||
| day13 | ||
| day14 | ||
| day15 | ||
| day16 | ||
| day17 | ||
| day18 | ||
| day21 | ||
| day23 | ||
| day24 | ||
| day25 | ||
| README.md | ||
AdventOfCode2020
My (attempted) solutions to Advent of Code 2020 in Elixir.
Strategy
If this year is like 2018, the last time I did this, each problem will be split into two parts. The second part can result in considerable refactoring of the first part, so I will split each part into its own file, like this:
day1/day1part1.exs- solution to part 1day1part2.exs- solution to part 2README- my summary and notes relating to the day's probleminput- input file downloaded from Advent of Code (if applicable)
If I get stuck, my instinct is to be persistent and take as long as it takes to solve the problem. However I think this year I don't want the pressure of days piling up and this is supposed to be fun, so I will probably limit each problem to one day, and then come back to those that I had problems with later.
No checking other people's solutions until I've solved it myself - or otherwise given up. If I make any refinements as a result of seeing other people's solutions or reading forums, etc., I will commit them to a separate file to leave the original version in tact.