25 ms·

Things I Don’t Know as of 2018

220 points by gurjeet 6y ago

jiofih 6y ago
YMMV and I know I’ll be judged a gatekeeper, but not knowing: networking, modern CSS, some familiarity with SASS, CORS, basic deployment / platforms, and graphics APIs (!) all seem like pretty gaping holes for a frontend engineer - you’ll most definitely need those when building actual products for the web.
- andrewingram 6y ago
  But you can also apply JIT to learning as well. Depending on your work, you may come across a situation that needs these things anywhere on the continuum from often to never. As the OP is a Facebook employee working as a core React team member, not knowing all these things clearly hasn't been a huge blocker. But similarly, he might well know these things to an above-average level, and just think that he doesn't.
  - lwigo 6y ago
    Or just grinds LeetCode really well (or had a referral).
  - ErikAugust 6y ago
    "As the OP is a Facebook employee working as a core React team member, not knowing all these things clearly hasn't been a huge blocker." 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.
    - kyawzazaw 6y ago
      Now you got me wondering how people who got more well known creating open source projects go through hiring process at these big tech cos. I know creator of Homebrew still had to go through typical google interview. I am talking about people like Jon Gjengset who got hired to work on Rust at AWS.
    - andrewingram 6y ago
      He was hired at the same conference at which he showcased Redux for the first time (as a byproduct of the content of his actual talk, which was time-travel debugging), so it's unlikely it directly gave him the cred necessary to get hired, since he was already in the hiring pipeline.
- idkat 6y ago
  Well it makes perfect sense to me why React keeps reinventing the wheel every other version and why it's a hot mess. This video makes more sense now as to why they don't seem to have any direction https://www.youtube.com/watch?v=iRo18pUs61Q https://www.youtube.com/watch?v=iRo18pUs61Q. Frontend web development shouldn't consume braincells and React reeks of shortsightedness.
  - arcturus17 6y ago
    I have absolutely no clue what you're rambling about, but if frontend dev shouldn't consume braincells, you go on and code a complex frontend in vanilla JS and then serve that plate of hot spaghetti to the devs coming after you.
  - richeyryan 6y ago
    That video is quite poor in my opinion. He comes so close to a bunch of very interesting questions like how can state management and effect management be done in a good, scalable way that maybe isn't tied to our view libraries? He then admits he has close to no opinion on the matter and suggests web components which is about a step above the jQuery scenario he described in the beginning. 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.
- colmvp 6y ago
  I don't think you're a gatekeeper, I just don't see the relevance to the author. 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.
  - clashmeifyoucan 6y ago
    Seconded, also reading the list, it's likely he just delved deep enough to solve the issue at hand and then back to work. 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).
- yladiz 6y ago
  If your speciality is frontend JS engineering, why are deployment, platforms, and networking (unless you simply mean how to use fetch/XMLHttpRequest) large holes? I'd even question graphics APIs beyond very basic knowledge, because in my experience I've never needed to know anything about those beyond the basics. These things sound more like full stack, rather than frontend.
  - jiofih 6y ago
    Yes, networking as in fetch/XHR, web sockets, HTTP, REST, protocols, performance and so on. How your frontend code runs. All I mentioned are strictly frontend skills, not anywhere near full-stack.
- johnfn 6y ago
  I mean, this is Dan Abramov we’re talking about. Ya know, the guy who created a good chunk of React. I’d say he built actual products for the web just fine.
  - jiofih 6y ago
    He is not one of the React authors, common misconception (his bio says “I didn’t make react” as a nod to that). He wrote the Redux library. Not that I would care either way - this is about skill sets and not personalities.
    - yreg 6y ago
      Abramov is the #1 contributor[0]. I guess by authors you mean only the innitial people who came up with React? [0] - https://github.com/facebook/react/graphs/contributors https://github.com/facebook/react/graphs/contributors
    - skinnymuch 6y ago
      He did create a big chunk of React. Half of the Github issues I see for React have him involved. He might not be a founder of React, but he sure is a major React author.
- names_are_hard 6y ago
  I think the point is that frontend engineering is a broad field, and everyone had gaps in their knowledge, especially specialists who focus on specific parts of the stack. It's possible to provide a ton of value on very complex frontends without doing much in the way of CSS, for example. I've been part of projects where the UI layer was handled in a dedicated library, and unless you wanted to be part of that team, you didn't have to understand much more than which React components to use when. Graphics are a specific subfield of frontend that isn't relevant to most apps, and it's possible to go very far without being exposed to these.
- burade 6y ago
  That's nonsense. The guy is a specialist. That's like asking Lionel Messi to also be good at goalkeeping.
- ogre_codes 6y ago
  > you’ll most definitely need those when building actual products for the web. 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.
  - jiofih 6y ago
    I know exactly who posted the article, thank you. I simply disagree that you can be a frontend engineer in the usual meaning it has without some level of those skills. Doesn’t mean anyone is less capable, deserving or cannot make a living that way.
    - ericmcer 6y ago
      But he is literally one of the most successful front end engineers of all time and lacks those skills. Your takeaway from the article is it’s antithesis.
      - jodrellblank 6y ago
        I simply don't believe he lacks those skills. He says "Python. I feel bad about this one — I have worked with Python for several years at some point and I’ve never bothered to actually learn it." 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.
        ogre_codes 6y ago
        > 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.
vzaliva 6y ago
There is a finite amount things we know and an infinite amounts of things we don't. Hence trying to list ones we do not know is futile. :)
- ogre_codes 6y ago
  It's not a comprehensive list of things this individual doesn't know. It's limited to technologies which other people assume they would know.
Phlogistique 6y ago
This is a list of known unknowns. Those are usually not a problem - the problems come with unknown unknowns.
- wbsun 6y ago
  +1, one can't know everything. Knowing the unknowns is often easy to fix, either learn them or find someone knows them. My company usually review postmortems of outages in production, almost all of them I have reviewed are because of a code change/config change that the author/operator had no idea about what could go wrong.
choeger 6y ago
From the list, I would suggest to learn C, because a lot of stuff is written in it or at least uses its ABI. So understanding that will give you a lot of leverage. Besides that, a deep dive into operating systems (yes, that means to get rid of MacOS if you use it) will give you a solid foundation to understand networking, containers and even more.
- Toutouxc 6y ago
  > I would suggest to learn C, because a lot of stuff is written in it Does it also mean we all need to learn how to design integrated circuits?
  - H8crilA 6y ago
    I do recommend learning VHDL/Verilog (it's like learning functional programming or prolog - a completely unique experience), but it really depends on what you're after in life. Churning out Java/Web CRUD apps is enough to earn a living, it is actually what most programmers do (and even though every such app is boring as hell, collectively it is highly important for the world).
    - nicoburns 6y ago
      It really does depend what you're after. I find working on CRUD apps quite interesting, because I care greatly about UX and understanding the people and business problems that motivate the tech.
  - choeger 6y ago
    If we could, that would be a great thing. But contrary to programs you cannot inspect an IC so we would not gain ass much. Otoh, running strace, gdb, and objdump can get you pretty far when debugging production code you've never seen that uses trillions of abstractions.
justin_oaks 6y ago
Reading this list made me really want to explain the basics of each of those items so as to clear up any misconceptions, or to confirm that, yes, he gets the gist of it. When I try to learn about topics that I'm unfamiliar with, the hardest information to find is "Why is X important?" and "What is the most important thing to know about X?" With those in hand, I'd be able to determine if a deep dive into the topic is useful for me or not.
- itsoktocry 6y ago
  >With those in hand, I'd be able to determine if a deep dive into the topic is useful for me or not. I think that's the point: we all know (most of) the gist of it. But the practical experience isn't something you can prep for in advance. You never know what tech you'll need to use in the real world. The "deep dive" comes when you get hired and the employer needs that tech. I'm not sure the employer gets that.
nemo1618 6y ago
I'd love to see lists like this from more high-profile programmers. What does John Carmack not know? What does Dan Bernstein not know? What does Bryan Cantrill not know?
- notretarded 6y ago
  Probably more than you'd think, although they'd not be so dumb as to vocalise it as one's career depends entirely on one's percieved capabilities.
  - myth2018 6y ago
    Actually at least Carmack did. Why would vocalizing that be dumb? It's actually not a matter of perceived capabilities, but of concrete results, and, in the case of those guys, there aren't plenty of room for discussion on this regard..
  - enriquto 6y ago
    > one's career depends entirely on one's percieved capabilities This may be true in many fields, but not in science and engineering.
- martindbp 6y ago
  > What does John Carmack not know? Vim or Emacs IIRC.
- myth2018 6y ago
  > What does John Carmack not know? As of 2014, relational databases. https://mobile.twitter.com/ID_AA_Carmack/status/457916010234777600 https://mobile.twitter.com/ID_AA_Carmack/status/457916010234...
- watermelon59 6y ago
  Not exactly that, but when reading Coders at Work I was surprised to learn that a lot of big names in our field use "printf debugging" and don't like actual debugging tools. Made me feel less bad about it :)
efiecho 6y ago
> Electron. Never tried it. And nothing of value is lost.
- dreamcompiler 6y ago
  The first time I spun up my own Electron app, I simultaneously had two feelings: 1. That took a lot of futzing around. 2. But way less futzing around than I expected for a fully cross-platform application. I still think the idea of Electron (using modern web technologies to develop applications) has merit. It just needs a better implementation (i.e use native webviews rather than shipping an entire browser.)
NiceWayToDoIT 6y ago
I love that article. Again harsh reality is that on average interview for a developer in London they will ask you all those questions and much more. And if you get hired by any chance in fintech you will most probably spend majority of your time on meetings and working with Excel spreadsheet... never touching any code.
MeinBlutIstBlau 6y ago
This article really makes me feel good as a current intern and comp sci student. I thought I clearly defined what a junior dev could be if I worked at it for another year. Having read all the stuff this guy doesn't know and what I've learned at my internship, it's almost any hint of imposter syndrome I might of had went away. Now I'm not saying he doesn't know how to program. I'm just saying it's very interesting to me how little you actually have to specialize in to make it in this field. What my internship has taught me, it really makes me feel secure job wise knowing I won't have difficulty being employed in the areas I know. I hate sounding so cocky but when I first started schooling again geared toward comp sci, I thought programmers knew just absurd amounts of stuff. Now I've found, they typically are just the average tech savvy individuals that weren't afraid to poke around in an OS.
- notretarded 6y ago
  Shush you, you're giving away the secret to my 6 figure salary.
- deleted 6y ago
  [deleted]
- alexpetralia 6y ago
  Most importantly, if you always keep this mindset, you will never stop learning!
- zests 6y ago
  Keep in mind technological knowledge is not the only factor. We pass on hiring plenty of technically competent people because of their communication skills. Knowing what you don’t know is one way to improve your communication skills.
  - tkgally 6y ago
    Good point. Knowing what other people don't know is important, too.
  - deleted 6y ago
    [deleted]
anonu 6y ago
This is common. I think there are few people that are masters at everything. Instead you should focus on building a talent stack or a skills mosaic. (Choose whichever term you want). The point is you might not be a master in any one subject but you might be pretty good at a handful of things. That permutation is enough to make you valuable and unique.
- watermelon59 6y ago
  I wonder if this is what contributes to the instability of most software though, especially SaaS. People do just enough to get by and "get things done," which always looks great at the time it happens. And then things break, and no one knows why because no one has the depth of knowledge to investigate it. But it has to be fixed, so typically one or two people in the team are assigned to it and are miserable for days or weeks while they painstakingly try and learn about the things they should've known in the first place, while at the same time try and fix a system under a lot of pressure from management. I wish the software industry rewarded knowledge, correctness and excellence rather than speed of execution. There are way too many things involved in a software system these days for people to know all of it. We shouldn't expected people to be highly knowledgeable about all of a programming language, multiple frameworks, libraries, cloud providers, CI/CD, security, and who knows what else. Instead, those should be specializations and teams should be composed of multiple specialists. I'm well aware that what I'm saying is a pipe dream. The industry at large is fine with the idea of deploying broken things and patching them later, no matter the cost to the health of engineers, so it's not gonna change anytime soon.
  - Xevi 6y ago
    You're right. Just by looking at job posts you'll see requirements to know several languages, frontend frameworks, databases, enterprise services, and so on. The modern programmer is often a jack of all trades, but a master of none. I'm building multi-million dollar applications for companies, and often it's with languages and frameworks I've never used before.
  - zests 6y ago
    From a selfish perspective, I like the current system. It makes it easier to stand out. Understand where depth is lacking on your team and become an expert. Whenever problems occur you become the go-to. Pros and cons but mostly pros.
forrestthewoods 6y ago
I love this list. My favorite thing about it is not only do I not know most of those things I don’t _want_ to know them. My background is video games. I specialize in real-time 3D applications. I think web tech is an overcomplicated embarrassment of cruft built on cruft built on cruft. Programming is a wide and diverse field. Webdev is the overwhelming majority of programming jobs. But you can have a very successful career not knowing _any_ of that stuff.
worik 6y ago
I am not sorry, this does not impress me. From the comments it appears this person has done some significant work in YetAnotherJavaScriptFramework. Boasting that: Fuzzy on the details of how TCP/IP works (hello web developer, read a book!), does not understand order complexity specifically or algorithms in general - as one commenter pointed out - no wonder JS front ends are such shit if this is the level of intellectual heft that the authors have. Not knowing modern CSS - how can this person possibly work in any sort of cutting edge web development and not know about that?.... Specialisation is OK, but ignoring the general knowledge of how computing works, and then going on to write software used in people's critical systems is irresponsible. Buy some books. Read them. Understand. It is not hard. But, yes, reading is harder than writing, listening is harder than talking, learning is harder than making stuff up and reinventing the wheel.... Yes. No wonder the state of web front ends.
- clashmeifyoucan 6y ago
  > I am not sorry, this does not impress me. I don't think it was meant to impress. On the contrary I think the overarching point of the whole article was that it's okay to not know things outside of your domain that may seem trivial to other CS folks. > Not knowing modern CSS - how can this person possibly work in any sort of cutting edge web development and not know about that? Well, I don't know how he does it anymore than you do. But it looks like he's still working on cutting edge web development and it seems to be working out, so my takeaway is that he doesn't need to know about it plain and simple.
  - kyberias 6y ago
    > it's okay to not know things outside of your domain that may seem trivial to other CS folks. Well, it's not ok. It's bad. It's irresponsible. There is a lot of basic stuff on that list one has to know.
    - karaterobot 6y ago
      How can you say that when there's no evidence for it? Abramov is a successful, respected programmer. Redux is a major contribution to the web. This article came out two years ago, and he doesn't appear to have ruined his reputation. On what basis is it safe to say he "has" to know any of the stuff he freely admits to not knowing?
alexanderscott 6y ago
no offense, but from this list the author is either 1) stuck in a particular domain or language or 2) not very proactive in broader learning or side projects. I agree it’s ok to not program C or understand network/transport layer in depth. but things like unix shell basics, python, micro services, docker - these are all fundamentals I assume everyone (backend, frontend, mobile, or game engine) has working understanding of in order to be a proficient developer today. nice that the author recognizes the areas they lack, and should commit to learning in 2021. happy to give good recommendations on books or online classes. more curious to see this list authored from someone with more diverse experience.
- mellosouls 6y ago
  Co-creator of redux, he was partly motivated to write the article to counter ideas you need to be fluent in everything, often propogated (intentionally or not) by "as a hiring manager...red flags" posts like yours. Fwiw: https://github.com/gaearon https://github.com/gaearon
  - alexanderscott 6y ago
    didn’t say need to be “fluent”, said need “working understanding” in today’s environment. countering that idea is futile. working on an open source JS framework is great and all, but doesn’t make you a seasoned engineer IMO. TlDR: take this list and dedicate time in 2021 to learning so you can be productive in real world business engineering teams
    - deleted 6y ago
      [deleted]
    - yladiz 6y ago
      Obviously the author is productive on a "real world business engineering team" considering they work for Facebook. Since you seem to have a lot to critique about the post and the author, maybe it's worth putting in that effort into reflection and self-criticality as well.
  - 6y ago
dang 6y ago
Discussed at the time: https://news.ycombinator.com/item?id=18780065 https://news.ycombinator.com/item?id=18780065
kebman 6y ago
I noticed he didn't know much about Rust. And I really want to learn Rust. Except it seems the installation size is reprehensible. Is there a way to install a minimum version to get started with some fiddling about?
- saagarjha 6y ago
  There’s a playground you can try in the browser: https://play.rust-lang.org/ https://play.rust-lang.org/
- Flex247A 6y ago
  You could try installing the MinGW version of the compiler
  - kebman 6y ago
    This might be what I'm looking for! Thank you! Hehe looks like it's gonna be a bit of an adventure, though.
    - Flex247A 6y ago
      Remember that rustup doesn't work and you'll have to update manually.
quda 6y ago
Lets face it, we are all the same. Gap over gap... We just pretend to be otherWISE.
aszen 6y ago
For those who are interested in what actual things the author knows, read https://overreacted.io/the-elements-of-ui-engineering/ https://overreacted.io/the-elements-of-ui-engineering/ Reading it I feel that creative problem solving is more important than simply knowing stuff. I wonder if knowing too much stuff is actually detrimental to exploring new ideas and trying them out.

220 points by gurjeet 6y ago

YMMV and I know I’ll be judged a gatekeeper, but not knowing: networking, modern CSS, some familiarity with SASS, CORS, basic deployment / platforms, and graphics APIs (!) all seem like pretty gaping holes for a frontend engineer - you’ll most definitely need those when building actual products for the web.

andrewingram 6y ago
But you can also apply JIT to learning as well. Depending on your work, you may come across a situation that needs these things anywhere on the continuum from often to never. As the OP is a Facebook employee working as a core React team member, not knowing all these things clearly hasn't been a huge blocker. But similarly, he might well know these things to an above-average level, and just think that he doesn't.
- lwigo 6y ago
  Or just grinds LeetCode really well (or had a referral).
- ErikAugust 6y ago
  "As the OP is a Facebook employee working as a core React team member, not knowing all these things clearly hasn't been a huge blocker." 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.
  - kyawzazaw 6y ago
    Now you got me wondering how people who got more well known creating open source projects go through hiring process at these big tech cos. I know creator of Homebrew still had to go through typical google interview. I am talking about people like Jon Gjengset who got hired to work on Rust at AWS.
  - andrewingram 6y ago
    He was hired at the same conference at which he showcased Redux for the first time (as a byproduct of the content of his actual talk, which was time-travel debugging), so it's unlikely it directly gave him the cred necessary to get hired, since he was already in the hiring pipeline.
idkat 6y ago
Well it makes perfect sense to me why React keeps reinventing the wheel every other version and why it's a hot mess. This video makes more sense now as to why they don't seem to have any direction https://www.youtube.com/watch?v=iRo18pUs61Q https://www.youtube.com/watch?v=iRo18pUs61Q. Frontend web development shouldn't consume braincells and React reeks of shortsightedness.
- arcturus17 6y ago
  I have absolutely no clue what you're rambling about, but if frontend dev shouldn't consume braincells, you go on and code a complex frontend in vanilla JS and then serve that plate of hot spaghetti to the devs coming after you.
- richeyryan 6y ago
  That video is quite poor in my opinion. He comes so close to a bunch of very interesting questions like how can state management and effect management be done in a good, scalable way that maybe isn't tied to our view libraries? He then admits he has close to no opinion on the matter and suggests web components which is about a step above the jQuery scenario he described in the beginning. 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.
colmvp 6y ago
I don't think you're a gatekeeper, I just don't see the relevance to the author. 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.
- clashmeifyoucan 6y ago
  Seconded, also reading the list, it's likely he just delved deep enough to solve the issue at hand and then back to work. 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).
yladiz 6y ago
If your speciality is frontend JS engineering, why are deployment, platforms, and networking (unless you simply mean how to use fetch/XMLHttpRequest) large holes? I'd even question graphics APIs beyond very basic knowledge, because in my experience I've never needed to know anything about those beyond the basics. These things sound more like full stack, rather than frontend.
- jiofih 6y ago
  Yes, networking as in fetch/XHR, web sockets, HTTP, REST, protocols, performance and so on. How your frontend code runs. All I mentioned are strictly frontend skills, not anywhere near full-stack.
johnfn 6y ago
I mean, this is Dan Abramov we’re talking about. Ya know, the guy who created a good chunk of React. I’d say he built actual products for the web just fine.
- jiofih 6y ago
  He is not one of the React authors, common misconception (his bio says “I didn’t make react” as a nod to that). He wrote the Redux library. Not that I would care either way - this is about skill sets and not personalities.
  - yreg 6y ago
    Abramov is the #1 contributor[0]. I guess by authors you mean only the innitial people who came up with React? [0] - https://github.com/facebook/react/graphs/contributors https://github.com/facebook/react/graphs/contributors
  - skinnymuch 6y ago
    He did create a big chunk of React. Half of the Github issues I see for React have him involved. He might not be a founder of React, but he sure is a major React author.
names_are_hard 6y ago
I think the point is that frontend engineering is a broad field, and everyone had gaps in their knowledge, especially specialists who focus on specific parts of the stack. It's possible to provide a ton of value on very complex frontends without doing much in the way of CSS, for example. I've been part of projects where the UI layer was handled in a dedicated library, and unless you wanted to be part of that team, you didn't have to understand much more than which React components to use when. Graphics are a specific subfield of frontend that isn't relevant to most apps, and it's possible to go very far without being exposed to these.
burade 6y ago
That's nonsense. The guy is a specialist. That's like asking Lionel Messi to also be good at goalkeeping.
ogre_codes 6y ago
> you’ll most definitely need those when building actual products for the web. 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.
- jiofih 6y ago
  I know exactly who posted the article, thank you. I simply disagree that you can be a frontend engineer in the usual meaning it has without some level of those skills. Doesn’t mean anyone is less capable, deserving or cannot make a living that way.
  - ericmcer 6y ago
    But he is literally one of the most successful front end engineers of all time and lacks those skills. Your takeaway from the article is it’s antithesis.
    - jodrellblank 6y ago
      I simply don't believe he lacks those skills. He says "Python. I feel bad about this one — I have worked with Python for several years at some point and I’ve never bothered to actually learn it." 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.
      - ogre_codes 6y ago
        > 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.

vzaliva 6y ago

There is a finite amount things we know and an infinite amounts of things we don't. Hence trying to list ones we do not know is futile. :)

ogre_codes 6y ago
It's not a comprehensive list of things this individual doesn't know. It's limited to technologies which other people assume they would know.

Phlogistique 6y ago

This is a list of known unknowns. Those are usually not a problem - the problems come with unknown unknowns.

wbsun 6y ago
+1, one can't know everything. Knowing the unknowns is often easy to fix, either learn them or find someone knows them. My company usually review postmortems of outages in production, almost all of them I have reviewed are because of a code change/config change that the author/operator had no idea about what could go wrong.

choeger 6y ago

From the list, I would suggest to learn C, because a lot of stuff is written in it or at least uses its ABI. So understanding that will give you a lot of leverage. Besides that, a deep dive into operating systems (yes, that means to get rid of MacOS if you use it) will give you a solid foundation to understand networking, containers and even more.

Toutouxc 6y ago
> I would suggest to learn C, because a lot of stuff is written in it Does it also mean we all need to learn how to design integrated circuits?
- H8crilA 6y ago
  I do recommend learning VHDL/Verilog (it's like learning functional programming or prolog - a completely unique experience), but it really depends on what you're after in life. Churning out Java/Web CRUD apps is enough to earn a living, it is actually what most programmers do (and even though every such app is boring as hell, collectively it is highly important for the world).
  - nicoburns 6y ago
    It really does depend what you're after. I find working on CRUD apps quite interesting, because I care greatly about UX and understanding the people and business problems that motivate the tech.
- choeger 6y ago
  If we could, that would be a great thing. But contrary to programs you cannot inspect an IC so we would not gain ass much. Otoh, running strace, gdb, and objdump can get you pretty far when debugging production code you've never seen that uses trillions of abstractions.

justin_oaks 6y ago

Reading this list made me really want to explain the basics of each of those items so as to clear up any misconceptions, or to confirm that, yes, he gets the gist of it. When I try to learn about topics that I'm unfamiliar with, the hardest information to find is "Why is X important?" and "What is the most important thing to know about X?" With those in hand, I'd be able to determine if a deep dive into the topic is useful for me or not.

itsoktocry 6y ago
>With those in hand, I'd be able to determine if a deep dive into the topic is useful for me or not. I think that's the point: we all know (most of) the gist of it. But the practical experience isn't something you can prep for in advance. You never know what tech you'll need to use in the real world. The "deep dive" comes when you get hired and the employer needs that tech. I'm not sure the employer gets that.

nemo1618 6y ago

I'd love to see lists like this from more high-profile programmers. What does John Carmack not know? What does Dan Bernstein not know? What does Bryan Cantrill not know?

notretarded 6y ago
Probably more than you'd think, although they'd not be so dumb as to vocalise it as one's career depends entirely on one's percieved capabilities.
- myth2018 6y ago
  Actually at least Carmack did. Why would vocalizing that be dumb? It's actually not a matter of perceived capabilities, but of concrete results, and, in the case of those guys, there aren't plenty of room for discussion on this regard..
- enriquto 6y ago
  > one's career depends entirely on one's percieved capabilities This may be true in many fields, but not in science and engineering.
martindbp 6y ago
> What does John Carmack not know? Vim or Emacs IIRC.
myth2018 6y ago
> What does John Carmack not know? As of 2014, relational databases. https://mobile.twitter.com/ID_AA_Carmack/status/457916010234777600 https://mobile.twitter.com/ID_AA_Carmack/status/457916010234...
watermelon59 6y ago
Not exactly that, but when reading Coders at Work I was surprised to learn that a lot of big names in our field use "printf debugging" and don't like actual debugging tools. Made me feel less bad about it :)

efiecho 6y ago

> Electron. Never tried it. And nothing of value is lost.

dreamcompiler 6y ago
The first time I spun up my own Electron app, I simultaneously had two feelings: 1. That took a lot of futzing around. 2. But way less futzing around than I expected for a fully cross-platform application. I still think the idea of Electron (using modern web technologies to develop applications) has merit. It just needs a better implementation (i.e use native webviews rather than shipping an entire browser.)

NiceWayToDoIT 6y ago

I love that article. Again harsh reality is that on average interview for a developer in London they will ask you all those questions and much more. And if you get hired by any chance in fintech you will most probably spend majority of your time on meetings and working with Excel spreadsheet... never touching any code.

MeinBlutIstBlau 6y ago

This article really makes me feel good as a current intern and comp sci student. I thought I clearly defined what a junior dev could be if I worked at it for another year. Having read all the stuff this guy doesn't know and what I've learned at my internship, it's almost any hint of imposter syndrome I might of had went away. Now I'm not saying he doesn't know how to program. I'm just saying it's very interesting to me how little you actually have to specialize in to make it in this field. What my internship has taught me, it really makes me feel secure job wise knowing I won't have difficulty being employed in the areas I know. I hate sounding so cocky but when I first started schooling again geared toward comp sci, I thought programmers knew just absurd amounts of stuff. Now I've found, they typically are just the average tech savvy individuals that weren't afraid to poke around in an OS.

notretarded 6y ago
Shush you, you're giving away the secret to my 6 figure salary.
deleted 6y ago
[deleted]
alexpetralia 6y ago
Most importantly, if you always keep this mindset, you will never stop learning!
zests 6y ago
Keep in mind technological knowledge is not the only factor. We pass on hiring plenty of technically competent people because of their communication skills. Knowing what you don’t know is one way to improve your communication skills.
- tkgally 6y ago
  Good point. Knowing what other people don't know is important, too.
- deleted 6y ago
  [deleted]

anonu 6y ago

This is common. I think there are few people that are masters at everything. Instead you should focus on building a talent stack or a skills mosaic. (Choose whichever term you want). The point is you might not be a master in any one subject but you might be pretty good at a handful of things. That permutation is enough to make you valuable and unique.

watermelon59 6y ago
I wonder if this is what contributes to the instability of most software though, especially SaaS. People do just enough to get by and "get things done," which always looks great at the time it happens. And then things break, and no one knows why because no one has the depth of knowledge to investigate it. But it has to be fixed, so typically one or two people in the team are assigned to it and are miserable for days or weeks while they painstakingly try and learn about the things they should've known in the first place, while at the same time try and fix a system under a lot of pressure from management. I wish the software industry rewarded knowledge, correctness and excellence rather than speed of execution. There are way too many things involved in a software system these days for people to know all of it. We shouldn't expected people to be highly knowledgeable about all of a programming language, multiple frameworks, libraries, cloud providers, CI/CD, security, and who knows what else. Instead, those should be specializations and teams should be composed of multiple specialists. I'm well aware that what I'm saying is a pipe dream. The industry at large is fine with the idea of deploying broken things and patching them later, no matter the cost to the health of engineers, so it's not gonna change anytime soon.
- Xevi 6y ago
  You're right. Just by looking at job posts you'll see requirements to know several languages, frontend frameworks, databases, enterprise services, and so on. The modern programmer is often a jack of all trades, but a master of none. I'm building multi-million dollar applications for companies, and often it's with languages and frameworks I've never used before.
- zests 6y ago
  From a selfish perspective, I like the current system. It makes it easier to stand out. Understand where depth is lacking on your team and become an expert. Whenever problems occur you become the go-to. Pros and cons but mostly pros.

forrestthewoods 6y ago

I love this list. My favorite thing about it is not only do I not know most of those things I don’t _want_ to know them. My background is video games. I specialize in real-time 3D applications. I think web tech is an overcomplicated embarrassment of cruft built on cruft built on cruft. Programming is a wide and diverse field. Webdev is the overwhelming majority of programming jobs. But you can have a very successful career not knowing _any_ of that stuff.

worik 6y ago

I am not sorry, this does not impress me. From the comments it appears this person has done some significant work in YetAnotherJavaScriptFramework. Boasting that: Fuzzy on the details of how TCP/IP works (hello web developer, read a book!), does not understand order complexity specifically or algorithms in general - as one commenter pointed out - no wonder JS front ends are such shit if this is the level of intellectual heft that the authors have. Not knowing modern CSS - how can this person possibly work in any sort of cutting edge web development and not know about that?.... Specialisation is OK, but ignoring the general knowledge of how computing works, and then going on to write software used in people's critical systems is irresponsible. Buy some books. Read them. Understand. It is not hard. But, yes, reading is harder than writing, listening is harder than talking, learning is harder than making stuff up and reinventing the wheel.... Yes. No wonder the state of web front ends.

clashmeifyoucan 6y ago
> I am not sorry, this does not impress me. I don't think it was meant to impress. On the contrary I think the overarching point of the whole article was that it's okay to not know things outside of your domain that may seem trivial to other CS folks. > Not knowing modern CSS - how can this person possibly work in any sort of cutting edge web development and not know about that? Well, I don't know how he does it anymore than you do. But it looks like he's still working on cutting edge web development and it seems to be working out, so my takeaway is that he doesn't need to know about it plain and simple.
- kyberias 6y ago
  > it's okay to not know things outside of your domain that may seem trivial to other CS folks. Well, it's not ok. It's bad. It's irresponsible. There is a lot of basic stuff on that list one has to know.
  - karaterobot 6y ago
    How can you say that when there's no evidence for it? Abramov is a successful, respected programmer. Redux is a major contribution to the web. This article came out two years ago, and he doesn't appear to have ruined his reputation. On what basis is it safe to say he "has" to know any of the stuff he freely admits to not knowing?

alexanderscott 6y ago

no offense, but from this list the author is either 1) stuck in a particular domain or language or 2) not very proactive in broader learning or side projects. I agree it’s ok to not program C or understand network/transport layer in depth. but things like unix shell basics, python, micro services, docker - these are all fundamentals I assume everyone (backend, frontend, mobile, or game engine) has working understanding of in order to be a proficient developer today. nice that the author recognizes the areas they lack, and should commit to learning in 2021. happy to give good recommendations on books or online classes. more curious to see this list authored from someone with more diverse experience.

mellosouls 6y ago
Co-creator of redux, he was partly motivated to write the article to counter ideas you need to be fluent in everything, often propogated (intentionally or not) by "as a hiring manager...red flags" posts like yours. Fwiw: https://github.com/gaearon https://github.com/gaearon
- alexanderscott 6y ago
  didn’t say need to be “fluent”, said need “working understanding” in today’s environment. countering that idea is futile. working on an open source JS framework is great and all, but doesn’t make you a seasoned engineer IMO. TlDR: take this list and dedicate time in 2021 to learning so you can be productive in real world business engineering teams
  - deleted 6y ago
    [deleted]
  - yladiz 6y ago
    Obviously the author is productive on a "real world business engineering team" considering they work for Facebook. Since you seem to have a lot to critique about the post and the author, maybe it's worth putting in that effort into reflection and self-criticality as well.
- 6y ago

dang 6y ago

Discussed at the time: https://news.ycombinator.com/item?id=18780065 https://news.ycombinator.com/item?id=18780065

kebman 6y ago

I noticed he didn't know much about Rust. And I really want to learn Rust. Except it seems the installation size is reprehensible. Is there a way to install a minimum version to get started with some fiddling about?

saagarjha 6y ago
There’s a playground you can try in the browser: https://play.rust-lang.org/ https://play.rust-lang.org/
Flex247A 6y ago
You could try installing the MinGW version of the compiler
- kebman 6y ago
  This might be what I'm looking for! Thank you! Hehe looks like it's gonna be a bit of an adventure, though.
  - Flex247A 6y ago
    Remember that rustup doesn't work and you'll have to update manually.

quda 6y ago

Lets face it, we are all the same. Gap over gap... We just pretend to be otherWISE.

aszen 6y ago

For those who are interested in what actual things the author knows, read https://overreacted.io/the-elements-of-ui-engineering/ https://overreacted.io/the-elements-of-ui-engineering/ Reading it I feel that creative problem solving is more important than simply knowing stuff. I wonder if knowing too much stuff is actually detrimental to exploring new ideas and trying them out.