Hacker News Reader

Comment by hueving | Hacker News Reader

This can't be overstated. If you dump a pile of acronym diarrhea on someone from a bunch of dead technologies and get upset when you get a blank stare, it is 100% your own fault for lacking the communication skills or abstraction skills to separate useless jargon from important concepts.

View on HN

I'll give you that. Someone called me on this in a security discussion by recommending people get a glossary. The terms were all recent and modern in this case but mainstream crowd apparently wasn't aware of any of them. So, I went back and explained each one so the reader would have context in the previous post. The vote count indicated that worked better.

That's happened enough that I sent out a recommendation to a bunch of people in high security industry to straight up drop our terminology when addressing a wide audience, look up what they call everything we talk about, and go through a major revision process on each post to translate it to their language. Might be able to get adoption of some of the techniques that already solved so many problems but just have no awareness or willingness to understand how they're normally presented. Not sure how many are going to do that rather than say "it's not our fault they didn't Google (topic) 101 to get the basic terminology and foundations."

I feel revision and avoiding acronyms particularly will help us but transferring the wisdom will still be an uphill battle. Especially with the Silicon Valley startups...

Totally agree with everything you're saying, but I would point out the the article is not about addressing a lay audience, it's about addressing network engineers who are supposedly lacking some historical/technical knowledge of their own field of work.

I expect network engineers to understand what they do day to day. Do they really need to understand the whole history of the field to do that? Mostly not: just specific things necessary for their jobs. Our economy and resources are sort of rigged in that direction. So, we might need to use a preemptive solution where we present various principles, tactics, pro's, and con's to them rather than a full history lesson they'll think is useless.

Ideally, they'll learn it all. I've learned the world is rarely ideal. Need a practical alternative to ideal...

That's just it, those who do not understand history are doomed to repeat it. By not learning about it they will make poor day to day decisions which lead to the exact same mistakes decades later.

It's true. Most of history is probably useless, though. So, you need to know which parts to learn. Most people getting into network engineering don't have 5-10+ years to figure that out on top of work, family, fun, etc. So, the most relevant parts of history of a subfield should be accessible in a way that doesn't require that level of effort. That's like making people studying mathematics, mechanical engineering, etc look through every ancient manuscript and writing to unearth the best principles and techniques for their field day-to-day and project-to-project. Makes no sense.

And this is coming from a guy whose gone to the extreme of studying everything in several sub-fields of IT: over 12,000 academic or professional papers in my archive on top of the books, etc. Skimmed most, fully read some, and re-read a tiny few (gold mine). Took a long time to get to that tiny few. No justification for that except that generation made little to no attempt to get that stuff to me in an accessible way. And now my generation is repeating the mistake for the next.

Or do you really think it's optimal that every learner have to spend 3-5 years per sub-topic digging through the whole of knowledge on it just to find the few things that might pay off?

Do you keep track of your gold mine in a list somewhere? Would be interested in looking at it. :)

Before I can wholesale share it, I have to go through to figure out which ones are locked in to ACM/IEEE to exclude them from the list. The rest are [mostly] disorganized because I started pulling them in batches of 20-100 a day. So, there's a little work to be done there before I can publish them.

I've saved your username and email somewhere so I can notify you when I get around to doing that. What topics are your core interests? My main focus is high security IT and software/system verification with a number on programming, hardware design/synthesis, software engineering, networking, databases, filesystems, OS's, and high-performance computing. Might send you a few samples of each in your interest to let you see the kinds of things people overlook. I should have time this week.

I sent you an email (the one linked to your HN profile description) on the subject. I hope you get back.

As far as computer disciplines go, my core interests are in language design, distributed systems design, software engineering, security, string and graph algorithms, high performance computing, OS and filesystem design. Aside from that I have interests in genomics, nanoscale optics, and AI/ML.

Thanks for the offer!

It's not about spending 3-5 years learning about the history but actually believing and understanding that that history has value. It's the ability to regularly ask the question "is this a solved problem" and actually be willing to work to figure it out. This is what I feel is missing with a lot of the younger engineers I interact with.

"It's the ability to regularly ask the question "is this a solved problem" and actually be willing to work to figure it out. This is what I feel is missing with a lot of the younger engineers I interact with."

I agree with you on that. Many don't have that desirable trait. They'll miss out on greater things because of that. Another thing worth study and effort is figuring out how to teach that mindset to young engineers.

Once they have it, then they need the organized presentation of our fields that I'm arguing for. Both the will/mindset and resources for learning are necessary for best results.

Nick, (this is a reply to your post at the same nesting depth, as we're at the max here)

We're pretty much on the same page on this whole thread, but consider the idea that perhaps the fact that it took so many years and thousands of papers wasn't because the previous generation didn't organize them well, but was simply due the the sheer volume of information. That time wasn't wasted sifting through irrelevant stuff - you're now an expert.

On the contrary, I think the writers and organizers of all that material did a great job; both of us owe nearly everything we know to them.

Replied here:

https://news.ycombinator.com/item?id=10420017

@ brianmwaters_hn

"took so many years and thousands of papers... due to the sheer volume of information. That time wasn't wasted sifting through irrelevant stuff - you're now an expert. On the contrary, I think the writers and organizers of all that material did a great job; both of us owe nearly everything we know to them."

I agree there's a lot of material, the learning process was worth it, and there's even more to gain. That said, the learning process taught me that a tiny, tiny fraction of those papers taught people 95+% of what they need to know for their sub-field. We need that information packaged, well-presented, and widely distributed for each sub-field. People wanting to learn more can volunteer time to do so. All I'm pushing for is that baseline packaged and ready for newcomers with few to no obstacles. Right now, it's hard enough to find that most don't. Gotta change that.

>Do they really need to understand the whole history of the field to do that?

That marks the difference between being a technician and being an engineer. A technician just needs to know how to do their job, whereas an engineer needs to know why they need the technician to do their job.

I still repeat the same question to your answer. Most engineers don't need to do near as much digging as many IT people do to understand the important stuff behind their field. For instance, despite all that's written on HW design, my research found that most of the key stuff (including insightful wisdom) can be found in under 10 books that properly transferred both knowledge and wisdom with minimal extraneous information. From there, it's years of experimentation to make those things habit and better understand why they're true. I discovered them with some Google perseverance but also because pro's were recommending them while explaining what wisdom each contained.

That could be done way more easily in networking. Should be done if it hasn't already. If it has with key resources, they shouldn't be so obscure with people like that blogger readily linking to them as I've seen in engineering fields. Don't make people wade through endless papers and histories of bureaucracies' decision-making processes to determine one technical report's worth of important design guidelines and justifications. Give them the good stuff in a way they know it's the good stuff.

"If you want your son to throw 50 yards, well... GIVE HIM... 50... YARDS!" (Vault drink commercial)

And, heck, it can even be presented in a time-ordered fashion where they learn some of the past as they go. They might start with a certain type of medium, the protocol for it, the issues, the solutions, and key things to learn from that which might apply to other situations. Then the next and the next. All the way up to samples of cutting edge stuff* at the end to make it memorable with an awe factor and exotic, weird stuff from our history sprinkled throughout just to hold attention (but also teach).

* A book on supercomputing got me more into networking than networking itself. The ultra-low-latency, high-bandwidth, cross-bar switches blew away anything I used. Plus, they in theory let many cheap nodes become a machine with CPU's, RAM, and graphics cards of a SGI Onyx2! To do it, though, I needed to understand the effect of wires/optics, host connectors, host protocols, cross-bar designs, topologies, cache-coherence algorithms, and so on. Quite a lot but quite the motivation. Never got to Onyx2 level on a budget but lessons gave long-lasting capabilities: topology, Beowulf clustering, single system image, clustered filesystems, Active Messages, reliable UDP (eg UDT), and discovering NUMAscale's products after typing the concept (NUMA) and connector (HyperTransport) into Google. One or two badass technologies along with justifications went a long way, eh?

Example would be me studying ancient NSA computers to find one used mercury for RAM. The concept of buffer overflow became more memorable as the story brought to life the consequences they endured: mercury exploding out the computer. Crazy stuff we'll never encounter but I still remember it & it reinforced preventing overflows.

This is an attitude I see more and more of today, and I think it's unfortunate. The slides in question aren't "a pile of acronym data;" they're made of lingo that would be recognizable to anyone who works in the field of networking - even if they don't understand the specifics of the protocols in question.

At any rate, the author's complaint isn't that "kids these days" haven't heard of all these acronyms, it's that they haven't learned any of the technical details behind those acronyms, and that those details are still relevant.

Finally, I have a bone to pick with the "it's the older generations' responsibility to educate the younger generation" idea that I hear so often. At the end of the day, it's everyone's own responsibility to educate themselves, and we all know there's plenty of materials available for that.

"Finally, I have a bone to pick with the "it's the older generations' responsibility to educate the younger generation" idea that I hear so often. At the end of the day, it's everyone's own responsibility to educate themselves, and we all know there's plenty of materials available for that."

I'm on your side of the discussion overall but that's unrealistic. It took me a decade to get so much of this knowledge and wisdom out of papers on programming, OS design, networking, security, etc. I just found some more foundational work in past months that should've been in every classroom for its relevance but nobody's heard of it.

The problem is that the stuff is scattered all over the place and not in pure form at all. There's books, papers, brochures, lectures, etc. These might have good details, fluff, or a varying mixture of each. Many great works can only be found behind paywalls (IEEE, ACM). Others are on academic sites, specific blogs, or places like CiteseerX where you have to know what you're looking for ahead of time.

Our field is anything but a clean, integrated presentation of what really mattered, matters, and might matter. It's a huge, scattered mess that we expect new crowd to just automagically sort through and discover necessary stuff. Prior generations certainly have some responsibility to make that easier rather than harder. I do my part with posts here and elsewhere directing people to specific techs that solved (or nearly so) the problems they are talking about. Need a more thorough solution, though, for the various sub-fields of I.T. before I'll blame the newcomers for prior generation's mess.

Hm, I agree that there's a lot scattered out there, but I hope that there's some room for exploration (and maybe specialization) somewhere in the noise.

I actually have an interesting perspective on this, being completely self-taught, before returning to university as an adult to get a computer science degree.

There are pros and cons to both sides of the self-taught vs. teacher-taught thing, though I'll make my bias clear up front: I spent a lot of years reading books and messing around with stuff; now, when I hear college students complain that a teacher "isn't a clear lecturer" or "didn't answer my question well," my tendency is to say "there's a book and an Internet out there, suck it up and get to studying, buddy," though I realize that attitude isn't perfect for everyone.

" when I hear college students complain that a teacher "isn't a clear lecturer" or "didn't answer my question well," my tendency is to say "there's a book and an Internet out there, suck it up and get to studying, buddy,""

I get that and mostly agree with it. Exception being the people who learn best with the help of others (esp face-to-face). They don't learn the hard stuff well with text but they're valuable once they learn it. The other exception would be the topics where having a pro at hand can greatly simplify the learning process mostly due to nature of topic itself.

In most situations, you're totally right. People just aren't putting in effort. I think the stuff with lots of historical baggage of unknown usefulness seems like unjustifiable effort to many in IT. So, I don't throw them into that category if it's such a thing rather than their own skill set. Now, if they didn't know essential networking skills and griped that nobody told them, I might link to your comment followed by a back hand.

> when I hear college students complain that a teacher "isn't a clear lecturer" or "didn't answer my question well," my tendency is to say "there's a book and an Internet out there, suck it up and get to studying, buddy,"

Which raises the question of what the lecturer is even standing around talking for. Isn't it just a waste of their own and everyone else's time if they aren't good at doing what they attempt to do? If someone is a good researcher and lousy in the classroom, why make them teach classes and waste everyone's time?

I agree with you there. I think Brian probably would, too. His point was that many people let their pursuit of knowledge end there rather than use other resources available to learn what they needed to know. The lecturer becomes an excuse rather than an obstacle on the path to understanding.

There are an order of magnitude more failed technologies than there are successful ones and learning all of the successful ones is already a gargantuan task. Just because some crotchety old guy watched a particular one go up in flames doesn't mean that everyone he talks to about a concept needs to be subjected to an analogy only relevant to one failed subject.

You are misunderstanding me if you think I suggested that old people need to educate young people. I'm suggesting that if concepts cannot be distilled from the technology and discussed on their own merit, don't bring them up because it means you don't actually understand them well enough.

This guy is mad not because people couldn't understand concepts, he is mad that they didn't get his archaic analogies. It's like a car guy calling an engineer stupid for not know what engine was in a 52 Chevy.

So he's a "crotchety old guy" with an analogy relevant to just "one failed subject." You have absolutely no respect for your elders, do you?

Also, the second sentence of your second paragraph makes no sense to me.

>You have absolutely no respect for your elders, do you?

No, I have no respect for people that offer analogies via obtuse references and then look down on you for not getting it.

Reply on news.ycombinator.com