Trying New Ideas

My son was saying today that this project he’s working on works but feels a little fragile. That is, he didn’t spend a lot of time on the architecture. Instead he was trying to see if the idea would work at all. For that reason, the code is mostly the remains of trial and error connected with duct tape and glue.

I realized that this is actually a good thing. When you’re exploring an idea, spending too much time creating an “ecosystem” is a complete waste if you don’t know if the core idea is viable. In fact, it’s not just about viability, it’s about knowing where the pain points are - that is, you don’t really know what needs to be engineered more carefully and what can be deprioritized because you haven’t “lived” with the code long enough.

For example, create an amazing object hierarchy that allows for all sorts of extensibility is not super helpful if there is no need to extend that part of the program. And a lot of times, with things that are new, you really don’t know where the joints are. I mean, you can make some educated guesses, but how much time do you really want to spend on a guess.

It reminded me of the story I’ve heard some comedians tell where in a moment of inspiration they had an idea for a joke that came to them in a dream and was amazing. So they woke up, wrote it down, and went back to sleep. In the morning, they woke up and read what they wrote down and were horrified that they ever thought it was funny.

In a kinda similar we need to jot down our program and come back to it. We need to see if it’s really a good idea or if your mindset at the time was a little off and it just seemed like a good idea at the time. If the comedian woke up in the middle of the night and wrote an entire set instead of just jotting down the highlights, they would have been both tired and profoundly disappointed in the morning.