I've worked with engineers who can happily write greenfield code that passes the spec, but fails on any inputs that are not clearly defined as valid. In an effo

I've worked with engineers who can happily write greenfield code that passes the spec, but fails on any inputs that are not clearly defined as valid. In an effort to fix this, they add layers and layers and layers of complexity and edge cases to the app logic, and intermix the actual app logic with handling invalid input. something like func isEven(s string) bool { num, _ := strconv.Atoi(s) return num % 2 == 0 } becomes: func isEven(s string) (string, error) { f, err := strconv.ParseFloat(s, 64) if err != nil { return "invalid", err } num := int(f) if num%2 == 0 { return "even", nil } else if num % 2 != 0 { return "odd", nil } return "invalid", nil } Which is.... technically correct, instead of func isEven(num int) bool { return num % 2 == 0 } func isEvenSafe(s string) (bool, error) { num, err := strconv.Atoi(s) if err != nil { return false, err } return isEven(num), nil }