Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Things I Don’t Know as of 2018

overreacted.io

Post reply on HN
Print view View original

51–60 of 119 posts

Re: Things I Don’t Know as of 2018

#51

Post by jiofih »

johnfn wrote: post #14
jiofih wrote: post #2

YMMV and I know I’ll be judged a gatekeeper, but not knowing: networking, modern CSS, some familiarity with SASS, CORS, basic deployment / platforms, and graphics APIs (!) all seem like pretty gaping holes for a frontend engineer - you’ll most definitely need those when building actual products for the web.

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.

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.

Re: Things I Don’t Know as of 2018

#52

Post by jiofih »

ogre_codes wrote: post #31
jiofih wrote: post #2

YMMV and I know I’ll be judged a gatekeeper, but not knowing: networking, modern CSS, some familiarity with SASS, CORS, basic deployment / platforms, and graphics APIs (!) all seem like pretty gaping holes for a frontend engineer - you’ll most definitely need those when building actual products for the web.

> you’ll most definitely need those when building actual products for the web. You should take a good look at who posted the article . Fundamentally, who he is and what he's done in the community is the context of the blog. Without understanding that, you miss the entire point.

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.

Re: Things I Don’t Know as of 2018

#53

Post by yreg »

jiofih wrote: post #51
johnfn wrote: post #14

Earlier quoted context omitted.

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.

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.

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

Re: Things I Don’t Know as of 2018

#54

Post by yladiz »

alexanderscott wrote: post #38

no offense, but from this list the author is either 1) stuck in a particular domain or language or 2) not very proactive in broader learning or side projects. I agree it’s ok to not program C or understand network/transport layer in depth. but things like unix shell basics, python, micro services, docker - these are all fundamentals I assume everyone (backend, frontend, mobile, or game engine) has working understandi…

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

Re: Things I Don’t Know as of 2018

#55

Post by jiofih »

yladiz wrote: post #12
jiofih wrote: post #2

YMMV and I know I’ll be judged a gatekeeper, but not knowing: networking, modern CSS, some familiarity with SASS, CORS, basic deployment / platforms, and graphics APIs (!) all seem like pretty gaping holes for a frontend engineer - you’ll most definitely need those when building actual products for the web.

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.

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.

Re: Things I Don’t Know as of 2018

#56

Post by yladiz »

alexanderscott wrote: post #43
mellosouls wrote: post #39

Earlier quoted context omitted.

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

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

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.

Re: Things I Don’t Know as of 2018

#57

Post by alexanderscott »

yladiz wrote: post #54
alexanderscott wrote: post #38

no offense, but from this list the author is either 1) stuck in a particular domain or language or 2) not very proactive in broader learning or side projects. I agree it’s ok to not program C or understand network/transport layer in depth. but things like unix shell basics, python, micro services, docker - these are all fundamentals I assume everyone (backend, frontend, mobile, or game engine) has working understandi…

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

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

Re: Things I Don’t Know as of 2018

#58

Post by enriquto »

watermelon59 wrote: post #34
nemo1618 wrote: post #17

I'd love to see lists like this from more high-profile programmers. What does John Carmack not know? What does Dan Bernstein not know? What does Bryan Cantrill not know?

Not exactly that, but when reading Coders at Work I was surprised to learn that a lot of big names in our field use "printf debugging" and don't like actual debugging tools. Made me feel less bad about it :)

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

Re: Things I Don’t Know as of 2018

#59

Post by zests »

watermelon59 wrote: post #40
anonu wrote: post #24

This is common. I think there are few people that are masters at everything. Instead you should focus on building a talent stack or a skills mosaic. (Choose whichever term you want). The point is you might not be a master in any one subject but you might be pretty good at a handful of things. That permutation is enough to make you valuable and unique.

I wonder if this is what contributes to the instability of most software though, especially SaaS. People do just enough to get by and "get things done," which always looks great at the time it happens. And then things break, and no one knows why because no one has the depth of knowledge to investigate it. But it has to be fixed, so typically one or two people in the team are assigned to it and are miserable for days…

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.

Re: Things I Don’t Know as of 2018

#60

Post by Drdrdrq »

watermelon59 wrote: post #34
nemo1618 wrote: post #17

I'd love to see lists like this from more high-profile programmers. What does John Carmack not know? What does Dan Bernstein not know? What does Bryan Cantrill not know?

Not exactly that, but when reading Coders at Work I was surprised to learn that a lot of big names in our field use "printf debugging" and don't like actual debugging tools. Made me feel less bad about it :)

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. :)
Post reply on HN