The good/great line is something you can stumble over and and then fall back from because it's a relative measure that has a zigzag to it, exactly the same as how artists perceive their work vs others. At first you know with some confidence that you're bad, and then you pick up a few tricks and get a swollen head for a while, until one day you notice some great feat that you knew nothing about. Then you are back to being an imposter knowing nothing again.
That repeats over and over, it just becomes more nuanced and specific in some ways and more general in others. You have "good days" and bad ones, and you're often exposed to the really different ideas simply by being "in the room" to engage with them properly on a project instead of skimming over someone's half-assed summary.
The two interesting areas of programming, to me, are at the very bottom of the stack near the hardware, and the very top where there's intensive abstraction and algorithm design. The parts in the middle are quicksand; it's pragmatically useful and productive for a job to know some little corner of C++ or a certain Unix tool or a longstanding bug in a Javascript framework. But that's not "programming" in the broad sense either. Shuffling around stacks of dependencies that have been vendored out for your consumption isn't the good part, and ultimately leads towards becoming what James Hague calls the "recovering programmer":
Part of the bitterness he speaks of comes from the feeling of perpetual consumption: if you're always learning a next "new thing" you never feel like you've built much of your own. So you have to decide for yourself a cut-off line where you will start to DIY more of it, where you won't do things the "standard" way or aim to have a large, publicly visible project or other such demons in your head. At that point you can just program.
That repeats over and over, it just becomes more nuanced and specific in some ways and more general in others. You have "good days" and bad ones, and you're often exposed to the really different ideas simply by being "in the room" to engage with them properly on a project instead of skimming over someone's half-assed summary.
The two interesting areas of programming, to me, are at the very bottom of the stack near the hardware, and the very top where there's intensive abstraction and algorithm design. The parts in the middle are quicksand; it's pragmatically useful and productive for a job to know some little corner of C++ or a certain Unix tool or a longstanding bug in a Javascript framework. But that's not "programming" in the broad sense either. Shuffling around stacks of dependencies that have been vendored out for your consumption isn't the good part, and ultimately leads towards becoming what James Hague calls the "recovering programmer":
https://prog21.dadgum.com/56.html
Part of the bitterness he speaks of comes from the feeling of perpetual consumption: if you're always learning a next "new thing" you never feel like you've built much of your own. So you have to decide for yourself a cut-off line where you will start to DIY more of it, where you won't do things the "standard" way or aim to have a large, publicly visible project or other such demons in your head. At that point you can just program.