31–40 of 41 posts
I'd prefer something cooler like "1337 hex wizard h4x0r g0d first of his name" but the HR people like full-stack better.
202x - Full Stack Engineer 201x - Web Developer 200x - Webmaster 199x - Guy with a computer That's how I remember it.
"Over the past few months, I have really started to admire what I call “Full Stack Web Developers”. A full stack web developer is someone that does design, markup, styling, behavior, and programming. Some examples of these types of developers are Jason Tremblay, Geoffrey Grosenbach & Tom Preston-Werner." --Randy Schmidt
The original link is dead, but it's still available via the Wayback Machine. [^0]
I still get a kick seeing people trying to describe what a full stack web developer is and almost every single instance neglects to reference Randy's original post. Let that sink in for a moment and consider the countless job descriptions you've seen in the last fourteen years.
[^0]: https://web.archive.org/web/20110210194715/http://forge38.co...
I made a joke on Facebook a few years back about true 'full stack' development. It was a post talking about some code I was writing to do some math computation on a simple OS I had written, running on a CPU I designed using my own custom instruction set, implemented in logic on a physical PCB I also designed and assembled. Of course even this is really only 'partial stack', since I didn't do the VLSI design of the 74…
If you didn't create the universe, set its rules for quantum mechanics, and assign all its constants (including irrational ones -- set them precisely!) you can't seriously call yourself competent at the full stack.
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…
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.
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.