12 ms·

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

by pc86 5y ago

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.

omginternets 5y ago
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.
- blagie 5y ago
  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.
  - bennysomething 5y ago
    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)
  - omginternets 5y ago
    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.
    - blagie 5y ago
      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.
  - 5y ago
mattgreenrocks 5y ago
Well respected and compensated engineers usually have a depth of experience that extends beyond their REST framework. That’s what the parent was advocating.
peterangular 5y ago
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.
- zozbot234 5y ago
  > 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 $#!+.
  - eastbound 5y ago
    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).
- tester756 5y ago
  Why would you need to be capable of referencing a HTTP RFC? Are you doing something fancy with HTTP?
  - thombles 5y ago
    Would it count as “fancy” to find out whether header names are case sensitive? Plenty of useful things in there.
andrewprock 5y ago
If reading RFCs is a gate, then it is a pretty bad one. They are public, free, well known, and generally well written.
- antifa 5y ago
  Also unnecessary to read for 99% of webdev work.
superdisk 5y ago
Why is gatekeeping always considered to be a bad thing?
- antifa 5y ago
  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.
commandlinefan 5y ago
> 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.
- pc86 5y ago
  The idea that you're not a real programmer if you can't use a specific editor is idiotic.
  - commandlinefan 5y ago
    The idea that not knowing something makes you smarter is idiotic.
    - pc86 5y ago
      Feel free to quote where anyone here is saying not knowing something makes you smarter.

by pc86 5y ago

omginternets 5y ago

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.

blagie 5y ago
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.
- bennysomething 5y ago
  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)
- omginternets 5y ago
  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.
  - blagie 5y ago
    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.
- 5y ago

mattgreenrocks 5y ago

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

peterangular 5y ago

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.

zozbot234 5y ago
> 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 $#!+.
- eastbound 5y ago
  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).
tester756 5y ago
Why would you need to be capable of referencing a HTTP RFC? Are you doing something fancy with HTTP?
- thombles 5y ago
  Would it count as “fancy” to find out whether header names are case sensitive? Plenty of useful things in there.

andrewprock 5y ago

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

antifa 5y ago
Also unnecessary to read for 99% of webdev work.

superdisk 5y ago

Why is gatekeeping always considered to be a bad thing?

antifa 5y ago
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.

commandlinefan 5y ago

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

pc86 5y ago
The idea that you're not a real programmer if you can't use a specific editor is idiotic.
- commandlinefan 5y ago
  The idea that not knowing something makes you smarter is idiotic.
  - pc86 5y ago
    Feel free to quote where anyone here is saying not knowing something makes you smarter.