3 ms·

> A "full-stack engineer" should be very familiar with... That person doesn't exist, gradient or not. There's no way for someone to be "very familiar" with so

> A "full-stack engineer" should be very familiar with... That person doesn't exist, gradient or not. There's no way for someone to be "very familiar" with so many different domains at the same time. By the time you gain familiarity with all the domains, the information you initially learned will be out of date or you will have forgotten. Also, full-stack colloquially refers to someone who can work on frontend and backend.

withinboredom 5y ago
I sometimes market myself as a “true full-stack engineer” and I’d say I’m pretty darn familiar with everything from the machine code, lexer, parser, compiler, linker, language idioms in a few languages, frameworks, CSS, HTML, TCP/IP, an ever-hating-and-hope-will-die feeling towards GRPC, JSON quirks, YAML quirks, how file systems work, how email works (SMTP, DKIM, SPF, etc), k8s, the Linux kernel, custom drivers, video game engines and the maths behind them (like Quaternions, vectors, matrices, etc), and probably a few other things I can’t remember right now. It takes a lot of time work to stay on top of these things but it’s a passion, and some things I know exist but don’t know the current incantation for (like getting full screen access for a game engine). It used to be quite long, but I think it’s much less LoC these days. Anyway… we do exist. Like I said, for me it’s a passion. It probably won’t come up in an interview unless it’s a startup and the job sounds incredibly interesting. Even then I might keep my mouth shut just to not come across as over-qualified or “too expensive.”
- ZephyrBlu 5y ago
  To me being "very familiar" with those things would mean that you could perform the role of a SWE, SRE, compiler dev, <language> dev, <framework> dev, kernel dev, engine dev, etc right now and be effective. Since that isn't possible I have to assume that you have a different definition of "very familiar" than I do.
  - psyc 5y ago
    It is possible. Contradiction dissolved.
    - ZephyrBlu 5y ago
      Do you know of such a person? I would love to see someone who can work in all of those roles simultaneously so I can try to learn how they're so effective across such a large number domains.
      - psyc 5y ago
        Sure. I’m like the person you replied to. It’s three things. 1) It took me 25+ years to amass the expertise. 2) It’s a hobby first, and a career second. 3) Since the beginning I always choose to see how things are the same more than how they are different. Goes for languages, hardware, APIs, OSes, protocols, everything. I insist on seeing it all as superficial variations on the same thing, no matter what anybody says. Oh but I don’t know how to do SRE. No interest.
        withinboredom 5y ago
        Same. It took about 25+ years, and a hobby that happens to pay the bills. Interesting that you say that about how things are similar. It’s so true! The same patterns/abstractions are everywhere, just with different words in them, different orders, and sometimes, different names. I also have no interest in an SRE role. I don’t like being on-call. I build systems to fail gracefully so I never work weekends, but most people don’t do that for some reason. I currently work as a SWE. We don’t have explicit roles where I work, but my responsibilities are in-line with a principal or lead engineer.
      - camgunz 5y ago
        I've also written a Linux driver, a filesystem, IPC code across an ARM CPU and proprietary DSP, web apps in PHP, Python, React, and Go, desktop apps, data pipelines, reporting dashboards, and all kinds of other things. Same as my sibling I stay curious and say yes a lot.
  - withinboredom 5y ago
    I’m active in my favorite language’s development, I work as a SWE, my current project is in a legacy system touching billions of people a year. Prior to that, I worked on a stats-heavy project that needed to make real-time decisions for millions of users at any given moment. On my free time, I work on various things like building a cockpit for a flight sim, building my own Bluetooth door lock, learning new languages and frameworks, creating SDKs for my favorite language to popular services, etc.
alluro2 5y ago
I don't think this is true - while exposure to a wider or narrower set of these domains / technologies will depend greatly by your held positions and responsibilities within teams, size of companies worked for, and raw years of experience (so it is a gradient), I would expect from an experienced web developer to simply be very familiar with all of these if they are passionate and curious about what they do. I consider myself a mediocre senior web dev, and I am can humbly say that I'm very familiar with all of the listed, without intentional effort in that direction over the years, simply because I wanted to understand the context of some of the things I needed to do, and also poke into each enough to understand how much depth there is and what I don't know. It is natural that it tends to add up. Over the years, I saw a strong correlation between that breadth and how "good" someone was - on the example of someone working on the fronted in a team, I see 3 basic categories: 1) Not very good: I can do only the most direct and specified things and if something doesn't go as implementation plan intended, or requires outside of what I see as my "formal scope" (e.g. "frontend developer", so React + CSS), I expect someone to solve it so I can continue 2) Ok, but limited: I do only the things inside my "formal scope", so if I'm building a frontend to a web app, it's someone else's responsibility to think about e.g. security - but when something doesn't go as planned along my line of work, I'll find why and unblock it 3) Good: We're building a web app, what are all the things it needs to consider and achieve? My part in the team is this UI / frontend, but if security is important for this use-case, how will my frontend be cognizant of the security goals? I should read up that OSI thing I heard about, cover the basics on my side, and start the discussion on it so we as a team ensure the frontend part is good security-wise
- ZephyrBlu 5y ago
  > I wanted to understand the context of some of the things I needed to do, and also poke into each enough to understand how much depth there is and what I don't know To me this is not equivalent to "very familiar". I think whakim's comment puts things well: > I use AWS day-to-day, but haven't used GCP day-to-day in 5+ years - should I realistically be able to keep abreast of the vast number of GCP changes that have happened over that time (plus all the changes in devops that make the workflows I was using 10 years ago look outdated)? Many projects don't need Websockets or Eventsource - do I have to keep that knowledge top-of-mind across the years that I don't use them? Can you really claim that you're "very familiar" with that web framework that you used two jobs ago - assuming there haven't been a bunch of major changes since then? https://news.ycombinator.com/item?id=30474206 https://news.ycombinator.com/item?id=30474206
gunapologist99 5y ago
> That person doesn't exist Just because you've never met one doesn't mean they don't exist. However, often, people like this (sadly) move into management or into higher-level architecture types of roles, and let their tech skills go fallow.

withinboredom 5y ago

I sometimes market myself as a “true full-stack engineer” and I’d say I’m pretty darn familiar with everything from the machine code, lexer, parser, compiler, linker, language idioms in a few languages, frameworks, CSS, HTML, TCP/IP, an ever-hating-and-hope-will-die feeling towards GRPC, JSON quirks, YAML quirks, how file systems work, how email works (SMTP, DKIM, SPF, etc), k8s, the Linux kernel, custom drivers, video game engines and the maths behind them (like Quaternions, vectors, matrices, etc), and probably a few other things I can’t remember right now. It takes a lot of time work to stay on top of these things but it’s a passion, and some things I know exist but don’t know the current incantation for (like getting full screen access for a game engine). It used to be quite long, but I think it’s much less LoC these days. Anyway… we do exist. Like I said, for me it’s a passion. It probably won’t come up in an interview unless it’s a startup and the job sounds incredibly interesting. Even then I might keep my mouth shut just to not come across as over-qualified or “too expensive.”

ZephyrBlu 5y ago
To me being "very familiar" with those things would mean that you could perform the role of a SWE, SRE, compiler dev, <language> dev, <framework> dev, kernel dev, engine dev, etc right now and be effective. Since that isn't possible I have to assume that you have a different definition of "very familiar" than I do.
- psyc 5y ago
  It is possible. Contradiction dissolved.
  - ZephyrBlu 5y ago
    Do you know of such a person? I would love to see someone who can work in all of those roles simultaneously so I can try to learn how they're so effective across such a large number domains.
    - psyc 5y ago
      Sure. I’m like the person you replied to. It’s three things. 1) It took me 25+ years to amass the expertise. 2) It’s a hobby first, and a career second. 3) Since the beginning I always choose to see how things are the same more than how they are different. Goes for languages, hardware, APIs, OSes, protocols, everything. I insist on seeing it all as superficial variations on the same thing, no matter what anybody says. Oh but I don’t know how to do SRE. No interest.
      - withinboredom 5y ago
        Same. It took about 25+ years, and a hobby that happens to pay the bills. Interesting that you say that about how things are similar. It’s so true! The same patterns/abstractions are everywhere, just with different words in them, different orders, and sometimes, different names. I also have no interest in an SRE role. I don’t like being on-call. I build systems to fail gracefully so I never work weekends, but most people don’t do that for some reason. I currently work as a SWE. We don’t have explicit roles where I work, but my responsibilities are in-line with a principal or lead engineer.
    - camgunz 5y ago
      I've also written a Linux driver, a filesystem, IPC code across an ARM CPU and proprietary DSP, web apps in PHP, Python, React, and Go, desktop apps, data pipelines, reporting dashboards, and all kinds of other things. Same as my sibling I stay curious and say yes a lot.
- withinboredom 5y ago
  I’m active in my favorite language’s development, I work as a SWE, my current project is in a legacy system touching billions of people a year. Prior to that, I worked on a stats-heavy project that needed to make real-time decisions for millions of users at any given moment. On my free time, I work on various things like building a cockpit for a flight sim, building my own Bluetooth door lock, learning new languages and frameworks, creating SDKs for my favorite language to popular services, etc.

alluro2 5y ago

I don't think this is true - while exposure to a wider or narrower set of these domains / technologies will depend greatly by your held positions and responsibilities within teams, size of companies worked for, and raw years of experience (so it is a gradient), I would expect from an experienced web developer to simply be very familiar with all of these if they are passionate and curious about what they do. I consider myself a mediocre senior web dev, and I am can humbly say that I'm very familiar with all of the listed, without intentional effort in that direction over the years, simply because I wanted to understand the context of some of the things I needed to do, and also poke into each enough to understand how much depth there is and what I don't know. It is natural that it tends to add up. Over the years, I saw a strong correlation between that breadth and how "good" someone was - on the example of someone working on the fronted in a team, I see 3 basic categories: 1) Not very good: I can do only the most direct and specified things and if something doesn't go as implementation plan intended, or requires outside of what I see as my "formal scope" (e.g. "frontend developer", so React + CSS), I expect someone to solve it so I can continue 2) Ok, but limited: I do only the things inside my "formal scope", so if I'm building a frontend to a web app, it's someone else's responsibility to think about e.g. security - but when something doesn't go as planned along my line of work, I'll find why and unblock it 3) Good: We're building a web app, what are all the things it needs to consider and achieve? My part in the team is this UI / frontend, but if security is important for this use-case, how will my frontend be cognizant of the security goals? I should read up that OSI thing I heard about, cover the basics on my side, and start the discussion on it so we as a team ensure the frontend part is good security-wise

ZephyrBlu 5y ago
> I wanted to understand the context of some of the things I needed to do, and also poke into each enough to understand how much depth there is and what I don't know To me this is not equivalent to "very familiar". I think whakim's comment puts things well: > I use AWS day-to-day, but haven't used GCP day-to-day in 5+ years - should I realistically be able to keep abreast of the vast number of GCP changes that have happened over that time (plus all the changes in devops that make the workflows I was using 10 years ago look outdated)? Many projects don't need Websockets or Eventsource - do I have to keep that knowledge top-of-mind across the years that I don't use them? Can you really claim that you're "very familiar" with that web framework that you used two jobs ago - assuming there haven't been a bunch of major changes since then? https://news.ycombinator.com/item?id=30474206 https://news.ycombinator.com/item?id=30474206

gunapologist99 5y ago

> That person doesn't exist Just because you've never met one doesn't mean they don't exist. However, often, people like this (sadly) move into management or into higher-level architecture types of roles, and let their tech skills go fallow.