[nickpsecurity]

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

[mentat]

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.

[nickpsecurity]

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?

[mentat]

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.

[nickpsecurity]

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

[ak217]

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

[nickpsecurity]

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.

[ak217]

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!

[vezzy-fnord]

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

[nickpsecurity]

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

[brianmwaters_hn]

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.

[nickpsecurity]

Replied here:

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

[fit2rule]

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

[nickpsecurity]

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.