I think this is normal especially if you’re changing languages, frameworks, codebases. Some people are gifted in memorization of these things and others of us just forget if it’s not needed. I do the same thing with people’s names.
If you’re working on the same type of thing everyday you’ll likely remember how to reverse an array in JavaScript. The other day I was trying to remember how to reverse a string in JavaScript… that was fun.
> Some people are gifted in memorization of these things
Those are usually people who aren't changing languages or frameworks. Memory is mostly recency and repetition, so if you want better memory then narrowing scope is a good strategy. I'd rather go broad so that I can better make connections between things but have to always look up the specifics especially now with LLMs right there
“You don't need to know everything. You need to know how to find everything.”
This is the knowledge in the head vs. in the world thing from Design of Everyday Things - if the knowledge is easily accessible in the world you will naturally keep it there not in your head. Maybe Google/LLMs are so fast this is the result.
One of the reasons I hate interviewing for software jobs is that the logic seems to be the opposite of this, and instead you should have any possible esoteric concept or possible problem ready at the top of your head instantly. And the same idea now with not allowing LLM for technical interviews
I'd reverse that. Junior developers should not be using google. But if they are a senior developer, they are probably wasting their time using LLM's instead of google.
The reason is pretty straight forward. I'm a senior developer. If I ask an LLM a question about my domain of expertise, I usually often get hallucinations or 100's of useless words saying nothing. That's because I already know most of what the LLM's have seen on the internet.
But if I ask it for background information in a topic I'm new to, an LLM is great starting point.
Most of the engineers who work for my department would have had an easier time explaining big o when they had a lot less experience. Most of them haven't thought about it since college.
>Last Tuesday, I spent 20 minutes Googling "how to reverse an array in JavaScript" because I couldn't remember if it was .reverse() or .reversed() or .reverseArray().
It is normal to not remember this, I certainly agree do not. It is not normal to use a dev environment, where you need to use Google to answer this question.
Also Google does incredibly poorly on these types of questions, often linking absolute slop instead of the official documentation. Git for example has great documentation, but if you look for it through Google you get AI slop articles which answer your question in 30 paragraphs.
Hell, even internet searching "mdn array reverse" will give you `reverse()` as the first result.
---
I genuinely find it concerning that it takes 20 minutes of "Googling" for the "Senior Developer" to work out something that is easily findable in the documentation.
It's especially worrying that they are then advising junior developers to do the exact same thing.
I appreciate that the author is trying to be encouraging. That's valuable, and we need more of it in this industry at the moment. But advising people that it's okay to avoid reading the documentation first is bad advice, in my opinion.
I think this is normal especially if you’re changing languages, frameworks, codebases. Some people are gifted in memorization of these things and others of us just forget if it’s not needed. I do the same thing with people’s names.
If you’re working on the same type of thing everyday you’ll likely remember how to reverse an array in JavaScript. The other day I was trying to remember how to reverse a string in JavaScript… that was fun.
> Some people are gifted in memorization of these things
Those are usually people who aren't changing languages or frameworks. Memory is mostly recency and repetition, so if you want better memory then narrowing scope is a good strategy. I'd rather go broad so that I can better make connections between things but have to always look up the specifics especially now with LLMs right there
“You don't need to know everything. You need to know how to find everything.”
This is the knowledge in the head vs. in the world thing from Design of Everyday Things - if the knowledge is easily accessible in the world you will naturally keep it there not in your head. Maybe Google/LLMs are so fast this is the result.
One of the reasons I hate interviewing for software jobs is that the logic seems to be the opposite of this, and instead you should have any possible esoteric concept or possible problem ready at the top of your head instantly. And the same idea now with not allowing LLM for technical interviews
I agree I don’t think interviews match development reality very well
If I am doing something more often (especially Linux commands) I am creating pages in Joplin to search in them.
senior developers - in the year of our Lord 2025 - should not be using google :)
You're probably right, DDG and Kagi have been returning significantly better results for technical queries for many years now.
I'd reverse that. Junior developers should not be using google. But if they are a senior developer, they are probably wasting their time using LLM's instead of google.
The reason is pretty straight forward. I'm a senior developer. If I ask an LLM a question about my domain of expertise, I usually often get hallucinations or 100's of useless words saying nothing. That's because I already know most of what the LLM's have seen on the internet.
But if I ask it for background information in a topic I'm new to, an LLM is great starting point.
trvke... basically chatgpt-ing everything these days.
Some of these are too embarrassing ever for juniors. No senior should struggle with big o notation.
He only has 8 years of experience, so not very senior.
Most of the engineers who work for my department would have had an easier time explaining big o when they had a lot less experience. Most of them haven't thought about it since college.
Do you think most enterprises even care about Big O outside of silicon valley? The answer is no.
What? Whens rhe last time you even thought about big o notation since college?
>Last Tuesday, I spent 20 minutes Googling "how to reverse an array in JavaScript" because I couldn't remember if it was .reverse() or .reversed() or .reverseArray().
It is normal to not remember this, I certainly agree do not. It is not normal to use a dev environment, where you need to use Google to answer this question.
Also Google does incredibly poorly on these types of questions, often linking absolute slop instead of the official documentation. Git for example has great documentation, but if you look for it through Google you get AI slop articles which answer your question in 30 paragraphs.
The biggest issue with this is that the developer did not read the documentation on the JavaScript Array prototype from MDN.
If you internet search "mdn array", you get the following as the first result:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
Then `⌘F`/`Ctrl-F` "reverse", the first result will be a link to this page:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
The second result will give the non-mutating ES6 version:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
Hell, even internet searching "mdn array reverse" will give you `reverse()` as the first result.
---
I genuinely find it concerning that it takes 20 minutes of "Googling" for the "Senior Developer" to work out something that is easily findable in the documentation.
It's especially worrying that they are then advising junior developers to do the exact same thing.
I appreciate that the author is trying to be encouraging. That's valuable, and we need more of it in this industry at the moment. But advising people that it's okay to avoid reading the documentation first is bad advice, in my opinion.