Things I Don’t Know as of 2018

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

> What does John Carmack not know?

As of 2014, relational databases.

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

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

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.

> What does John Carmack not know?

Vim or Emacs IIRC.

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.

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

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.

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

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

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.

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.

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.

That's nonsense.

The guy is a specialist. That's like asking Lionel Messi to also be good at goalkeeping.

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.

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

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.

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. Frontend web development shouldn't consume braincells and React reeks of shortsightedness.

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.

There’s a playground you can try in the browser: https://play.rust-lang.org/

You could try installing the MinGW version of the compiler

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

> 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

If the knowledge is not relevant or applicable to what you are working on, what is the problem?

Knowing that things exist is more important than in-depth knowledge of those things.

Lots of things can be learned from books, but there are only so many hours in a day.

The vast majority of web developers I've worked with don't know TCP, and I'd count myself in that group too.

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.

Hang onto the impostor syndrome. Eventually, you come to accept that it seems like everyone around you knows things you don't, and then it keeps you pushing yourself.

Shush you, you're giving away the secret to my 6 figure salary.

Don't be too sure about not having difficulty being employed in areas you know.

During my last job hunt three years ago, I had interviews every week. On my current job hunt, I'm having problems booking just one.

There will always be a combination of factors that can make your job search easier or harder.

Don't be too quick to take it at face value. It's hard to write down what is actually in one's head, even for experienced writers. I'm sure he'll tell you a lot more on the stuff he claims he doesn't know if you had the good fortune of having a chat with him in person. Also, keep in mind that he probably knows deeply about some things and their extents, and so his definition of words like 'fuzzy' should be different from that of an intern's. As he puts it himself,

> Experienced developers have valuable expertise despite knowledge gaps

contributes heavily to

> learning technologies when I need them

which can be very valuable.

The older I am, the more experience I have, the harder i find landing a job. 10+ years of experience, multiple companies. Also, not that many techs/skills from earlier years are applicable now, it seems that there were couple of technology cycles since then, and more experienced persons may have no much advantage over younger persons.

If people you know do not know much, then the people you know do not know much, there are also people you do not know.