Approaching work from a standpoint of fun, play, creative, interest. Curiosity. Bit by bit, have an idea, make it. Done. Loop. Growing the interest. Growing the work. Led by play. Just happens. Don’t really need to think about it.

In this next project, a coding project, I want to approach the project the same way. Like making music, just kind of happens. Something that feels right. Something that requires virtually no forced effort. All effort led by positive energy.

Too often in the past I’ve approached projects from a standpoint of, “what grand goal do I want to achieve”, then work backward from there. But the work felt like a burden, because if it didn’t build towards the goal, or if the goal wasn’t attainable, the work was meaningless. The alternate approach, working on something because it’s fun, interesting, satisfying, means there’s meaning in the work regardless. There still needs to be a guiding direction, but not towards some grand goal. Just a direction, saying, go roughly there. And the creative process will drive itself.

The guiding direction is that I don’t enjoy modern software engineering. It sucks. But I know it could be good. Because I like programming. So I’ll work on tiny projects where I try to make something, then I ask myself, how can I enjoy making this? What needs to be done? How does it need to work? Example: databases suck. Object relational models suck. Types are great. Data can exist as types. Data migrations can be versioned. Databases are one large mutable state. State transitions must be defined precisely, else the data will get increasingly chaotic, increase entropy, and become unweildy. Mutable state is fine. It’s OK. Immutability is a myth, because if everything was immutable then data would explode in size. Sometimes we do indeed need to change the data at hand. And when we do so, we need to keep track of its state and state transitions. Another example: properties of data. Data is assumed to have certain properties. Making those properties explicit can save headache.

But all of this should be fun. It should be small. It should be simple. It should be easy, and grow over time.

At first I thought this project would start as something like: simulate a CPU then write a language that compiles to assembly, then check properties of programs in that language by reasoning about the programs using the CPU abstraction. Which, well, maybe one day, sure, that could be done. But I’d hate doing that. It’s very low level, and a ton of work. And it’s too difficult. It’s the opposite of small easy projects.

I think the way this should start is that I take a project from work, one that contains a lot of business logic, and write a dummy version of python (tython) that contains all the features that I actually want. Then rewrite the project in tython. And make it clean, elegant, simple. I should start with what I know. Then go from there. Hopefully it will lead me to figuring out a simple solution to the DevOps work, where arguably most of my annoyance in software engineering can be found.