I know: I shouldn't write for public audience about programming, software architecture or -design. I also should not write about principles or concepts.
The reason for that: I am dumb. I am not perfect at all. And I know most people are way smarter than I am.
But I am going to do it, because I am convinced that it important to build and fail in public.
Build, fail, solve, delete, repeat
When I got in contact with my first lines of code, I did not know anything about computers. I was a kid and I wanted to solve an issue:
My computer, a modern system with mind-blowing 64M of memory, got stuck without any obvious reason. I found out that a program was using more and more memory over time until the OS, Microsoft Windows 98, resigned and just freezed.
Sometimes, I was able to kill the causing process, preventing the OS from freezing. And this was what I wanted to automate. Not the best idea, right? Wait for the next move.
As I did not have access to the internet, I went to the local book store and asked for a book that will teach me how to program. The only available book was about C++.
Well. Being 13 years old, learning C++ is not the first language that comes to mind. And of course I failed hard. I was able to create a piece of software that got the job done. But the purpose of the program was, this is what I learned, not worth it.
The important thing I gathered from this: I got an idea about a language, I learned that I had to start with a better suited entry point to get into programming and I learned more about operating systems and how they manage resources.
I also learned that it is ok to do a crappy job. As long as you admit that that was a crappy job and learn from it.
This is the one thing people I interacted with in the upcoming decades fail. Being open about the things they do not yet understand. Focus on what is needed to actually understand the problem better in order to get a better approach to a solution.
In my mind, every problem that is getting my attention, should be worth a first attempt. An attempt that is meant to be deleted just by definition. I do not understand the problem. I will try to solve it, knowing that my solution will be temporary. But also knowing that my next attempt will be more elegant, because I learned not to solve the problem. I got an expert about the problem itself in the meantime.
What this approach is good for
In the past, I used this exploration-based approach for a lot of things that seemed scary to me: Event Sourcing is the most prominent example for this. But - Eventsourcing is a great example for this, but I will elaborate on that later - I guarantee that you will become a better programmer, if you can accept the fact that you will eventually fail. Or to put it this way: Sometimes it is okay to suck at programming.
