Hacker News Reader

Comment by pc86 | Hacker News Reader

I don't think I can really articulate why but this smells a lot like the "real programmers use [neo]vim" or "real developers write C++" kind of gatekeeping that was pretty widespread and even expected/accepted a few decades ago, but really has no place now.

Being intimately familiar with HTTP is fine, reading a lot of RFCs is fine, but there are plenty of well respected, well compensated, influential engineers who do neither, and have no need for either one.

View on HN

I see what you mean, but you’ll note that I’m neither saying that it’s the only way, nor am I saying that it’s required. What I’m instead doing is trying to cultivate a deep understanding of one’s tools and protocols, which is absolutely the hallmark of a competent engineer.

I concede that this may superficially resemble the aberration you describe, but insist that it’s actually very different.

My experience is that to do any kind of engineering and most kinds of science really well, you need to have a deep understanding one layer down and one layer up.

The HTTP comment seems off-base. HTTP is neither particularly important or interesting as a protocol. You can spend a half-hour with netcat and have a few conversations with your web server, and you're set.

The concept more broadly is spot-on. The "I don't need to know [x] to do my job" crowd is universally mediocre at their job.

For a programmer, the set of things one layer down is important, be that cache/memory hierarchies, low-level programming, operating systems, databases, compilers/interpreters, or otherwise. So is one layer up, which is usually business and product understanding.

I'll also mention: Mediocrity at one's job is okay. There are plenty of wonderful people who have work-life balance and do interesting things outside of their job, and just want a pay check. There are people happy to be working on systems I'd be miserable working on -- payroll, banking, inventory, etc. -- and I'm glad they're around. A few of them are among my favorite people too.

That's a good way of looking at domain knowledge "one layer up". I'm have been terrible at this in the past and I have been making an effort to improve. Business knowledge seems to provide the most leverage, especially in fields like finance.

My problem is I find the knowing the lower level stuf way way more interesting. Heck I'm doing a udemy course on network programming which arguably won't help my career, I just have a secret shame about not really knowing networking. (Plus it's really interesting)

Respectfully, if you think http is unimportant or uninteresting, then you don’t know it very well. It’s exceedingly interesting from a linguistic point of view, to name but one; the notion of verb + complement of the object is fundamental to http, and sheds light on where it tends to be the _wrong_ choice. This inevitably leads to non-trivial design discussions.

And comment about netcat happens to be exactly what I’m condoning.

As for mediocrity, sure. But it should be voluntary, not imposed by a lack of options.

I think this: "Respectfully, if you think http is unimportant or uninteresting, then you don’t know it very well" is fairly presumptuous.

HTTP has no interesting theoretical basis, and doesn't really generalize to much. Like most early internet protocols, it's kind of random and ad-hoc, with incremental hacks and improvements like keep-alive added later. You can pick up any RFC -- POP, IMAP, or whatever, and get just as much out. That's not nothing; they're worth knowing, but here's a short list of protocols and data standards which which have a theoretical basis which will teach you something deeper:

- git. Brilliant data standard.

- SQL. And relational database theory.

- SGML. Yes, the original. Much juicier than XML in design.

- Cryptographic protocols. Pick up a copy of Applied Cryptography, and read the chapter.

- A survey of the early RPC and object embedding protocols (OpenDoc, OLE, etc.)

- TCP/IP

- Any of the various compression and/or error correction protocols.

- Printer standards, especially PostScript

- Video, audio, or image compression standards.

.. and so on.

Some of those require months of study.

I would say that mediocrity is okay as long as you don't force others to follow it. Sometimes I feel as if there is some sort of "militant mediocrity" happening in some corners of our profession, where anyone even remotely interested in digging one layer down is not only looked down as not being enlightened enough, but also committing a capital sins of acting against the business interests and walking outside the predetermined boundaries of their programming-caste. Cue horror stories of cowboy coders and NIH.

If I'm hiring a SWE that will touch anything web I expect them to know the basics of HTTP and to be capable of referencing/digesting an RFC. It's a common interview question for these roles to outright ask, "how does the internet work?" gesturing to a whiteboard. It's a reasonable stance to take.

Overall I agree with your gate-keeping comment - that's how people interview/hire. I disagree that it "has no place" - if I'm hiring a mid-to-senior engineer that's web-capable I am 100% gate-keeping to make sure they have an intimate understanding of HTTP + are capable/comfortable reading RFCs.

> how does the internet work?

It's like a series of tubes. That's why SWE work involves so much plumbing and getting deep into all sorts of $#!+.

While Internet is a series of tubes, SQL is a sewer: You need a lot of layers to interact with it because it’s very dirty. Real engineers have Liquibase over Hibernate and completely hide SQL from developers. Also it’s extremely slow, I don’t know why old people like it. That’s why NoSQL works better when you have large databases, like a thousand documents or more.

Also, React is not slow at displaying tables. If it’s slow, you can use plugins to hide cells which are not in the viewport.

(Old farts like me manage a billion records and display tables of 7k rows x 100 columns in a webpage in mere milliseconds, a joy that React developers will never understand. Why do you need more than 10 lines if you have pagination, they say).

Why would you need to be capable of referencing a HTTP RFC?

Are you doing something fancy with HTTP?

Would it count as “fancy” to find out whether header names are case sensitive? Plenty of useful things in there.

I certainly don't think that's a thing someone needs to know to be a useful web developer. I've certainly never needed to care, although I wouldn't classify myself as web in particular.

I've never needed to look up if headers were case sensitive, it's just never caused an issue in my 10 years experience.

Referencing, no. But being able to look up the answer to an tricky edge case in the RFC is a valuable skill

Thats a really odd set of things to gatekeep on.

What, fundamental knowledge and capability?

Fundamental for those whose job is building web servers, sure. Id expect nothing less from the authors of apache, nginx, etc.

I would say that if a web dev can articulate http verbs, their uses, and how to design a cohesive naming strategy and documentation scheme, that's all they need to be competent. There is no need to read the HTTP RFS for most design tasks. I can understand those requirements for Google, AWS, Facebook devs, but 90% of the work out there doesn't need that level of understanding to make something decently performant.

90% is an exaggeration. Even someone doing CRUD has to be familiar not only with HTTP verbs, but also some headers, response codes, query strings, request bodies, understand how caching works, etc, at some point. The only way to avoid it is only working for years on the simplest of projects.

They don't have to read RFCs in bed before sleep, but they should at least know the gist of what they contain.

All those things that you listed can be learned without reading the RFCs though, no? But yeah, I agree with the list you wrote. That's what I had in mind.

That's why I wrote "They don't have to read RFCs in bed before sleep, but they should at least know the gist of what they contain."

I bet this is a poor juniors interview out there:

Interview 0:

"I expect them to know the basics of HTTP and to be capable of referencing/digesting an RFC"

Interview 1:

"All devs should be up to speed on the mysterious world of character sets, encodings, Unicode, all that stuff"

Interview 2:

"Any real programmer can reverse a string in C without a buffer"

Interview 3:

"I expect anyone working with k8s to understand the cgroup fundamentals."

Interview 4:

"No really. What is html5?"

Well respected and compensated engineers usually have a depth of experience that extends beyond their REST framework. That’s what the parent was advocating.

> real programmers use [neo]vim" or "real developers write C++"

Real programmers know how to do both even if the don’t do them exclusively.

The idea that you're not a real programmer if you can't use a specific editor is idiotic.

The idea that not knowing something makes you smarter is idiotic.

Feel free to quote where anyone here is saying not knowing something makes you smarter.

If reading RFCs is a gate, then it is a pretty bad one. They are public, free, well known, and generally well written.

Also unnecessary to read for 99% of webdev work.

Why is gatekeeping always considered to be a bad thing?

Gatekeeping is not always a bad thing, but OP implemented a clear sample of the No True Scottsman fallacy to draw a rather arbitrary and mostly useless line to put themselve in the imaginary "real programmers" group.

Reply on news.ycombinator.com