He's a library designer and is working with a team maintaining and updating one of the most popular Javascript libraries in the world. He has a very deep background in that language which is one of the most important skills for his role.
I don't blame him for not knowing some of those things you listed more deeply. There's only so many hours a day to dig deep into a wide range of material. You still have to spend time going into other material that might be more relevant to the day to day including testing, managing people, communication with team members, planning, etc. Yeah sure I'd love to be more knowledgeable about CORS or networking, but I also want to be much stronger in Javascript, the JS library I'm working on, design patterns, deployment, etc.
Lastly, I'd rather be in Abramov's shoes where my work profoundly influenced web development than be all over the place with my 'expertise' and not actually be all that impactful with my time.
I can relate to that a bit, especially CORS since I never bothered to see what was up with that at a deep level either. Honestly just used a module for Flask when needed to get it working there and set up a CORS proxy on a cloudflare worker for a different project and called it a day.
Maybe that's how it went with him too. I'd call this something like "Laze Driven Development"—learning just enough to solve the problem (like my experiences with bash scripts).
I’d say he built actual products for the web just fine.
Not that I would care either way - this is about skill sets and not personalities.
But similarly, he might well know these things to an above-average level, and just think that he doesn't.
In a practical sense that should be fine, given the level of specialization that a company like Facebook can have given its size and scope. But I wonder if Dan would make it through the average Facebook engineer interview without his Redux cred however.
He is also the rare person who is very honest about this kind of thing which is refreshing. For example he claims he only vaguely understands time complexity ("nested loops are bad").
I don't know exactly what point I'm making here, besides there can be a disconnect between a developer interview process and what people actually contribute. I think engineers should strive to be solid at the fundamentals, but at the same time there are very productive people who just learn as they go. Also, it takes a village so to speak, and over-optimizing for Comp Sci majors who drill LeetCode may not be the best long term choice for building teams either.
I am talking about people like Jon Gjengset who got hired to work on Rust at AWS.
The guy is a specialist. That's like asking Lionel Messi to also be good at goalkeeping.
You should take a good look at who posted the article.
Fundamentally, who he is and what he's done in the community is the context of the blog. Without understanding that, you miss the entire point.
He's skilled at JavaScript and C# and worked with Python for years, what's the betting he's as good as any typical Python developer, if not better? Pretty good, I'd think.
> "I struggle to read either LISP-inspired (like Clojure), Haskell-inspired (like Elm), or ML-inspired (like OCaml) code"
How many people don't know Haskell but can successfully struggle through reading it instead of having their eyes glaze over and completely refuse to try?
> "CORS. I dread these errors! I know I need to set up some headers to fix them but I’ve wasted hours here in the past."
"I don't know it - but I've also worked on it and know how to fix it and done so" - hmmmm. I suspect he is more capable than he's making out; politely talking himself down.
Why?
If you are heads down working on core Javascript technologies, why do you step over and dig into learning more than the basics of Python? Likewise most of these languages/ skills.
I'll accept his word that he doesn't know the details of Python module imports, that he isn't an expert, but surely there's a difference between "not expert at X" and "don't know X"?
You are commingling "Don't understand programming" with "Don't understand Python here. It's pretty clear that an experienced developer is going to understand parenthesis matching. But regardless of how many years of experience you have in Javascript, the first time you see a Python list comprehension you are likely to scratch your head for a bit. Python lambdas are also quite alien if you aren't familiar with them.
FWIW, I was a professional developer for 10+ years before I knew learned Big O notation. I know a fair number of junior and even senior developers who don't know Big O notation even now. I knew how to avoid Big O type problems long before I knew the terminology.
The first time, sure. After several years of working with Python? He does say that. "I have worked with Python for several years".
Dan isn't a frontend engineer in the usual sense. He works on the underpinnings of the language, he's not building web sites.
The way I see it the advent of React was basically a rejection of the imperative MVC model that was prevalent with the likes of Backbone in favor of a more functional one. The first prototype of React was written in Standard ML. The evolution over the years with flux, redux and hooks was basically answering the questions that were arguably solved in MVC already but coming from the angle of declarative, immutable approaches. Where does state live? How do I handle asynchronous effects? How do I abstract that behavior from my views?
I don't think the community has answered those questions definitively yet and a lot of the interest seems to be in refining the view mechanics with the likes of Svelte rather than really getting to grips with how to best handle long lived application state and the effects that operate on it.
One thing I could see being the case in a couple of years, and in some ways the video does reach this conclusion, is that the reactive, stateful layer will be abstracted from the view and how you render your data will be almost like choosing a templating engine on the server. It could be React, Vue, Svele, Marko, Web Components, whatever. Those libraries and components will handle your dropdowns opening and closing and your tooltips showing but your real application state that distinguishes your product from another will live somewhere else and will be less subject to churn.