[HN Gopher] Things I Don't Know as of 2018
___________________________________________________________________
Things I Don't Know as of 2018
Author : gurjeet
Score : 133 points
Date : 2020-11-26 16:18 UTC (6 hours ago)
(HTM) web link (overreacted.io)
(TXT) w3m dump (overreacted.io)
| nemo1618 wrote:
| I'd love to see lists like this from more high-profile
| programmers. What does John Carmack not know? What does Dan
| Bernstein not know? What does Bryan Cantrill not know?
| myth2018 wrote:
| > What does John Carmack not know?
|
| As of 2014, relational databases.
|
| https://mobile.twitter.com/ID_AA_Carmack/status/457916010234...
| watermelon59 wrote:
| 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 :)
| enriquto wrote:
| It's not only a matter of usage. Many good programmers will
| argue that "actual debugging tools" are mostly useless and
| that logging the execution of your program is a more
| productive use of your time. In some sense, time spent inside
| the debugger is lost forever. On the other hand, the time
| spend writing good logging code is really worth, and will be
| especially helpful to detect future bugs that you have not
| yet written.
|
| I'm not a good programmer, but I can say very proudly that
| I've never used any debugger (except for assembly language,
| where the debugger is more like an interactive shell).
| Drdrdrq wrote:
| Not a big name myself, but I'm always surprised that this
| surprises people. I mostly use print statements, simply
| because a) every environment has them, b) there is much less
| (none) fiddling involved to set them up, and c) because
| debugging is rarely needed anyway, assuming you are working
| on your own / your team's code (and that you are half good).
| I think the last time I have used a debugger was on what I
| think would be a definition of spaghetti code - not proud of
| it, but I did learn not to do that. :)
| Tainnor wrote:
| This is interesting, I use the debugger a lot, in whatever
| language. I've debugged with CLI interfaces and I've used
| IDEs.
|
| I don't want to claim this is superior to printf debugging,
| or whatever other technique. I just like seeing the code
| executing, and debugging some weird error can sometimes be
| an almost relaxing activity, as you just step through the
| code one by one and try to keep track of what's happening
| without needing to think more than 2 or 3 steps ahead.
|
| That said, I'm also the guy who will happily put
| breakpoints into internal framework code (e.g. Spring Boot)
| so that I can understand why the framework doesn't do what
| it's supposed to do. Usually, I find the answer, although
| maybe in some cases it would have been more economical to
| use a workaround instead, but that would leave me
| dissatisfied...
| hamburglar wrote:
| I rarely use the debugger in highly async systems (e.g.
| node) because it's just a mess, but in C/C++/Go/Java
| where there actually are good debuggers and you tend to
| have chunks (e.g. entire functions) of synchronous code,
| I find it very, very helpful to step line-by-line through
| most nontrivial code at least once for any major code
| path. A long time ago, I had a sort-of mentor who,
| whenever he looked at new code, asked the author "have
| you single-stepped through it yet?" so I did it to humor
| him, but the number of times I caught errors was eye-
| opening, so to this day I still like to do it.
| renewiltord wrote:
| 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.
| notretarded wrote:
| Probably more than you'd think, although they'd not be so dumb
| as to vocalise it as one's career depends entirely on one's
| percieved capabilities.
| myth2018 wrote:
| Actually at least Carmack did.
|
| Why would vocalizing that be dumb? It's actually not a matter
| of perceived capabilities, but of concrete results, and, in
| the case of those guys, there aren't plenty of room for
| discussion on this regard..
| enriquto wrote:
| > one's career depends entirely on one's percieved
| capabilities
|
| This may be true in many fields, but not in science and
| engineering.
| martindbp wrote:
| > What does John Carmack not know?
|
| Vim or Emacs IIRC.
| MeinBlutIstBlau wrote:
| This article really makes me feel good as a current intern and
| comp sci student. I thought I clearly defined what a junior dev
| could be if I worked at it for another year. Having read all the
| stuff this guy doesn't know and what I've learned at my
| internship, it's almost any hint of imposter syndrome I might of
| had went away.
|
| Now I'm not saying he doesn't know how to program. I'm just
| saying it's very interesting to me how little you actually have
| to specialize in to make it in this field. What my internship has
| taught me, it really makes me feel secure job wise knowing I
| won't have difficulty being employed in the areas I know. I hate
| sounding so cocky but when I first started schooling again geared
| toward comp sci, I thought programmers knew just absurd amounts
| of stuff. Now I've found, they typically are just the average
| tech savvy individuals that weren't afraid to poke around in an
| OS.
| hamburglar wrote:
| 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.
| glenstein wrote:
| I think different people can use those feelings differently.
| In my case, the thing you describe does work. It is
| stressful, but it gets me to be productive and have high
| standards (to the extent that I do, at least).
| alexpetralia wrote:
| Most importantly, if you always keep this mindset, you will
| never stop learning!
| zests wrote:
| Keep in mind technological knowledge is not the only factor. We
| pass on hiring plenty of technically competent people because
| of their communication skills. Knowing what you don't know is
| one way to improve your communication skills.
| tkgally wrote:
| Good point. Knowing what other people don't know is
| important, too.
| notretarded wrote:
| Shush you, you're giving away the secret to my 6 figure salary.
| [deleted]
| vzaliva wrote:
| There is a finite amount things we know and an infinite amounts
| of things we don't. Hence trying to list ones we do not know is
| futile. :)
| ogre_codes wrote:
| 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.
| efiecho wrote:
| > Electron. Never tried it.
|
| And nothing of value is lost.
| choeger wrote:
| From the list, I would suggest to learn C, because a lot of stuff
| is written in it or at least uses its ABI. So understanding that
| will give you a lot of leverage.
|
| Besides that, a deep dive into operating systems (yes, that means
| to get rid of MacOS if you use it) will give you a solid
| foundation to understand networking, containers and even more.
| Toutouxc wrote:
| > I would suggest to learn C, because a lot of stuff is written
| in it
|
| Does it also mean we all need to learn how to design integrated
| circuits?
| H8crilA wrote:
| I do recommend learning VHDL/Verilog (it's like learning
| functional programming or prolog - a completely unique
| experience), but it really depends on what you're after in
| life. Churning out Java/Web CRUD apps is enough to earn a
| living, it is actually what most programmers do (and even
| though every such app is boring as hell, collectively it is
| highly important for the world).
| justin_oaks wrote:
| Reading this list made me really want to explain the basics of
| each of those items so as to clear up any misconceptions, or to
| confirm that, yes, he gets the gist of it.
|
| When I try to learn about topics that I'm unfamiliar with, the
| hardest information to find is "Why is X important?" and "What is
| the most important thing to know about X?"
|
| With those in hand, I'd be able to determine if a deep dive into
| the topic is useful for me or not.
| itsoktocry wrote:
| > _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.
| dang wrote:
| Discussed at the time:
| https://news.ycombinator.com/item?id=18780065
| forrestthewoods wrote:
| I love this list. My favorite thing about it is not only do I not
| know most of those things I don't _want_ to know them.
|
| My background is video games. I specialize in real-time 3D
| applications. I think web tech is an overcomplicated
| embarrassment of cruft built on cruft built on cruft.
|
| Programming is a wide and diverse field. Webdev is the
| overwhelming majority of programming jobs. But you can have a
| very successful career not knowing _any_ of that stuff.
| worik wrote:
| I am not sorry, this does not impress me.
|
| From the comments it appears this person has done some
| significant work in YetAnotherJavaScriptFramework.
|
| Boasting that: Fuzzy on the details of how TCP/IP works (hello
| web developer, read a book!), does not understand order
| complexity specifically or algorithms in general - as one
| commenter pointed out - no wonder JS front ends are such shit if
| this is the level of intellectual heft that the authors have. Not
| knowing modern CSS - how can this person possibly work in any
| sort of cutting edge web development and _not_ know about
| that?....
|
| Specialisation is OK, but ignoring the general knowledge of how
| computing works, and then going on to write software used in
| people's critical systems is irresponsible.
|
| Buy some books. Read them. Understand. It is not hard. But, yes,
| reading is harder than writing, listening is harder than talking,
| learning is harder than making stuff up and reinventing the
| wheel....
|
| Yes. No wonder the state of web front ends.
| [deleted]
| clashmeifyoucan wrote:
| > I am not sorry, this does not impress me.
|
| I don't think it was meant to impress. On the contrary I think
| the overarching point of the whole article was that it's okay
| to not know things outside of your domain that may seem trivial
| to other CS folks.
|
| > Not knowing modern CSS - how can this person possibly work in
| any sort of cutting edge web development and not know about
| that?
|
| Well, I don't know how he does it anymore than you do. But it
| looks like he's still working on cutting edge web development
| and it seems to be working out, so my takeaway is that he
| doesn't need to know about it plain and simple.
| kyberias wrote:
| > it's okay to not know things outside of your domain that
| may seem trivial to other CS folks.
|
| Well, it's not ok. It's bad. It's irresponsible.
|
| There is a lot of basic stuff on that list one has to know.
| karaterobot wrote:
| How can you say that when there's no evidence for it?
| Abramov is a successful, respected programmer. Redux is a
| major contribution to the web. This article came out two
| years ago, and he doesn't appear to have ruined his
| reputation. On what basis is it safe to say he "has" to
| know any of the stuff he freely admits to not knowing?
| anonu wrote:
| This is common. I think there are few people that are masters at
| everything. Instead you should focus on building a talent stack
| or a skills mosaic. (Choose whichever term you want). The point
| is you might not be a master in any one subject but you might be
| pretty good at a handful of things. That permutation is enough to
| make you valuable and unique.
| watermelon59 wrote:
| 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.
| zests wrote:
| From a selfish perspective, I like the current system. It
| makes it easier to stand out. Understand where depth is
| lacking on your team and become an expert. Whenever problems
| occur you become the go-to. Pros and cons but mostly pros.
| Xevi wrote:
| You're right. Just by looking at job posts you'll see
| requirements to know several languages, frontend frameworks,
| databases, enterprise services, and so on. The modern
| programmer is often a jack of all trades, but a master of
| none.
|
| I'm building multi-million dollar applications for companies,
| and often it's with languages and frameworks I've never used
| before.
| tuckerconnelly wrote:
| Totally agree up to "There are way too many things..." That
| seems like blowing a nuance out of proportion.
|
| I think what we need is to stop having "flat" feel-good
| organizations where everyone gets a say, and similarly we
| need to stop having corrupt organizations where the most
| politically savvy person is at the top.
|
| We need strong, competent technical leaders who truly know
| most languages, frameworks, paradigms, and we need to pay
| them well. They need to take responsibility for the whole
| project and architecture, ruthlessly simplify, and work with
| product to define what actual problem is so the team and code
| doesn't turn into Frankenstein's monster.
|
| We need non-corrupt competence hierarchies.
|
| </Soapbox>
| alexanderscott wrote:
| no offense, but from this list the author is either 1) stuck in a
| particular domain or language or 2) not very proactive in broader
| learning or side projects.
|
| I agree it's ok to not program C or understand network/transport
| layer in depth. but things like unix shell basics, python, micro
| services, docker - these are all fundamentals I assume everyone
| (backend, frontend, mobile, or game engine) has working
| understanding of in order to be a proficient developer today.
|
| nice that the author recognizes the areas they lack, and should
| commit to learning in 2021. happy to give good recommendations on
| books or online classes.
|
| more curious to see this list authored from someone with more
| diverse experience.
| yladiz wrote:
| > not very proactive in learning or side projects
|
| Why do side projects matter for a job? Learning, maybe, but
| they both point to "extracurricular" time spent programming,
| which shouldn't affect someone's hiring. I've been on hiring
| panels and have pushed specifically against that mentality,
| because I strongly believe what a person is interested in
| outside of their work shouldn't affect my decision to hire
| them, as long as they're competent during the interview.
| alexanderscott wrote:
| I agree with that. it shouldn't have to be extracurricular.
| in fact, having outside interests other than programming is a
| plus.
|
| but there are plenty of ways to learn the general basics of
| modern computing on company dime. whether thru training,
| talking with peers, reviewing others code, or taking a step
| back and looking at architecture outside your specific
| domain.
|
| if I'm speaking with a frontend engineer on my team who
| doesn't understand how his code is deployed or basics on the
| compute resources used to run that code it's likely not going
| to be a very productive discussion
| mellosouls wrote:
| Co-creator of redux, he was partly motivated to write the
| article to counter ideas you need to be fluent in everything,
| often propogated (intentionally or not) by "as a hiring
| manager...red flags" posts like yours.
|
| Fwiw: https://github.com/gaearon
| alexanderscott wrote:
| didn't say need to be "fluent", said need "working
| understanding" in today's environment. countering that idea
| is futile.
|
| working on an open source JS framework is great and all, but
| doesn't make you a seasoned engineer IMO.
|
| TlDR: take this list and dedicate time in 2021 to learning so
| you can be productive in real world business engineering
| teams
| [deleted]
| yladiz wrote:
| Obviously the author is productive on a "real world
| business engineering team" considering they work for
| Facebook. Since you seem to have a lot to critique about
| the post and the author, maybe it's worth putting in that
| effort into reflection and self-criticality as well.
| klelatti wrote:
| "Wisdom is knowing what you don't know."
|
| Maybe:
|
| - The author is has a very acute sense of where his expertise
| is limited and that fact leads him to seek really expert help
| when he needs it?
|
| - He has spent his time gaining deep expertise in an area
| rather than trying to spread his time across a number of
| unrelated?
|
| - He works in a team where he doesn't need the skills he's
| listed?
|
| - He's just modest about his capabilities?
| kebman wrote:
| I noticed he didn't know much about Rust. And I really want to
| learn Rust. Except it seems the installation size is
| reprehensible. Is there a way to install a minimum version to get
| started with some fiddling about?
| NiceWayToDoIT wrote:
| I love that article. Again harsh reality is that on average
| interview for a developer in London they will ask you all those
| questions and much more. And if you get hired by any chance in
| fintech you will most probably spend majority of your time on
| meetings and working with Excel spreadsheet... never touching any
| code.
| jiofih wrote:
| YMMV and I know I'll be judged a gatekeeper, but not knowing:
| networking, modern CSS, some familiarity with SASS, CORS, basic
| deployment / platforms, and graphics APIs (!) all seem like
| pretty gaping holes for a frontend engineer - you'll most
| definitely need those when building actual products for the web.
| ogre_codes wrote:
| > you'll most definitely need those when building actual
| products for the web.
|
| You should take a good _look at who posted the article_.
|
| Fundamentally, who he is and what he's done in the community is
| the context of the blog. Without understanding that, you miss
| the entire point.
| jiofih wrote:
| I know exactly who posted the article, thank you. I simply
| disagree that you can be a frontend engineer in the usual
| meaning it has without _some level_ of those skills. Doesn't
| mean anyone is less capable, deserving or cannot make a
| living that way.
| ericmcer wrote:
| But he is literally one of the most successful front end
| engineers of all time and lacks those skills. Your takeaway
| from the article is it's antithesis.
| johnfn wrote:
| I mean, this is Dan Abramov we're talking about. Ya know, the
| guy who created a good chunk of React.
|
| I'd say he built actual products for the web just fine.
| jiofih wrote:
| He is not one of the React authors, common misconception (his
| bio says "I didn't make react" as a nod to that). He wrote
| the Redux library.
|
| Not that I would care either way - this is about skill sets
| and not personalities.
| yreg wrote:
| Abramov is the #1 contributor[0]. I guess by authors you
| mean only the innitial people who came up with React?
|
| [0] - https://github.com/facebook/react/graphs/contributors
| colmvp wrote:
| I don't think you're a gatekeeper, I just don't see the
| relevance to the author.
|
| He's a library designer and is working with a team maintaining
| and updating one of the most popular Javascript libraries in
| the world. He has a very deep background in that language which
| is one of the most important skills for his role.
|
| I don't blame him for not knowing some of those things you
| listed more deeply. There's only so many hours a day to dig
| deep into a wide range of material. You still have to spend
| time going into other material that might be more relevant to
| the day to day including testing, managing people,
| communication with team members, planning, etc. Yeah sure I'd
| love to be more knowledgeable about CORS or networking, but I
| also want to be much stronger in Javascript, the JS library I'm
| working on, design patterns, deployment, etc.
|
| Lastly, I'd rather be in Abramov's shoes where my work
| profoundly influenced web development than be all over the
| place with my 'expertise' and not actually be all that
| impactful with my time.
| clashmeifyoucan wrote:
| Seconded, also reading the list, it's likely he just delved
| deep enough to solve the issue at hand and then back to work.
|
| I can relate to that a bit, especially CORS since I never
| bothered to see what was up with that at a deep level either.
| Honestly just used a module for Flask when needed to get it
| working there and set up a CORS proxy on a cloudflare worker
| for a different project and called it a day.
|
| Maybe that's how it went with him too. I'd call this
| something like "Laze Driven Development"--learning just
| enough to solve the problem (like my experiences with bash
| scripts).
| andrewingram wrote:
| 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.
| ErikAugust wrote:
| "As the OP is a Facebook employee working as a core React
| team member, not knowing all these things clearly hasn't been
| a huge blocker."
|
| In a practical sense that should be fine, given the level of
| specialization that a company like Facebook can have given
| its size and scope. But I wonder if Dan would make it through
| the average Facebook engineer interview without his Redux
| cred however.
|
| He is also the rare person who is very honest about this kind
| of thing which is refreshing. For example he claims he only
| vaguely understands time complexity ("nested loops are bad").
|
| I don't know exactly what point I'm making here, besides
| there can be a disconnect between a developer interview
| process and what people actually contribute. I think
| engineers should strive to be solid at the fundamentals, but
| at the same time there are very productive people who just
| learn as they go. Also, it takes a village so to speak, and
| over-optimizing for Comp Sci majors who drill LeetCode may
| not be the best long term choice for building teams either.
| kyawzazaw wrote:
| Now you got me wondering how people who got more well known
| creating open source projects go through hiring process at
| these big tech cos. I know creator of Homebrew still had to
| go through typical google interview.
|
| I am talking about people like Jon Gjengset who got hired
| to work on Rust at AWS.
| lwigo wrote:
| Or just grinds LeetCode really well (or had a referral).
| idkat wrote:
| 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.
| richeyryan wrote:
| That video is quite poor in my opinion. He comes so close to
| a bunch of very interesting questions like how can state
| management and effect management be done in a good, scalable
| way that maybe isn't tied to our view libraries? He then
| admits he has close to no opinion on the matter and suggests
| web components which is about a step above the jQuery
| scenario he described in the beginning.
|
| The way I see it the advent of React was basically a
| rejection of the imperative MVC model that was prevalent with
| the likes of Backbone in favor of a more functional one. The
| first prototype of React was written in Standard ML. The
| evolution over the years with flux, redux and hooks was
| basically answering the questions that were arguably solved
| in MVC already but coming from the angle of declarative,
| immutable approaches. Where does state live? How do I handle
| asynchronous effects? How do I abstract that behavior from my
| views?
|
| I don't think the community has answered those questions
| definitively yet and a lot of the interest seems to be in
| refining the view mechanics with the likes of Svelte rather
| than really getting to grips with how to best handle long
| lived application state and the effects that operate on it.
|
| One thing I could see being the case in a couple of years,
| and in some ways the video does reach this conclusion, is
| that the reactive, stateful layer will be abstracted from the
| view and how you render your data will be almost like
| choosing a templating engine on the server. It could be
| React, Vue, Svele, Marko, Web Components, whatever. Those
| libraries and components will handle your dropdowns opening
| and closing and your tooltips showing but your real
| application state that distinguishes your product from
| another will live somewhere else and will be less subject to
| churn.
| arcturus17 wrote:
| I have absolutely no clue what you're rambling about, but if
| frontend dev shouldn't consume braincells, you go on and code
| a complex frontend in vanilla JS and then serve that plate of
| hot spaghetti to the devs coming after you.
| names_are_hard wrote:
| 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.
| yladiz wrote:
| If your speciality is frontend JS engineering, why are
| deployment, platforms, and networking (unless you simply mean
| how to use fetch/XMLHttpRequest) large holes? I'd even question
| graphics APIs beyond very basic knowledge, because in my
| experience I've never needed to know anything about those
| beyond the basics. These things sound more like full stack,
| rather than frontend.
| jiofih wrote:
| Yes, networking as in fetch/XHR, web sockets, HTTP, REST,
| protocols, performance and so on. How your frontend code
| runs. All I mentioned are strictly frontend skills, not
| anywhere near full-stack.
| burade wrote:
| That's nonsense.
|
| The guy is a specialist. That's like asking Lionel Messi to
| also be good at goalkeeping.
| Phlogistique wrote:
| This is a list of known unknowns. Those are usually not a problem
| - the problems come with unknown unknowns.
___________________________________________________________________
(page generated 2020-11-26 23:00 UTC)