4 ms·

well, for web it ought to include some knowledge of, and ability to debug, the underlying protocols, HTTP[S], TCP, IPv4/v6. And modern Ethernet switching. On th

by mac3n 5y ago

well, for web it ought to include some knowledge of, and ability to debug, the underlying protocols, HTTP[S], TCP, IPv4/v6. And modern Ethernet switching. On the host side, network sockets and some kernel implementation chops. At the lower end of the stack, modern processor/memory performance architecture, beginning with a basic understanding of instruction sets. Ability in some hardware design language would be good, tristates, gates, latches and flops. But that's just my take on the full stack.

seumars 5y ago
In what context would one realistically be able to debug TCP/IPv4/IPv6? Also in terms of network sockets and kernel implementation you're talking about apples and oranges.
- fragmede 5y ago
  Any context where network things don't work like they should. This would include why your home internet is 'flakey', why your load balancer doesn't quite balance loads, why some database connections are slow but others are fine. You may not need those skill but busting out tcpdump and looking at pcaps in wireshark is part of calling yourself full-stack. With the cloud it may not matter as much if you've never twiddled SACK settings, but there's a large body of knowledge that is entailed by full-stack that can't be covered in boot camp.
- mac3n 5y ago
  _slightly_ tongue-in-cheek, because i'm annoyed by people calling the top 3% "full" stack But, an example is discovering from the DSACK responses that your network performance sucks because the intel TCP offload firmware is retransmitting entire jumbograms when any packet gets lost. Also discovering that you can't get near full network bandwidth because some moron attaches a 3-byte SNAP header. And if you don't have some idea how your programming language works, how do you know what you're doing? When a memory cache miss costs the equivalent of several hundred instructions.
  - mac3n 5y ago
    in the last case, a multithreaded C++ backend service where the STL String reference count updates weren't atomic
- lowercased 5y ago
  "debug" may be the wrong term, but 'diagnose' might be a more necessary skill. a colleague described a recent scenario. they've got a college kid (... 1st year? 2nd year?) doing programming work, and basically dissing on all tech stuff that he isn't intimately familiar with (which... means a lot of stuff). he managed to get some stuff working on google app engine, but some of the stuff doesn't work. The kotlin stuff has a warm up time ("that's normal"), but some PHP stuff takes 8-10 seconds all the time for on every request. "PHP sucks, it's shitty, everyone's leaving it, kotlin rules", etc. No one else is seeing that same performance. Most other people hit the PHP instance and get 100ms response times with moderate payloads. He keeps insisting that it's PHP that's horrible, and what he's seeing is evidence that not even google engineers can make it work because it's so bad. My colleague and a couple others have said to him "you have a network problem - some route to that app engine isn't working right for you for some reason". "oh no, it's not that. PHP is crappy". So... over the holidays, he goes home to parent's house. Has a week of doing some work, never once mention of PHP being slow. IIRC, he seemed to think google got stuff working (despite PHP being crappy). Then he's back at his regular place, and suddenly it's all slow/bad again. Hrm... if you're the only person on a distributed team having extremely slow network issues to one server, then that problem goes away when you access it from a different network, then you have the same problem when you go back to the first network... it's not the remote technology. Or... at least not the tech you think it is. I'm not saying he can actually debug or affect an actual fix, but diagnosing/recognizing the signs of network problems as actual network problems should be a requisite. If 8 people hit a server and get 100ms or less response times, and your requests take 8 seconds from your house, but 100ms from your parents' house... this is a network problem on someone's end. It's not a PHP (or kotlin, or ruby, or whatever) issue.

by mac3n 5y ago

seumars 5y ago

In what context would one realistically be able to debug TCP/IPv4/IPv6? Also in terms of network sockets and kernel implementation you're talking about apples and oranges.

fragmede 5y ago
Any context where network things don't work like they should. This would include why your home internet is 'flakey', why your load balancer doesn't quite balance loads, why some database connections are slow but others are fine. You may not need those skill but busting out tcpdump and looking at pcaps in wireshark is part of calling yourself full-stack. With the cloud it may not matter as much if you've never twiddled SACK settings, but there's a large body of knowledge that is entailed by full-stack that can't be covered in boot camp.
mac3n 5y ago
_slightly_ tongue-in-cheek, because i'm annoyed by people calling the top 3% "full" stack But, an example is discovering from the DSACK responses that your network performance sucks because the intel TCP offload firmware is retransmitting entire jumbograms when any packet gets lost. Also discovering that you can't get near full network bandwidth because some moron attaches a 3-byte SNAP header. And if you don't have some idea how your programming language works, how do you know what you're doing? When a memory cache miss costs the equivalent of several hundred instructions.
- mac3n 5y ago
  in the last case, a multithreaded C++ backend service where the STL String reference count updates weren't atomic
lowercased 5y ago
"debug" may be the wrong term, but 'diagnose' might be a more necessary skill. a colleague described a recent scenario. they've got a college kid (... 1st year? 2nd year?) doing programming work, and basically dissing on all tech stuff that he isn't intimately familiar with (which... means a lot of stuff). he managed to get some stuff working on google app engine, but some of the stuff doesn't work. The kotlin stuff has a warm up time ("that's normal"), but some PHP stuff takes 8-10 seconds all the time for on every request. "PHP sucks, it's shitty, everyone's leaving it, kotlin rules", etc. No one else is seeing that same performance. Most other people hit the PHP instance and get 100ms response times with moderate payloads. He keeps insisting that it's PHP that's horrible, and what he's seeing is evidence that not even google engineers can make it work because it's so bad. My colleague and a couple others have said to him "you have a network problem - some route to that app engine isn't working right for you for some reason". "oh no, it's not that. PHP is crappy". So... over the holidays, he goes home to parent's house. Has a week of doing some work, never once mention of PHP being slow. IIRC, he seemed to think google got stuff working (despite PHP being crappy). Then he's back at his regular place, and suddenly it's all slow/bad again. Hrm... if you're the only person on a distributed team having extremely slow network issues to one server, then that problem goes away when you access it from a different network, then you have the same problem when you go back to the first network... it's not the remote technology. Or... at least not the tech you think it is. I'm not saying he can actually debug or affect an actual fix, but diagnosing/recognizing the signs of network problems as actual network problems should be a requisite. If 8 people hit a server and get 100ms or less response times, and your requests take 8 seconds from your house, but 100ms from your parents' house... this is a network problem on someone's end. It's not a PHP (or kotlin, or ruby, or whatever) issue.