> 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/.
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!
Same with enterprise software development. It's kind of neat that the world of software engineering is so big that one can go 20 years into their career and be totally experience-deficient in large spaces of the industry.
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... - 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.
- create-react—app or Parcel bundler, both of which require zero config. CRA is easiest but I’m not a fan of their defaults for Typescript (which is to prevent the app loading in dev if you have any tslint or compiler errors, even if they are just warnings) so once I’ve messed around fixing that, it’s almost just as easy to use Parcel.
- For website projects, I use react-static as a static site generator as it can handle all your data loading, bundle splitting, server side rendering, etc. for you automatically. It’s best to start your project with react-static rather than retrofitting it, they have a command line tool to set up a new project so this is usually instead of CRA/Parcel. Gatsby is probably an equally valid choice, react-static seemed a little simpler to me and I’ve been happy so far but Gatsby community seems larger.
- I’ve not used Redux for a couple of years now, instead using MobX for application state. Personally I find it so much quicker and easier to use, although it is undeniably more “magic”. Honestly think this is one of the biggest productivity enabling changes I’ve made since switching to React.
- Personally I’m a fan of Typescript, while it can be a bit of a pain initially, I think you reap the rewards as a project progresses in terms of ability to refactor easily and avoid wasting time on syntax errors.
For example, I had a little game where initially I wrote a React+ecosystem solution that worked. Then, considering that I don't need x updates per seconds, I switched to server-side rendering + morphdom.
As a result I could reduce all my code to 1) websockets messages to the server and strings of markup from the server, and 2) a few 'optimistic updates' on the client-side by directly changing the DOM. Having no more client-side state to maintain really simplifies things.
Considering that this was a viable solution to a game that has to update the DOM on pretty much every click (but no more than that), it's probably a fine solution to the vast majority of apps I build.
I can't wait for Phoenix LiveView to make this kind of solution less ad-hoc, but at least so far even the ad-hoc solution is so much simpler...
I can understand you’re opinions about the module system, but I disagree. For a small to medium size app it can seem like annoying boilerplate that gets in the way. If you’re working on a large app across multiple teams then it’s very helpful. You have a single entry point for all relevant code. You can define the api for that module so other teams don’t misuse what you have built. It can get frustrating when you have a single component that you want to share and you need to wrap it in a module, that feels very unnecessary, but I know the angular team is working on that.
I actually really like that my components are in the dom, I can see clearly where it is, not which div with which class or Id it is. It makes inspecting the tree very easy.
RxJS can be difficult and hard to learn, which doesn’t help that the docs are meh and you can never find exactly where to go. Juniors really need someone to help them not leak subscriptions. Though if you follow Angulars promoted idea of using the async pipe, then that will automatically clean up your subscriptions. Again, for small components/apps it feels way overkill, but it feels oh so nice when your trying some complex async stuff and can handle it and pass it along so easily.
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.
I was formally educated to do low level development, did operating systems, hardware design, and communications for a living for 15 years. During that time I also learned and regularly used FP, data processing, windows GUI, full stack web development. Every year I pick a new tooling language so that I'm not completely tied to one language or paradigm. Every time I have an opportunity to use the right language or tool for the job I learn it and use it.
The whole point of my education process was not to learn C and Assembly, it was to motivate me to he constantly learning. When I wanted a new job I created a "real world problem" to solve, did actual design docs, took courses online, read books, etc. Was able to get a new job in a completely different field, doubling my pay and reducing my work load. That's all due to the fact that if I had a list of stuff I didnt know I'd be out there learning that stuff every waking minute.
I would immediately try to get you fired for lying about your knowledge and qualifications.
One of the best possible things you can do is admit when you don't know something. That should always be safe to do at any GOOD employer.
The rest of his blog so far is basically about things he does know.
If someone non-junior knew no shell scripting and had no FP knowledge — or thought that JavaScript counts as FP [spoiler alert: it doesn’t] — I wouldn’t hire them.
Maybe you can read some other articles on the blog (it’s new so there’s not many) to get a sense of my interests.
I also have a StackOverflow profile: https://stackoverflow.com/users/458193/dan-abramov
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.
EDIT: In another comment Dan himself mentions that Facebook tries to hire generalists.
Most technology companies are also terrible at explaining what they do so you need to be able to do a bit of reading to understand their value proposition. For example Docker, their website's homepage states.
Future proof your Windows apps and drive continuous innovation Protect your legacy, invest in your future.
Which is techobabble nonsense, and doesn't tell me a fucking thing about what Docker does. Docker isn't just for windows apps, so I don't know why they are alienating linux users. It makes no sense, and I would assume most people would move on unless they already knew what it was. This is sad, because I like and use Docker and want them to succeed.
How I would describe Docker to the uninitiated. Docker is a file. In that file you can run a series of commands to install and compile all the software necessary to run your application. Once you execute the file, it outputs another file which you can send to someone else who will automatically know how to run it. That's all it is, there is no reason for confusion.
My point is that knowing 20 different programming languages did not make me more successful or better. This guy kind of sort of knew one language and was crushing me in sales.
On an unrelated note, I knew a guy that knew every new tool and language under the sun. Was always learning the latest thing. Terrible engineer —- everything too complicated and abstracted. Hard to follow, hard to work with.
I don’t believe knowing more necissarily makes for a better enginner at all.
(I can't be the only one)
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.
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.
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.
I think there’s an interesting point in there as to the attributes needed to build something new vs scale something existing to a new level. They’re both clearly great at the things they seem to prefer doing.
Yes, that's literally the definition of Imposter Syndrome.
What do you consider "actual coding"?
If, for example, you need to hash/salt passwords correctly and you haven't done that lately, even if you remember for certain how to do it, you should look it up to see if the best method has changed in the last year. Knowing algorithms off the top of your head might almost be a negative, if it makes you less likely to check with a bit of research first when it's time to use one.
[1] https://twitter.com/dan_abramov/status/1078658656344903683?s...
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.
I would say someone with 5 years experience could be senior to someone with 10 years under their belt, granted the former worked on the right projects that gave them valuable experience, with some combination of design, understanding trade offs, implementation, and social/management skills managing delivery of their features or taking complexity and simplifying it (both technically and from a requirements perspective). You could work 10 years and not hit those points.
I expect someone with 10 years is hands down more experienced than someone with just one year under their belt, but otherwise, looking at how long you’ve been in the industry is kind of meaningless without understanding what it is that you did.
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.
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?
Being constantly underestimated probably doesn't feel so great when it's hard to find employment or when people don't respect your technical opinions.
That's the mainstream narrative as regards to minority groups in tech :-)
I too am not convinced that being underestimated sucks. Being overestimated may be stressful when you keep trying to fit the image that others may have formed of you and to meet their expectations. When underestimated, the most likely way is upwards, towards greater appreciation; when overestimated, one quite possible way is downwards, amid general disappointment of those who had higher expectations of you.
I am not sure which is better.
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.
There are far more accomplished people in the world who know far less about far more topics. This case doesn't seem particularly extraordinary.
1. In this article, the author says that he does not know streams. Now, when he learns it well, he can write about "How he learned about streams", and a beginner would empathize more with this article rather than some expert ranting about it in their blog. 2. It is inspiring for the readers. It sends a message: "If you master one skill and master it well, you can still add a lot of value to the world. Knowing everything in the field is not really important". 3. Many people write not just for others, but also for themselves. Making your insecurities public is a good way to acknowledge and face them.
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.
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...
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?).
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.
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.
What IS difficult to master, is people.
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.
Have you ever used shared hosting or know how this works? Then you can cross this off.
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.
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.
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.
Didn't know him, but I like him now.
If you know what you don't know anything, you know more than if you don't know anything and you don't know.
> 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
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.
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".
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.
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/
He, obviously, does NOT list things that he does not know at all. (How can you describe something that you do not know?)
I'm very surprised by how accurate this is...
