Comment by msla | Hacker News Reader

Comment by msla | Hacker News Reader

Parent Full thread

The phrases "functional understanding" and "working knowledge" are gigantic sucking tarpits.

Before I got my current job, I felt confident in my knowledge of computer networking at the LAN level. I knew I wasn't going into the telecom world and I knew I didn't have the knowledge to debug BGP or ensure a CO was doing everything right, but LANs? Sure. No problem. I knew DHCP, Ethernet, TCP/IP, even stuff like PPP which is more niche now. Heck, I'd even passed a college course on the subject. OK... set up an ICMP server and make it useful. That's LAN, right? Certainly gonna be used on a LAN.

I'm not saying it was hard. I'm saying that I'd never touched ICMP before except for ping and didn't know what the more advanced stuff even was. Did I have a "working knowledge" of basic networking? Did I have a "functional understanding" of how to get a building full of computers to talk to each other?

It's always something. I thought I had a good, working knowledge of networking. Someone who'd actually done networking in a corporate setting would have disagreed, and pointed to a list of things I'd never touched because those things aren't useful in SoHo LANs and aren't theoretical enough for a classroom. Multiply that by a few dozen topic headings and watch people sink under the load.

Unless you got yourself into a situation where you were expected to set up a whole office with the same speed and expertise as a full-time network engineer based on some gross misrepresentation of your skillset, I don't see how this story is particularly relevant. Maybe it's a good cautionary tale about presuming that SoHo is the limit of networking?

Technical topics are indeed both very deep and very broad. The level of sophistication and depth is how you choose your specialization, but that doesn't mean you're never allowed to learn anything else. You should learn enough about each field to know the shores when you're standing there, to be able to communicate with the "natives"/specialists, and to know when you're getting out of the shallow end. This expectation should exist for everyone: DBA, application developer, devops, network, whatever. They should all know the territory and be able to work together cohesively to identify the best place to take something down deep.

Depending on the constraints of the project, leaving the shallows means either a) developing more proficiency directly and getting deeper yourself; or b) acknowledging that you need someone with more expertise in that area to take it from there while you go back to handle things in areas you know better.

The thing we must avoid is "well I'm not a network engineer so I don't look at Cisco configs, sorry". That should be replaced with "well I'm not a network engineer, so I have no idea what's happening here, but it's still interesting, can I sit behind you and learn?"

> Unless you got yourself into a situation where you were expected to set up a whole office with the same speed and expertise as a full-time network engineer based on some gross misrepresentation of your skillset, I don't see how this story is particularly relevant.

Taking a job as one of a business's "computer people" puts you in the path of a whole lot of interesting tasks, even if your main job is programming.

> Maybe it's a good cautionary tale about presuming that SoHo is the limit of networking?

It's certainly that, but I want to expand on this a bit: SoHo is the only stuff most people can play with. For example, I can make programs and package them in Docker containers and run them that way, but I don't know how I'd play with Kubernetes in a realistic fashion. There's whole genres of technology most people can't get realistic access to without some institutional support. It's an effective ceiling on some kinds of knowledge.

As far as learning how to learn, I agree with you. I think a lot of it comes down to vocabulary: Once you know the terms the experts use, you can bootstrap effectively and learn more terms and bootstrap even more effectively. Plus, words have a way of coming back to you at odd intervals, effectively dropping you hints when you see something you vaguely recognize.

Maybe we should all have Word Of The Day calendars.

> For example, I can make programs and package them in Docker containers and run them that way, but I don't know how I'd play with Kubernetes in a realistic fashion.

Minikube: https://kubernetes.io/docs/tasks/tools/install-minikube/

Alternately, you'd take advantage of $CLOUD_PROVIDER's initial signup credit and start cloud instance equivalents.

Nowadays most things have good virtual environments floating around (you can even download virtualized mainframes if you want). A little bit of time tinkering with such environments will take you surprisingly far -- especially in fields like network engineering, where even most professionals don't know how to experiment.

Reply on news.ycombinator.com