What I mean is that once they know the algorithm they want, writing that as code just flows, they can write out 50 lines of code that represents the algorithm in 10 minutes, without having to stop to double check what they’re doing after every statement.
Of course their implementation will have bugs, but it will still be approximately correct.
And vice versa, a talented developer can read any reasonably well written code and quickly work out what it’s doing.
It’s really about fluency in a language, like the difference between talking in your first language Vs one you only know from lessons. Writing code is the bread and butter of your job, so if you can’t do it fluently that’s a problem.
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 think the ability to “just look up this code” is a demonstration of fluency—if your way of figuring out “what happens when I invoke this library function” is “read the source code”, that indicates that you are able to fluently read code.
That said, fluently reading code and fluently writing code are somewhat different skills, and the very best developers relative to their toolchain can do both with that toolchain.
In my experience truly powerful developers are able to do this, but even many Google L5s will just look up this code every time.
Indeed I am a Google L5, and I usually do look this stuff up (or ChatGPT it). I think it’s more important to remember roughly what libraries do at a high level (what problems they solve, how they differ from other solutions, what can’t they do) than trivia about how exactly you use them.
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.
You are right that writing code glue code is a large part of software engineering, and that knowing what the libraries do is an important part of that. But once you know (or think you know) what the libraries do, how quickly do you bash out the code that does that? Do you struggle, or does it just come naturally?
And as faul_sname pointed out, often the quickest way to understand what the library does is to look at it. Is that something you’re capable of doing, or are you forced to hope the documentation addresses it?
Other times you want to write a quick test that the library does what you expect. Is that going to take you half an hour, or 2 minutes?
“Can you check if that will cause a diamond dependency”
“Can you try deflaking this test? Just add a retry if you need or silence it and we’ll deal with it later”
“I’ll refactor that so it’s harder to call it with a string that contains PII”
To me, those instructions are a little like OP’s “understand an algorithm” and I would need to do all of them without needing any support from a teammate in a predictable amount of time. The first 2 are 10 minute activities for some level of a rough draft, the 3rd I wrote specifically so it has an upper bound in time, and the “refactor” could take a couple hours but it’s still the case that one I recognize it’s possible in principle I can jump in and do it.
What I mean is that once they know the algorithm they want, writing that as code just flows, they can write out 50 lines of code that represents the algorithm in 10 minutes, without having to stop to double check what they’re doing after every statement.
Of course their implementation will have bugs, but it will still be approximately correct.
And vice versa, a talented developer can read any reasonably well written code and quickly work out what it’s doing.
It’s really about fluency in a language, like the difference between talking in your first language Vs one you only know from lessons. Writing code is the bread and butter of your job, so if you can’t do it fluently that’s a problem.
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 think the ability to “just look up this code” is a demonstration of fluency—if your way of figuring out “what happens when I invoke this library function” is “read the source code”, that indicates that you are able to fluently read code.
That said, fluently reading code and fluently writing code are somewhat different skills, and the very best developers relative to their toolchain can do both with that toolchain.
Indeed I am a Google L5, and I usually do look this stuff up (or ChatGPT it). I think it’s more important to remember roughly what libraries do at a high level (what problems they solve, how they differ from other solutions, what can’t they do) than trivia about how exactly you use them.
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.
You are right that writing code glue code is a large part of software engineering, and that knowing what the libraries do is an important part of that. But once you know (or think you know) what the libraries do, how quickly do you bash out the code that does that? Do you struggle, or does it just come naturally?
And as faul_sname pointed out, often the quickest way to understand what the library does is to look at it. Is that something you’re capable of doing, or are you forced to hope the documentation addresses it?
Other times you want to write a quick test that the library does what you expect. Is that going to take you half an hour, or 2 minutes?
“Wrap that in a semaphore”
“Can you check if that will cause a diamond dependency”
“Can you try deflaking this test? Just add a retry if you need or silence it and we’ll deal with it later”
“I’ll refactor that so it’s harder to call it with a string that contains PII”
To me, those instructions are a little like OP’s “understand an algorithm” and I would need to do all of them without needing any support from a teammate in a predictable amount of time. The first 2 are 10 minute activities for some level of a rough draft, the 3rd I wrote specifically so it has an upper bound in time, and the “refactor” could take a couple hours but it’s still the case that one I recognize it’s possible in principle I can jump in and do it.