The Half-Baked Shaman

Just like OpenAI,
in an IT market that updates more than once a day,

programmers (not developers) shouldn't be subordinated to a language,
designers shouldn't be subordinated to a tool,
and product planners shouldn't be subordinated to news.

What they have in common is the frame.

A frame can serve as priming water for some unfamiliar or new act (or thought), but it should never become the specification for the action (or the thought that gives rise to the action).



In the end, it's just a tool. So what? There's no need to tie yourself, or the service you're building, to it as if it were the one and only key.

You should always hold onto the thought of "So what?" or "Whatever." Experience itself is sometimes what makes this all the more dangerous.





If you hear the saying "A half-baked shaman gets people killed," get out of there as fast as you can.

The saying is correct. A half-baked shaman does get people killed. But without going through the half-baked-shaman phase first, no one can ever become a real shaman.
Do you remember the moment you first printed "Hello World"? The half-doubting, half-excited "Wait, this works?! If I work at it a bit more, couldn't I also pull this off?" that's how it starts.
Everyone goes through it at least once. Or becomes the creator of a bug over a mere spacing issue or a simple typo.
Just as we don't call a developer a half-baked shaman for producing a bug.