Writing algorithms that are 50 lines of code seems like one definition of fluency, and one that is probably relevant in compilers/backend, but this also rings a little hollow to me, in terms of the pragmatics of real software engineering.
In my experience, most software engineering is using libraries, not language features; how would you describe fluency over libraries? Is “glue code” like command-line flags or CRUD web app routing subject to this? Should that code also “just flow”? In my experience truly powerful developers are able to do this, but even many Google L5s will just look up this code every time. Is that “fluent”? Is there a better concept to be applying here other than “fluency”?
My impression is that this is outside the scope of what you’re describing, “implementing algorithms.” This is an important part of software engineering, but I would say it’s not entirely overlapping with what I would call “building <things/tools/products>”. Would you agree? How would you relate these two aspects?
I personally don’t feel “fluent” programming this way, and maybe it is my own perfectionism, but this and the other replies, while certainly understandable and defensible, ring a little more hollow than I would like. I think going down below the level of “just know what APIs broadly exist” and actually being fluent at that lower level is usually necessary for the true 10-100x devs I’ve seen to work at that level. Usually this is achieved by building lots and lots of practical, deployable systems, but this just means it is implicitly taught through experience, and I wonder if there is a better way. Anyway, trying to figure out if it was this popular, but IMO flawed, type of fluency you were referring to was my original question, and I thank you for your answer.