Live data from Hacker News

Things I Don’t Know as of 2018

overreacted.io

31–40 of 119 posts

Re: Things I Don’t Know as of 2018

#31
post #2

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.

> 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.

Re: Things I Don’t Know as of 2018

#32

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?

> What does John Carmack not know?

As of 2014, relational databases.

https://mobile.twitter.com/ID_AA_Carmack/status/457916010234...

Re: Things I Don’t Know as of 2018

#33

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?

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.

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..

Re: Things I Don’t Know as of 2018

#34

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?

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 :)

Re: Things I Don’t Know as of 2018

#35
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.

Re: Things I Don’t Know as of 2018

#36
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.

Re: Things I Don’t Know as of 2018

#37

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?

Following JC, as of one year ago, he didn't know much about AI, NNs and DL. Last week, he achieved familiarity. I believe him.

Re: Things I Don’t Know as of 2018

#38
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.

Re: Things I Don’t Know as of 2018

#39

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 understandi…

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

Re: Things I Don’t Know as of 2018

#40
post #24

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.

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.

Post reply on HN