
Things I Don’t Know as of 2018 - nhebb
https://overreacted.io/things-i-dont-know-as-of-2018/
======
erulabs
This is an awesome article! I like the idea of being more forthcoming with
what we don't know.

> Containers. I have no idea about how to use Docker or Kubernetes. (Are those
> related?) I have a vague idea that they let me spin up a separate VM in a
> predictable way. Sounds cool but I haven’t tried it.

> Deployment and devops. I can manage to send some files over FTP or kill some
> processes but that’s the limit of my devops skills.

I'm working hard on trying to tease out a method to educate developers about
DevOps / Kubernetes... It's hard to explain to people who have not been on-
call or walked into a company on their first day as a devops, but I am
strongly in the camp of "Kubernetes is live-saving, game-changing, etc". I
tend to fail to explain to most product-focused developers successfully -
Either too low level, too high level and hand-wavey, or they walk away with a
sense of "man one day, that might be cool", rather than "We could get going on
this _today_!". The most success I've had is in demonstrations (I have a
raspberry Pi Kube cluster with 4 pies, with which I can physically unplug
power, network, disk, etc and show off Kube's self-healing and auto-discovery
powers), but at companies with day to day stresses, not so much. Plus the demo
only scratches the service of cool features of even the Deployment API object.

Shameless self promo, but I'm working on a project with a friend that
hopefully helps. I want product-focused developers to have a "Heroku" moment
about kube and understand the immense benefits they get from designing their
applications with a "cloud-native" mindset. That the small cost is _vastly_
worth the benefit. The project is here:
[https://kubesail.com/](https://kubesail.com/).

My "thing I dont know as of 2018", just for good measure: How to build complex
front-end applications without making a complete mess of things!

~~~
jchw
>My "thing I dont know as of 2018", just for good measure: How to build
complex front-end applications without making a complete mess of things!

If you find _anyone_ that truly knows the answer, please let us know :)

I'm sure plenty of people claim to, and many more will just claim that the
mere concept is flawed so there's no point, and there are even more non-
answers. But the actual problem is very difficult. I remember when AngularJS
(the old Angular) first came out and it felt like we finally started having an
idea of how to handle frontend after years of dissatisfaction with jQuery,
Knockout, etc.. Then React, Polymer, Web Components, ES6, Webpack, Modules,
TypeScript, Redux (and its Flux-based ancestors) and so, so much more hit
and... it's mesmerizing.

I think React is the best option so far, it's still not 100% where it should
be but it offers my favorite API and the essence of it is simple enough to fit
in a tiny, minimal library if you want. It can be tricky here and there, but
the way it encapsulates state is, for the most part, super predictable. I love
the way you fold asynchronous streams into state and props using tools like
create-subscription so that components don't have to fiddle around with
confusing, long async chains.

For me, Polymer and Web Components were both huge misses - the promise of Web
Components is still neat to this day, but I really don't think I would want to
compose my application out of many Web Components, it just doesn't seem like
the right tool for that job, it seems like a better tool for embedding or
shared widgets. There's really a lot that can be said here w.r.t. Polymer and
Web Components in general but I don't think any of it hasn't been said better
so I'll leave it alone.

Angular 2+ do not do it for me. It is amazingly nice having so much out of the
box unlike React, but at the same time I find myself constantly annoyed. The
NgModule system feels like a relic of AngularJS. When it was standard to
simply concatenate JavaScript files together and call it a bundle, this system
made perfect sense. In the world of ES modules and Webpack, it's just a layer
of needless complexity. The AOT compiler causes all sorts of shenanigans where
valid, obvious JavaScript won't work. I don't really care for dependency
injection, at least not the way its implemented in Angular. It does give you
some neat tricks, but I am happier with my obvious, ugly code, thanks. Even
disregarding modules and DI, I still don't like Angular. My favorite concept
from React is that the tree of components is out of line of the DOM. In
Angular the component is actually in the DOM. This usually only matters in a
few cases, but when it does it's really annoying. Example would be CSS, or
say, if you want a component to be a table row. The way event listeners work
is not orthogonal between child elements and the so-called 'host' element due
to this, as well, whereas in React you can just use HTML-style on event
attributes since you are rendering all of the elements that end up in the DOM
always. Angular's documentation frequently doesn't have example code showing
you how to use things, which may actually be because the developers aren't
sure - I've often tried to figure out how to use basic features only to find
GitHub issues pointing out the severe limitations in them. Like, Angular
Router - What if you want to compartmentalize some routes in a child module?
You could of course just define a Routes[] variable somewhere and import it,
but there is actually a RouterModule.forChild, so surely you can use that? No.
You can only use that if you are using loadChildren, which uses lazy loading.
Lazy loading is actually a PITA especially depending on how you have modules
setup, and the AOT compiler once again does some truly confusing stuff. Like,
you can fake loading something synchronously with loadChildren, but check out
what you gotta do to make it work with the AOT compiler:
[https://github.com/angular/angular/issues/10958#issuecomment...](https://github.com/angular/angular/issues/10958#issuecomment-305604484)
\- Nearly every interaction with Angular beyond trivialities end in multiple
open GitHub issues that lead nowhere, and it's frustrated me like crazy.
Angular also seems to like RxJS, a library I really want to love but can't
seem to quite get there. It's very powerful, but I hate that to get the exact
behavior I want I often end up with quite a long list of operators where the
order can be important in subtle ways. It's easy to leak subscriptions in RxJS
especially if you're new to it. Some things are hard to implement, like say if
you wanted to implement some kind of feedback loop where the result goes back
through. And worst of all, you tend to get RxJS subscriptions and subjects at
the component level at Angular, meaning you've got to deal with these async
values in rendering code, in logic code, etc. Which can cause RxJS to spread
like a virus when all you wanted to do was pull some state in and combine it
with some other state. And if you want change detection to work, there's even
more rules you need to be careful about following...

I've yet to try Ember. I've looked at Vue.js but ultimately haven't been as
drawn in.

...But even despite my preference for React, large apps are _still_ super hard
to structure, and many problems feel unsolved. Like saving and synchronizing
state to a server. There's individual solutions to that problem, but none feel
like they're 'perfect' across all of the domains you want them to be. GraphQL
seems like it could be nice but so far I have been mystified by it in
practice, and longing for better type-safety on both sides. React obviously is
far from perfect, too, and because of its imperfections, you are going to want
a lot of linting to prevent people from shooting themselves in the foot,
especially if you are working on a team. I've never fully figured out unit and
integration testing in React, last I checked the standard was to use Jest and
JSdom and JSdom required native Node.JS modules and bla bla... needless to
say, I was unsatisfied. Because unit test suites on JS apps tend to compile to
one giant bundle, you have a harder time parallelizing work and doing
coverage-based tests.

Organizing components? Smart components vs dumb components? Container
components? High order components? Where to put the Redux reducers and actions
and state? How to split your bundle? Whether or not to split your bundle?
Webpack vs Rollup vs Parcel? I'm barely scratching the surface. Production
frontend apps are insanely difficult and it's fragmented to all hell. I don't
buy in super hard to the JS fatigue thing, but I do think we're very
scatterbrained right now on how to build good frontend apps, and it seems like
it's gonna take a while to fully collect our thoughts and figure out how
things 'ought' to be done. Right now, it's really super all over the place.

So yeah... I think it's OK if you don't know how to write complex front-end
apps without making a mess. I doubt you are alone even among the pioneers.

~~~
crimsonalucard
There is a core issue with UI development that makes things harder and less
elegant than the backend.

It's the io loop. Components must change state and react to state. This where
the complexity arises. If you remove the loop by having components only react
to state, you will find your programs to be simple, modular and more
beautiful.

The feedback loop of IO destroys the functional and modular nature of UI.
Functional programming simplifies programming through restriction, however ui
development is inheritly an object oriented problem due to the IO loop, so the
results of trying to make it functional will have limited benefites.

The way to make UI work is to find a way to have components react to state and
change state in a simple way and without hard coding a refrence to external
state in the component itself. Aka stateless.

Many people believe that passing a closure is the solution. The reality is
passing a closure is awkward and a form of encapsulating state with methods
that leads to the same issues of complexity that you get with oop. Keep data
and functions seperate always, a closure is technically a functional concept,
but it is also oop in disguise as it is instatiating state coupled with a
functions just like an object in oop.

Global event emitters might be the best way. I'm not sure if redux does this.
I'm not a UI guy so everything is just imho.

~~~
np_tedious
I don't think many people actively working on front end will agree with
passing closures as the best way. "callback hell" is a very common complaint.

What you've discussed above seems to overlap pretty well with both redux and
monadic state management like Elm.

~~~
np_tedious
Hmm maybe elm isn't really monads. Tried to bullshit there, my bad.
[https://redux.js.org/introduction/prior-
art#elm](https://redux.js.org/introduction/prior-art#elm)

------
alangpierce
Not to derail the core message, but one learning approach I've enjoyed in the
past is to come up with a list like this and then try to learn a little bit
about all of them. Doesn't need to be deep knowledge, just a basic "hello
world" or equivalent to get your feet wet. It's a lot harder to get breadth
when you stick to technologies that solve a problem you're facing, so
sometimes it's fun to just explore a technology for the sake of seeing what
it's like. Maybe with a more solid basic understanding, you'll recognize a
case in the future where it could be useful or where it would be fun to throw
into a side project. Also, some technologies may stand out as more fun and
things that you naturally want to dig into further.

Of course, that doesn't mean you now _know_ any of these things, but even some
small experience breaks through a psychological barrier, from something
intimidating and unknown to something a bit more tangible.

~~~
cbanek
This!

Also, I find that when I start to learn about something, as long as I'm just
going thru the motions on a hello world, and actually look up what the things
do, I learn the most. Coming in with that beginner mindset you learn faster,
then it's kind of a slow crawl to become an expert. The first week of playing
with a new language / domain / piece of software I think I learn the most.
It's the 80/20 rule at work.

Plus I find just having a small amount of knowledge and understanding where a
piece of technology fits in the greater scheme of things to be really useful.

------
oraphalous
Very surprised that he is not expert at functional programming...

I always assumed that all the folks behind React were driven by a desire to
make web programming more functional generally - that this was an ideal toward
which they thought we should be working. And furthermore assumed that this was
informed by a deep understanding of functional programming generally and the
reasons why it is desirable as a programming methodology.

That inspired me to learn more about functional programming... which
definitely wasn't a bad thing to do.

But I guess I have just been projecting - I have a friend who I've always
considered smarter than me who raves about functional programming... and I
guess I just thought this is what smart people generally have come to realise
is the god's truth about programming.

It's good to know in a way that Dan is not in fact this religious about it. I
wonder how other React devs feel.

~~~
danabramov
I think everybody on the React team is on board with functional principles
(like separating side effects from computation and relying on referential
transparency).

But there’s a reason “deep” functional programming hasn’t gone mainstream —
many people (including me) find it hard to contort their product code to
express their thoughts in 100% functional way.

React has always been about taking the pragmatic parts of FP and making them
easy to benefit from without buying into learning category theory or something
like that.

------
PacifyFish
This is so refreshing. Kudos to Dan Abramov for putting countless cases of
imposter syndrome to rest, at least temporarily.

~~~
alexpetralia
Totally agreed. I feel many engineers feel this way but can't say it. Really
impressed to see the humility here.

~~~
barberousse
Because there's substantially more 'perceived' pressure when you don't know
for a fact that thousands of developers rely on your work or trust your
authority via your follower count. Power absolutely changes one's mental
context for taking action, and Dan Abramov is one of the most empowered people
in the front-end world.

------
sidcool
This is a very good article. What stumps me though is how the 10x
engineers/architects make such sound technical choices without knowing a lot
of things. I perennially feel ignorant of Computer Science concepts that many
others seem to possess. This article helps me to understand it's not only me.
But I would still like to make the best tech choices most of the times...But
the problem is..WHAT TO LEARN NEXT? THERE'S BILLION THINGS, WHAT TO PICK UP?

~~~
commandlinefan
I first started coding professionally in the early 90’s, just as “the web”
started to take off. I found myself surrounded by people who talked about the
network stack all the time; I put together that there was an important concept
called “TCP/IP” in there. So I did what I thought was the most logical thing:
I picked up a copy of Richard Steven’s “TCP/IP Illustrated” and read it cover
to cover. Then a funny thing happened - I found out I actually knew WAY more
about the network stack than all the people around me who were blathering
about it non-stop as though they were experts (which I didn’t and still don’t
consider myself). That experience has made me take other’s claims of expertise
with a grain of salt.

~~~
TeMPOraL
I think a corollary here is that reading a technical book cover to cover isn't
really _that_ hard. Personally I'm trying to make it my default approach for
learning things - books over articles (where that makes sense; books on
continuously changing software are a waste of paper).

------
azizinnnjo
I very much enjoy working as a programmer, but, to be honest, there is
constantly a little anxiety in the back of my mind that I do not get
FP/docker/devops/insert-latest-buzzword-here enough not to look like a
clueless coder in a watercooler-side chat with a fellow. So I really
appreciated this article, it made me feel better about myself :-)

~~~
commandlinefan
It’s deeper than that - you won’t just look like a “clueless coder”, you’ll
find yourself unemployable. I learned early on that it doesn’t matter what
credentials you have or how much experience you have, never admit there’s
anything you don’t know, or they’ll pass on you to hire somebody else who
confidently insists that he does know absolutely every single thing there is
to know. I feel bad for the author of this piece, because putting his name to
this _will_ cost him employment at some point in the future.

~~~
siquick
The author created the key state management tool for one of the world's most
used front end libraries - I think he's gonna be ok!

~~~
pelotom
The idea of Dan Abramov having trouble finding employment is beyond comical.

~~~
commandlinefan
Well, I hope so - the author of Homebrew ended up having trouble finding
employment:
[https://twitter.com/mxcl/status/608682016205344768](https://twitter.com/mxcl/status/608682016205344768).
Stranger things have happened.

~~~
leesec
Getting rejected from a single company does not constitute having trouble
finding employment.

------
29athrowaway
You can make a living as a frontend dev without having to touch those topics
much.

Other devs: desktop app devs, mobile devs, backend devs, devops devs, network
devs, data scientists, game devs get exposed to those a little bit more.

If you are interested in learning a lot of those at the same time, write a
server in C.

[https://beej.us/guide/bgnet/html/multi/index.html](https://beej.us/guide/bgnet/html/multi/index.html)

~~~
guru_meditation
If you are not working on Browser frontend, you will also enjoy the API
stability.

Here's an older verison of the same guide by the same author, more than 2
decades ago:
[https://web.archive.org/web/19970812031954/http://www.ecst.c...](https://web.archive.org/web/19970812031954/http://www.ecst.csuchico.edu:80/~beej/guide/net/)

Amazing how little has changed. I strongly suspect anyone will remember the UI
framework du jour 10 years from now but Berkeley sockets have staying power.
Despite occasional efforts to replace (OpenTransport anyone?).

------
mettamage
I would like a list to see what he does know, according to himself. Somehow I
get giddy making a comparison between what he knows and doesn’t know. I want
to make a mental model of what a real dev looks like, even if it is a biased
one.

~~~
jtolmar
Here's some other senior dev's list:

Don't know: start with Dan's list, it has many similarities. I know more Bash,
but not enough to write a shell script more complex than my aliases file. I
vaguely know z80 and 6502 assembly. I know Java extremely well, but am faking
C++ and C#. I understand flexbox but not CSS floats. I don't even know what
sockets and streams even are in this context, they don't sound like the
sockets and streams I know. I don't know node. I do know graphics and
algorithms.

More don't know: the only front-end frameworks I know are Backbone, raw
javascript, and various immediate-mode graphics APIs. I barely understand the
AWS services I use. I don't understand matrix decomposition and that's
actually relevant to things I do. I have to look up basic SQL commands when
I'm writing it.

Do know: graph search algorithms in excessive depth, sequential Bayesian
filtering in excessive depth, most of 2D graphics, 3D graphics up until you
need to sample the local region in world space, most of procedural terrain
generation, 2D computational geometry, 2D physics, sensor error
characteristics for various sensors, GPS from the high level down to
pseudoranges (but not down to signal analysis), rather a lot about data
formats and compression, video game networking models

The "do know" list isn't exhaustive. The "don't know" one even more so.

~~~
mywrathacademia
From your "do know" list you sound like a video game developer. I would think
that a video game developer would be strongest in C++. Are you telling me your
"do know" list is applied using Java?

~~~
jtolmar
Video games are a hobby, my day job is GPS algorithms. More of the list is
relevant for those than you might think.

Most of my games have been done in Java or Javascript.

------
sp527
This has always felt to me like an inconvenient truth most people are too
uncomfortable to voice aloud. Maybe we all fear that we're the singular
hapless fool adrift in an industry of savants?

~~~
munificent
_> Maybe we all fear that we're the singular hapless fool adrift in an
industry of savants?_

Yes, that's literally the definition of Imposter Syndrome.

~~~
sp527
I think there are several elements particular to the tech industry that
elevates this problem past ‘classic’ Imposter Syndrome. So that label feels a
bit reductionist to me, though not entirely incorrect.

------
yawaramin
Two things come to mind:

> I was considered by all my masters and my father a very ordinary boy, rather
> below the common standard of intellect.

-Charles Darwin

> That any civilized human being in this nineteenth century should not be
> aware that the earth travelled round the sun appeared to be to me such an
> extraordinary fact that I could hardly realize it.

> “You appear to be astonished,” he said, smiling at my expression of
> surprise. “Now that I do know it I shall do my best to forget it.”

> “To forget it!”

> “You see,” he explained, “I consider that a man’s brain originally is like a
> little empty attic, and you have to stock it with such furniture as you
> choose…”

> “But the Solar System!” I protested.

> “What the deuce is it to me?” he interrupted impatiently; “you say that we
> go round the sun. If we went round the moon it would not make a pennyworth
> of difference to me or to my work.”

-Sir Arthur Conan Doyle, _A Study in Scarlet_

------
heydonovan
After reading this, I feel like I've imposter syndrome as well. I know about
80% of those topics pretty well, but I don't think I could ever get a job as a
junior dev. Maybe I focus too much on learning things that interest me, and
not enough on things that land you that software engineer title.

~~~
Aeolun
So the main thing you are missing is the actual coding?

~~~
heydonovan
Hah! Probably. I'd rather learn about distributed systems, the idiosyncrasies
of bash, how file systems work, dive into how http/2 & ipv6 will solve some of
our problems, etc. Absolutely love fixing bugs in code though, but the actual
act of coding an application from scratch bores me. Can't explain it!

~~~
sophiebits
(I manage the React team at Facebook.) This is like me! I love fixing stuff
and enjoy coding from scratch much less. I don’t have specific tips for you,
but I promise it’s possible.

------
akhilcacharya
I was __really __surprised to see algorithms on this list. I would have
presumed everyone at Facebook would be a cover-to-cover expert at the sorts of
algorithms you 'd see in coding interviews.

~~~
plahteenlahti
According to his tweet [1], there is a separate hiring track for front end
engineers that does not include that much algorithmic knowledge. I was
surprised too.

[1]
[https://twitter.com/dan_abramov/status/1078658656344903683?s...](https://twitter.com/dan_abramov/status/1078658656344903683?s=21)

~~~
RonanTheGrey
Facebook can afford (nay, NEEDS) to rise to that level of specialization. But
that's only going to be true at the level of a megacorp, like Facebook, or
Google, or Microsoft.

For even moderately sized companies, someone with wider knowledge will fare
better, because such companies aren't going to spend $500k/yr on someone who
doesn't know algorithms (or on someone who ONLY knows algorithms). The
marginal cost to Facebook is near zero, the marginal cost to a smaller company
certainly is not.

~~~
danabramov
To be clear, once you get in, there is no actual distinction. People can
choose any team, and "front end" people sometimes work on the backend or
mobile or services or IDE or a compiler, etc. We try to hire generalists.

------
palerdot
This is the most inspiring article of 2018, both in tone and content. Huge
thanks to Dan for this writeup.

------
henrikeh
A really curious aspect of this list is the “scale”/depth of the various
topics. Some are very specific: “Node backends”, “GraphQl”; some are very
general: “algorithms”, “functional languages”.

It is well established that “knowing more” is not really a thing; we just
learn to further understand relations and distinctions, feeding our ability to
know of more things we have yet to learn.

------
pepijndevos
What I miss from this article is what he does know. Not to boats, but to
contrast. I know some of the things he does not know, and I'm sure he knows
things I don't know. But without knowing what his expertise is, it's easy to
think you know more than him.

~~~
alexdowad
This. Never heard of Dan before today. Now he is "a guy on the Internet who
writes about programming but doesn't know much about it".

~~~
douglaswlance
He invented Redux, and is a core contributor to React.

~~~
irq11
Honestly, hearing that a core contributor to React doesn’t know much of
anything about basic engineering topics is disheartening, not encouraging.

Not memorizing the algorithm book is one thing, but being considered a
“rockstar” when you don’t know basic sorting algorithms...

~~~
rpeden
Consider that actual rock stars often aren't the world's _best_ musicians from
a purely technical perspective - but they're experts at delivering what their
audience wants.

Dan made a bit of a name for himself in a couple of ways I can think of:
creating a very popular library (Redux) and communicating extremely well in
English about React and Redux.

"Able to communicate about with a broad audience about complex technical
topics" is a skill I wish more developers had.

So he's able to create things his audience wants and then communicate to his
audience about those things. Sounds exactly like a rock star to me.

That's meant as a compliment, not an insult. The ability to communicate well
and the ability to be honest about you don't know are two things the developer
community needs more of.

~~~
irq11
I’ll grant you this: unless you’re actually playing music to sold-out
stadiums, “Rock star” is an insipid, meaningless phrase. I’m not trying to
debate the definition. Likewise, I’m not interested in the technical
qualifications to be a “communicator”. There are clearly few technical
standards for fame.

In every other field of engineering, there are standards of knowledge and
competency. Software is notable, in that not only are there _no_ standards,
but we actually see the glorification of ignorance of even _basic_ knowledge.

There are lots of bad, popular github projects (particularly in the JS
universe, where the bar for competency is already quite low) and having a
popular project is not prima facie evidence of engineering skill (how many
projects was the string-reversing NPM module breaking, again?) Which is to
take nothing from the author; I don’t particularly care about his level of
skill, nor am I saying his projects are bad. The argument is not about the
author.

What I care about is when someone says _“hey, I’m ignorant of the basics of
the field in which I work, but it’s OK, because I work on a big, famous
project.”_ , and people interpret that to mean that _their_ ignorance is
dandy, too. There are dozens of comments to this effect on this page (cf every
comment that mentions “impostor syndrome”)

It’s OK to not know things. It’s OK to be a beginner. It’s _not OK_ to excuse
yourself from knowing things you really should know as a professional, because
someone else got famous without that knowledge.

~~~
electric_sheep
Way I see it is it's more than OK to not know things -- it's a necessary
optimization. Engineering is all about tradeoffs, and skills development is no
exception. Follow one path, forego another; dive deep, sacrifice breadth (and
vice versa).

So consider that maybe, just maybe, for a developer working full-time on a SPA
framework, not knowing Docker or Bash scripting might not be a real impediment
to working effectively or delivering quality product. If it were, perhaps
React & Redux wouldn't be as great as they are. And since they _are_ great,
maybe we should consider that fact not as a celebrity get-out-of-jail-free
card, but as counterevidence to your implication that these topics all
constitute a universal educational imperative, and that someone lacking in any
of these areas is by definition not a professional in the software field.

------
matchagaucho
There's a risk of being a _" Jack of all trades, master of none"_ in Software
Engineering.

Companies pressure Engineers to be "Generalists" because it lowers salary
rates and makes people more replaceable. But it's the Specialists (like Dan)
that drive actual innovation.

~~~
ahoka
What about 'T-shaped' people?

~~~
munchbunny
I bet if you got fifty programmers (as a representative sample) in a room and
asked them to define "T-shaped" you'd get a wide range of answers that
generally reflect a T shape but don't really align on what the horizontal part
should be.

------
yawaramin
Hi Dan, I'm surprised and amazed by your patience and cool-headedness here. In
my opinion that's the foundational quality of every good developer, everything
else comes out of that. Seeing your replies here tells me all I need to know.

------
Tade0
This piece made me realise one thing: the most valuable part of my knowledge
is not systematized.

To put it in a different way: If someone asked me what I _know_ I couldn't
show it in any other way than "watch this".

------
nikivi
Great post. I tackle the problem of being aware of things I don’t yet know or
fully understand by maintaining an [open Trello
board]([https://trello.com/b/cu32qF3q](https://trello.com/b/cu32qF3q)) that
lists topics I want to learn in a visual way.

I then mark off topics I am focusing on learning now and topics I want to
learn ‘Next’. This helps me greatly. I also try to learn things in context of
projects I am working on and the direct knowledge I need to solve the problems
I have.

------
benjaminsuch
I love Dan. One of very few developers I really admire. And it's quite nice to
see that we have very similar knowledge gaps.

------
Apreche
I don't know anything about the person who wrote this, but I know almost
everything they don't know. Am I a much better programmer/engineer than I
thought?

~~~
kojeovo
You're either way more knowledgable than most, or there's a bit of Dunning-
Kruger in play. Hard to tell. What you know is only a small part of the game
anyways.

~~~
throw20180103
To be honest, this article scares me from using react/redux, because the
author don't know how types works.

(I can't be the only one)

~~~
freehunter
I will admit I am a terrible programmer, but I will say using Redux scared me
away from using React at first.

Maybe my React needs are minimal, but I tried following a tutorial using React
and Redux and I was immensely confused. Once I struck out on my own and
ditched Redux for just straight React, everything became so much clearer and
simpler.

~~~
acemarke
Hi, I'm a Redux maintainer. Anything specific that confused you? Which
tutorials were you looking at?

We're currently planning a revamp of the Redux docs. I'd really appreciate any
feedback on what things caused problems, so we can know how to make the docs
better.

Feel free to comment here, or ping me on Twitter or in the Reactiflux chat
channels. I've also got a survey open asking for suggestions on docs
structuring:
[https://docs.google.com/forms/d/e/1FAIpQLSfzIkY3fXZ8PrQKScYM...](https://docs.google.com/forms/d/e/1FAIpQLSfzIkY3fXZ8PrQKScYMK0YoEgALfAK2qQ0mOj1_ibKv2qDTuQ/viewform)

Also, fwiw, you may be interested in my suggested resources for learning
Redux:

[https://blog.isquaredsoftware.com/2017/12/blogged-answers-
le...](https://blog.isquaredsoftware.com/2017/12/blogged-answers-learn-redux/)

~~~
askmike
[not OP but I can remember feeling the same, also I haven't done a big redux
project in about a year]

I haven't looked at the docs in a while but I'm not sure that's where the big
problem lies. The hard thing about Redux is that you need to "get" the core
concepts (not that complex), and how they interplay with how (and when) React
renders component subtrees (very complex - this requires a new understanding
of react you didn't need before).

After you learn React and finally "get" it you definitely won't get Redux. Not
because of Redux perse, but because the way you structure your application is
so different. After that you'll encounter more subjective questions like do we
put this (semi localized) state in Redux? And there are no right answers
anymore, just opinions.

Also the boilerplate doesn't help.

~~~
acemarke
Yeah, the docs can't solve everything, but I'm hoping we can improve the
structure, the content, the reading flow, and how the prerequisite concepts
are handled.

As part of that, I definitely want to have new category sections on "Using
Redux with a UI" (which would include both how that works in general, and
specific pages for use with React, Angular, Vue, Ember, etc), and "Real World
Usage" (which could cover things like app structure, code splitting, choosing
a side effects approach, and so on).

As for the "boilerplate" line... everyone throws around this word, and
everyone means something different. Could you clarify what specific things
you're thinking of when you say that?

FWIW, we have a new package called `redux-starter-kit`, which is specifically
intended to help simplify several common Redux use cases. It includes
utilities that help with store setup, reducer definitions, immutable update
logic, and even creating entire "slices" of state automatically without having
to write any action types or action creators yourself. I'd encourage everyone
to try it out, and let us know how much it helps improve your apps and what
else ought to be included:

[https://redux-starter-kit.js.org/](https://redux-starter-kit.js.org/)

~~~
askmike
> As for the "boilerplate" line... everyone throws around this word, and
> everyone means something different. Could you clarify what specific things
> you're thinking of when you say that?

As stated before I haven't done a big JS project for about a year now. In the
last project I did we used redux in a create-react-app. At the time the best
practice was creating presentational and container components[1].

The biggest boilerplate was:

\- Whenever we added a react component (presentational) we would need to
create a container component to wrap it in, this would always result in ~20 or
basically the same lines (in our project we did things pretty verbose, so we
didn't have a HoC or whatever people use).

\- "immutable update logic", reducing deeply nested objects is a pain an error
prone (using es6 spread or Object.assign), I've heard about some libraries
that can help with this, but we didn't use anything at the time).

> FWIW, we have a new package called `redux-starter-kit`

I am most definitely going to use this for an upcoming project!

[1] [https://medium.com/@dan_abramov/smart-and-dumb-
components-7c...](https://medium.com/@dan_abramov/smart-and-dumb-
components-7ca2f9a7c7d0)

~~~
acemarke
FWIW, I've always felt that having duplicate / parallel "container" and
"component" folders/files just for the sake of separating them is completely
overkill. Most components are only connected once - just do that in the same
file and export the plain and connected versions separately. I wrote some
thoughts on that here:
[https://gist.github.com/markerikson/ea312b5ee398627ffceb09f8...](https://gist.github.com/markerikson/ea312b5ee398627ffceb09f89904831f)

Similarly, I'm actually thinking that in the upcoming Redux docs revamp, I'd
like to have the tutorials and examples switch from a "folder-by-type"
approach to either a "feature folder" or even a "ducks" approach, and maybe
even cut down on having separate action constant variables. There's valid
reasons to do things in multiple files, but it's also not _necessary_, and I
want to simplify things.

Yes, I totally agree immutable update logic is a pain to write and write
correctly, which is why Immer is awesome, and why the starter kit uses Immer
internally. My only concerns are that the code _is_ mutating unless you wrap
it in RSK's "magic" `createReducer` utility that uses Immer, and it's going to
be hard to figure out how to teach this properly. But, in terms of LOC and
simplicity, it's a huge win.

Please let me know how well it works for you, and if you've got any other
suggestions for what it should include!

~~~
askmike
Ah yes Immer is the framework I read about a few months back but couldn't find
anymore. Thanks for reminding me.

> My only concerns are that the code _is_ mutating unless you wrap it in RSK's
> "magic" `createReducer` utility that uses Immer, and it's going to be hard
> to figure out how to teach this properly. But, in terms of LOC and
> simplicity, it's a huge win.

It's only a win since we decided that "mutation is bad" and we had to do
spread notation gymnastics in all our es-2025 code that we are compiling to
es5 anyway. From an abstraction point of view this is how I feel consensus
about state management changed over time in the frontend world (or the
part/frameworks I was involved in):

\- 2010: jQuery will help you update the DOM anywhere (looking at IE6) - but
you have to solve state yourself. A deeply nested object attached at `window`
was considered best practice.

\- 2012: We need to manage state properly, here is a nice Backbone "model"
class: pass it a schema and use getters/setters to update so you can glue
state change events to your view logic.

\- 2014: Angular (first version) is great! Don't worry about managing your
state yourself, just attach whatever you want to $scope and we will simply use
dirty checking to check everything whenever something changes.

\- 2015: React uses a vdom which behaves similar: change whatever you want and
keep rendering it and React will figure out what actually changed. And for
your state we made this flux thing which you implement as a bunch of different
data stores (in my mind similar to backbone models except they only go "one
way").

\- 2016 (redux): here is a single store that also flows one way. Oh yea you
need to do everything functional and you can't mutate any objects anymore or
things will break. These 20 lines of code show you how to change the property
of object with another property called id with value "x" in a nested list.
This is better because it makes diffing faster in the vdom. You have to make
sure you never mutate so here is a way to "freeze" your objects which will
make sure you don't do this.

\- 2017 Immer (I haven't used this yet): We realize it's a pain to change big
objects if you can't mutate, so here is a dummy object you can mutate, we will
clone it to make sure it's a different object. This is a proxy to the objects
that will end up in your store (and exposed to your view layer).

I understand how we got to needing Immer, but it's a solution to a problem we
only have because of how frameworks like React figure out what changed (strict
equality). But it's too verbose and error prone for us to do manually. React
only got designed as it did because too many people got tired of OO style
state management. Right now I'm noticing a lot of people are getting tired of
the verbosity, boilerplate and complex abstractions that come with doing
things the "proper React way" (updating state represented in an object is the
main example here, but that whole chain is verbose: you need to create actions
you can dispatch, you need to write a reducer to catch those actions and
mutate your objects, you need to glue the correct state to each component).

React is great tech, but in a lot of ways it's a counter movement. Countering
complexities you get when managing state the OO way. But now it has gotten
very complex itself, we now need a solution (immer) introduced by a solution
(redux) that was needed to manage state inline with React. In other words,
also very complex.

It feels almost as if I took the Backbone code, renamed it and marketed as "a
simpler way to manage your UI" I could get a lot of people to switch away from
React + redux + immer + immutable + redux-thunk + etc...

~~~
guru_meditation
I wish we had more historical overviews like this.

The number of new developers has been outstripping the number of old
developers in most environments and this has been happening for at least the
last 15 years.

Thus, we come back to Richard P. Gabriel's Worse is Better, or at least the
essay's focus on the importance of social components of a project[1]. N.B.:
not implying Redux is worse than any of the other discussed projects.

Newer generations cannot possibly have the time to go through the history and
tradeoffs of various frameworks that used to be extremely popular and the
reasons people moved on. Too many previous frameworks and too few posts like
what you just wrote. Besides, where to start? It's not like TAOCP is going to
have a chronology of Browser UI frameworks.

Instead, the tendency is to leverage the rapidly developing ecosystem and work
with the projects that have the largest numbers of stars on github, etc.

If you are a very large well heeled eng. organization with a capability to
enforce the use of particular frameworks, it is in your interest to popularize
them. You will pay and encourage your engineering org to, among other things
they do, market it to the dev. community. If there are enough engineers in
your org (say: tens of thousands), you will begin exerting a tremendous
concentrated influence on the Open Source community.

At the same time, for everyone else who does notwork inside a 10K+ engineer
org, the lack of future maintenance and upgrades presents such a huge downside
risk to not using the most popular open source frameworks. The open source
community moves so quickly that you run into the risk of being stuck with
maintaining the reusable components you plucked from other open source
efforts.

The backwards compatibility guarantees are so much lower than what they used
to be. The browser world is still figuring out how to link dependencies[2],
let alone generate a stack that is stable enough where you don't have to
continually update your UI codebase if you want to keep continuing to reuse
other people's widget code.

So you tend to stay with the pack. React is the new most popular thing? OK,
let's do React. Redux is the new way? OK, Redux. Pick anything else and you
risk being stuck with a stack that rapidly loses the ability to interoperate
with a huge majority of new Browser UI open source code.

[1]
[https://en.wikipedia.org/wiki/Worse_is_better](https://en.wikipedia.org/wiki/Worse_is_better)

[2] [https://medium.com/webpack/the-state-of-javascript-
modules-4...](https://medium.com/webpack/the-state-of-javascript-
modules-4636d1774358)

------
aaronfc
To be honest, knowing your limitations that well is a ver good thing. Probably
many people would say "yes, I know" knowing not much more than what he
summarized for some of the items of the list with just a few words.

Didn't know him, but I like him now.

~~~
_trampeltier
Wenn du weist, dass du nichts weist weist du mehr als wenn du nichts weist das
nicht weist.

If you know what you don't know anything, you know more than if you don't know
anything and you don't know.

------
kimar
Could it be that Dan's personal threshold for "knowing" things is just higher
than that of most of us? Surely there are things on that list which he could
pick up effortlessly if need be (eg: flexbox, sass).

------
in38years
Knowing what you don't know is better than not knowing what you don't know. It
shows a wide breadth of knowledge and I suspect that with the desire and time,
you could become an expert in any of these things.

------
Walkman
I know most of these things in detail, I can understand them and use most of
them daily. I know NOTHING about JavaScript at all. It's ok, you work on
frontend, I'm on backend.

------
yangshun
The author, Dan Abramov, is a really smart, great and humble guy who has had
immense contributions to the front end ecosystem and community.

It's interesting that people who don't know that will view that post
negatively but people who know what he has accomplished would be inspired by
it.

To end off, pay your respects at: [https://dan.church/](https://dan.church/)

------
giminoshi
Read this entire thing without realizing it was freaking DAN ABRAMOV. This is
a weightier article than I realized. WOW.

------
I_am_tiberius
I thought Dan wrote react dnd in typescript.

~~~
acemarke
Nope. Dan wrote it in JS originally, then handed off maintainership of it a
while back (possibly before he wrote Redux in 2015). Looks like it may have
been ported to TS this year: [https://github.com/react-dnd/react-
dnd/pull/1017](https://github.com/react-dnd/react-dnd/pull/1017)

------
tigershark
It’s kind of scary that Dan Abramov doesn’t know about ML languages or
typescript... I hope that he is just being humble, because otherwise I wonder
if it was a complete lie when Facebook said that they were pushing on ReasonML
instead of react.js. I know that he was not initially involved and that the
first prototype used ocaml as a primary language before falling back to
JavaScript. I really appreciate Dan work and his multiple and very helpful
posts, but as someone that enjoys functional languages and hopes to see a full
featured ML react, or at least a full support for typescript, I really hope
that Dan can see the advantages in the “functional way” given that he is now
one of the main actors.

~~~
danabramov
I think you’re a bit confused here. Facebook isn’t “pushing” anything.

There’s a React team. I’m on that team. We develop React. Facebook uses it all
over the place.

There’s also a Reason team. (Its creator also wrote React originally.) They
work on Reason and its React bindings. Facebook uses it in some places.

We talk to the Reason team of course. But there has never been a plan to force
all React users to use Reason. I don’t know where you heard that. If you like
it, that’s cool. If not, that’s cool too. We’re just sharing what we use.

I’m not sure what your practical concerns are (are Reason bindings or TS
typings not good enough?) but I’d like to hear them!

Of course I know “about” ML and TS. If I didn’t know about them I wouldn’t
mention them. :-) I haven’t developed anything meaningful in either of them
but it’s not like I’m clueless about what types are. I’ve been using C# for
years.

~~~
tigershark
Thanks for your answer, I think that at the time of ReasonML presentation and
a couple of other times I had the impression that there was quite of a push on
that direction, but I may be wrong.

~~~
danabramov
There’s not really such a thing as a “push” at FB — each product team is
independent and decides what to use based on its own criteria. So there’s
never an org-wide mandate to adopt a certain technology. Reason has some
adoption but it’s happening organically.

~~~
guru_meditation
IMHO, teams using a certain stack have agency to see that stack win the hearts
and minds of other developers.

Additionally, the opinions of popular leads, managers etc on what should be
used will count more. Winning their mindshare will win you a lot of FB org.

Winning a lot of FB org will exert a tremendous influence on the Open Source
community as you now have large numbers of engineers working on open source
projects on premium pay.

I believe this is how it works in most modern large engineering orgs. After
reaching a certain critical mass of adoption, a team will be hard-pressed to
use anything else, especially if reusing other team's components requires you
to master, say, Redux anyway.

------
dennisgorelik
Dan Abramov lists things that he knows at least a little bit.

He, obviously, does NOT list things that he does not know at all. (How can you
describe something that you do not know?)

------
simplecomplex
Sometimes there’s an unrealistic expectation that engineers know everything,
but senior engineers I’ve worked with and hired knew most of that list... at
least somewhat.

Yes, comfort with bash and a knowledge of how networking actually works is
something I expect someone working on computer software for 10+ years to have
gotten familiar with _at some point_.

I also expect people who build libraries inspired by prior work (FRP) to
actually learn a bit about the prior work. I’m surprised he has not dabbled
with functional programming.

~~~
Spearchucker
It would be great if we all met each others' expectations. And yet it doesn't
work that way. A step up from where you're at is to realize that tech, ANY
tech, is easy. If brute-forced by rote it can be even be learnt by those
without the aptitude.

What IS difficult to master, is people.

~~~
simplecomplex
No, tech is not easy. I dont think I’ve met a software engineer in my entire
20 year career who would characterize programming as “easy”. I don’t think of
law, medicine, and architecture as easy either. I’m sure I could have been an
architect, if I spent years learning it like I did programming. But that
doesn’t make it easy.

Software engineers command huge salaries because it’s not easy. Just because
anyone can learn anything doesn’t make everything is easy.

I don’t understand why tech celebrates amateurism and ignorance... We don’t
all know everything but we shouldn’t wear our ignorance like a badge of honor
either.

~~~
Spearchucker
Mastering tech is easy relative to mastering people. I know. I've done the
former for 32 years at companies like Microsoft and Nokia. Still learning the
latter. Not sure how this celebrates amateurism or ignorance.

------
miguelrochefort
That's pretty much exactly the list I would come up with myself.

I'm very surprised by how accurate this is...

------
Abimelex
Similar here, just bookmarked it as TODO for 2019 :)

------
lucb1e
> serverless

Have you ever used shared hosting or know how this works? Then you can cross
this off.

~~~
k__
Shared hosting includes automatic capacity scaling and on-demand pricing?

~~~
naniwaduni
For most use cases, the required capacity ranges from zero to still small
enough to fit on a single host.

Any half-decent shared host ought to be able to scale you at least as far as a
single database server on commodity hardware will suffice.

~~~
k__
Not the answer to the question, but you're right.

------
guelo
Is that guy really an experienced developer? He's obviously talented but
experience and talent are different things. It sounds like he has less than 10
years under his belt.

~~~
danabramov
I’ve been learning programming since 12, got first software job at 18. I’m 26
now. So depends on how you count.

~~~
guelo
And not that many technologies.

~~~
danabramov
No, not that many. I've worked with C# and .NET ecosystem (WinForms, ASP .NET
MVC, NHibernate, EF, MSSQL), later Django/Flask/Python, later Xamarin/Cocoa
and Rx, yet later Backbone, AngularJS, React. Haven't worked with low-level
stuff at all.

~~~
guru_meditation
I would say that in this particular domain going from:

WinForms -> ASP .NET MVC

and then

Backbone -> AngularJS -> React

(including participating in React development) gave you the kind of exposure
and experience you needed for Redux.

I think a lot of people reading on here missed this parts and I certainly
didn't catch onto this reading your Things I don't Know as of 2018 post or the
"Things I do Know" post you linked to.

------
anonytrary
> People often assume that I know far more than I actually do. That’s not a
> bad problem to have and I’m not complaining.

It is also not a good problem to have, either. There will always be a few
people who think you know everything, and a few people who think you know
nothing. The only plausible reason why everybody would think you know
everything is that you act like you know everything around everybody. Put
differently, if most people think you know more than you do, it would imply
that you are not very humble in your interactions with most people.

> Folks from minority groups often suffer the opposite bias despite their
> hard-earned credentials, and that sucks.

Does it suck, though? It is much better to be underestimated than to be
overestimated. I've read a lot of Dan's articles. He offers a lot of
interesting insight and advice in pretty much every article he's written. The
guy comes off as a know-it-all! Not saying it's bad, but it something to
introspect on if you constantly find people overestimating your abilities.

~~~
thatswrong0
I wouldn’t say he comes across as a know-it-all.. everything he’s written that
I’ve read has to do with React or a few closely related subjects. And his
writing never has a tone of superiority or “this should be obvious” that is,
IMO, a requirement to be a know-it-all

I personally kind of figured he knew a lot about everything Webdev related
since he knows so much about React, but that’s obviously not the case now that
he’s listed all that out. In fact, now I don’t feel like the extent my
knowledge is as limited as I did because I have a basis for comparison! Which
I.. figure might be the point of the article?

------
new_guy
There's three kinds of article you can write:

1, things you know about

2, things you don't know about (this article as an example)

3, things you don't know you don't know about (hackernoon and medium are full
of this kind of c*ap, people creaming their pants over switching their
computer on for the first time)

There's absolutely zero value in the last two, they add so much noise and
worse they make the author look like a complete idiot, even if they're not. I
genuinely don't understand why people are so insistent on broadcasting their
ignorance/stupidity though?

The only article of worth is the first kind, writing about your subject area,
that adds value and is how people learn.

~~~
josephpmay
It's interesting and notable because of who wrote it. The author created one
of the most-used programming frameworks, yet there are a lot of things he
doesn't know. This type of article can actually be super helpful for people
with impostor syndrome, as it shows that you don't need to be an expert in
everything to create work that millions of people use and love.

~~~
anonytrary
> The author created one of the most-used programming frameworks, yet there
> are a lot of things he doesn't know.

There are far more accomplished people in the world who know far less about
far more topics. This case doesn't seem particularly extraordinary.

~~~
vfinn
Why does it have to be the most extraordinary thing? The article was really
surprising to me, and it made me feel less bad about my own gaps.

