Live data from Hacker News

Things I Don’t Know as of 2018

overreacted.io

61–70 of 119 posts

Re: Things I Don’t Know as of 2018

#61
post #52

Earlier quoted context omitted.

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

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.

Re: Things I Don’t Know as of 2018

#62

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?

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.

> one's career depends entirely on one's percieved capabilities

This may be true in many fields, but not in science and engineering.

Re: Things I Don’t Know as of 2018

#63
post #60

Earlier quoted context omitted.

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

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

Re: Things I Don’t Know as of 2018

#64

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…

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

Re: Things I Don’t Know as of 2018

#65
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…

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.

Re: Things I Don’t Know as of 2018

#66

Earlier quoted context omitted.

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

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

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?

Re: Things I Don’t Know as of 2018

#67
post #46

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…

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.

Good point. Knowing what other people don't know is important, too.

Re: Things I Don’t Know as of 2018

#68

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…

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.

Re: Things I Don’t Know as of 2018

#69
post #63
post #60

Earlier quoted context omitted.

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

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

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.

Re: Things I Don’t Know as of 2018

#70

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…

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.

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