3 ms·

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 cul

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

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