3 ms·

We need to define what the term means then. Because any plonker can write js and sql after a few weeks playing around and make a mess of all of it. What is the

We need to define what the term means then. Because any plonker can write js and sql after a few weeks playing around and make a mess of all of it. What is the point of having a low bar when you're employing somebody? "C# (.NET 6), React (Typescript / Next.js), PostgreSQL, Kubernetes, Kafka, OpenTelemetry (and more)" - from https://news.ycombinator.com/item?id=31679768 https://news.ycombinator.com/item?id=31679768 Done properly, meaning to bring real value, you need to know SQL pretty well. Ditto C# (ditto, no doubt, web dev). Kafka is nontrivial software. It's not something a mortal can pick up in a few months.

christophilus 4y ago
I've never once used Kubernetes or Kafka or OpenTelemetry, but I've been "full stack" since before those technologies existed. There are plenty of full-stack Node shops. You only need JS as a language (or preferably TS, these days). And many, many companies can get away with just Postgres as their data store, with maybe a caching layer like Redis or Memcache or even an in-process cache. Heroku, Render, Fly, etc can solve the Kubernetes problem for a whole lot of projects for a very long time, so I don't think Kuberentes belongs on a "must know in order to be full-stack" list. When I first started in the industry (when C# was pre-1.0), you simply hired "engineers". Your expectation for them was that over time, they'd learn the peculiarities of your entire tech stack. But immediately, they'd be able to understand most technical problems at a fundamental level, reason about it, and give a reasonable solution with a decent list of pros / cons / tradeoffs. I've made hiring decisions for around a decade now, and that's still my expectation of an engineer. I don't expect every engineer I hire to know my stack (it's varied wildly from project to project: C#, jQuery, SQLServer, Memcache; Rails, Redis, MySQL, React; Preact, Polka, Postgres, a bunch of AWS junk; React, Hapi, ElasticSearch, etc. You don't need to know the intricacies of the full stack when you join a team. You need to be able to understand why you might need a bit of tech, and when tackling an issue, you may need to learn a new bit of tech to better solve the problem.
- Chris_Newton 4y ago
  It’s an unfortunate example of the strange priorities that seem to plague our industry. I’ve also been doing this development thing for a while now, and at this point I’m fairly sure the actual order of what matters looks something like this (most important first): 1. Solid fundamentals in development and/or infrastructure as appropriate 2. Soft skills, particularly different styles of communication and organisation 3. Domain knowledge relevant to the role/product 4. Knowledge of any specific language, tool, process or technique We could debate the order of the top two. Domain knowledge is new to almost everyone when they first start a new role, unless they happen to have worked for someone else in the same field before. The specific technologies are rarely going to be an exact match, but that doesn’t matter as long as someone has good general knowledge and the motivation to quickly learn new tech when they need to. I can’t help feeling that a lot of problems in a lot of development groups would vanish if hiring was based on looking for good fundamentals and a professional approach rather than strict buzzword compliance, and if the day-to-day working environment then supported good people doing deep work. It’s not really surprising that some people think every new technology will take weeks to learn and capable full-stack developers are mythical creatures when you look at the environments and hiring processes they are stuck with, but it doesn’t have to be that way and of course the better developers are drawn to the places that aren’t, which continues the cycle.
  - zasdffaa 4y ago
    > if hiring was based on looking for good fundamentals and a professional approach rather than strict buzzword compliance Thank you
- zasdffaa 4y ago
  > I've made hiring decisions for around a decade now, and that's still my expectation of an engineer That sounds like the kind of reasonableness that just does not come across to me when I read so many job adverts. When I read 'full stack' it says to me 'know this stuff', otherwise you should put "we need this and you also need to learn x, y, z, ..." as the need arises. I can do that.
icambron 4y ago
Counterpoint: it is absolutely something you could know all of. In your example, I’d describe myself has highly proficient in c#, Typescript, React, Postgres, and Kafka, proficient at Kubernetes, and unfamiliar with OpenTelemetry. That’s just a list of common tools, and if the list were different, I’d be pretty confident I could learn whatever I was missing on the job. Tools are usually the easy part. I agree you need to know all those things pretty well, but I don’t think that’s a huge ask. You can definitely pick up Kafka in a few months. Look, maybe all that’s not your thing, which is fine, but knowing a wide range of tools and being comfortable in any part of the architecture isn’t some crazy rare skillset known only to certain cyborgs. It’s certainly not idiocy to seek those people out.
- zasdffaa 4y ago
  I've been doing sql for decades. You can learn sql in weeks, a few months to get good at it, longer to get good at relational data modelling (I've seen some non-normalised messes) and years to learn the database underneath to get solid scalable performance out of it - and if you don't your business may sink. I think it fair to say if it had not been for me, 2 successful business would have died due to sql perf. problems. Edit: what this means is if you go for a shallow skill level it works at first but may cost later, and very heavily. Good back-end langauge skills, well, I can pick up C# in a few weeks and indeed did - because I had a ton of other language experience behind me. That isn't something you get in a few months - and I mean not just the language but the whole gamut of techniques for solid programming, and you can add functional programming on top. Then you need to understand about garbage generation and big-oh costs of algorithms so you don't do twatty things with linked lists. How about web dev? I know more about html/http/user interfaces than most web devs do and you don't have to look far to see the mess they made (I choose not to be a web dev). Maybe I set the bar high but when I see a list of skills, I assume it means "be actually good in these" not "pickem up as you go along" Perhaps people should be more clear about what they want. > It’s certainly not idiocy to seek those people out. Maybe you aren't looking for the level of skill that I assume you are. But be clear what full-stack means because others (me) may misunderstand it.
  - icambron 4y ago

christophilus 4y ago

I've never once used Kubernetes or Kafka or OpenTelemetry, but I've been "full stack" since before those technologies existed. There are plenty of full-stack Node shops. You only need JS as a language (or preferably TS, these days). And many, many companies can get away with just Postgres as their data store, with maybe a caching layer like Redis or Memcache or even an in-process cache. Heroku, Render, Fly, etc can solve the Kubernetes problem for a whole lot of projects for a very long time, so I don't think Kuberentes belongs on a "must know in order to be full-stack" list. When I first started in the industry (when C# was pre-1.0), you simply hired "engineers". Your expectation for them was that over time, they'd learn the peculiarities of your entire tech stack. But immediately, they'd be able to understand most technical problems at a fundamental level, reason about it, and give a reasonable solution with a decent list of pros / cons / tradeoffs. I've made hiring decisions for around a decade now, and that's still my expectation of an engineer. I don't expect every engineer I hire to know my stack (it's varied wildly from project to project: C#, jQuery, SQLServer, Memcache; Rails, Redis, MySQL, React; Preact, Polka, Postgres, a bunch of AWS junk; React, Hapi, ElasticSearch, etc. You don't need to know the intricacies of the full stack when you join a team. You need to be able to understand why you might need a bit of tech, and when tackling an issue, you may need to learn a new bit of tech to better solve the problem.

Chris_Newton 4y ago
It’s an unfortunate example of the strange priorities that seem to plague our industry. I’ve also been doing this development thing for a while now, and at this point I’m fairly sure the actual order of what matters looks something like this (most important first): 1. Solid fundamentals in development and/or infrastructure as appropriate 2. Soft skills, particularly different styles of communication and organisation 3. Domain knowledge relevant to the role/product 4. Knowledge of any specific language, tool, process or technique We could debate the order of the top two. Domain knowledge is new to almost everyone when they first start a new role, unless they happen to have worked for someone else in the same field before. The specific technologies are rarely going to be an exact match, but that doesn’t matter as long as someone has good general knowledge and the motivation to quickly learn new tech when they need to. I can’t help feeling that a lot of problems in a lot of development groups would vanish if hiring was based on looking for good fundamentals and a professional approach rather than strict buzzword compliance, and if the day-to-day working environment then supported good people doing deep work. It’s not really surprising that some people think every new technology will take weeks to learn and capable full-stack developers are mythical creatures when you look at the environments and hiring processes they are stuck with, but it doesn’t have to be that way and of course the better developers are drawn to the places that aren’t, which continues the cycle.
- zasdffaa 4y ago
  > if hiring was based on looking for good fundamentals and a professional approach rather than strict buzzword compliance Thank you
zasdffaa 4y ago
> I've made hiring decisions for around a decade now, and that's still my expectation of an engineer That sounds like the kind of reasonableness that just does not come across to me when I read so many job adverts. When I read 'full stack' it says to me 'know this stuff', otherwise you should put "we need this and you also need to learn x, y, z, ..." as the need arises. I can do that.

icambron 4y ago

Counterpoint: it is absolutely something you could know all of. In your example, I’d describe myself has highly proficient in c#, Typescript, React, Postgres, and Kafka, proficient at Kubernetes, and unfamiliar with OpenTelemetry. That’s just a list of common tools, and if the list were different, I’d be pretty confident I could learn whatever I was missing on the job. Tools are usually the easy part. I agree you need to know all those things pretty well, but I don’t think that’s a huge ask. You can definitely pick up Kafka in a few months. Look, maybe all that’s not your thing, which is fine, but knowing a wide range of tools and being comfortable in any part of the architecture isn’t some crazy rare skillset known only to certain cyborgs. It’s certainly not idiocy to seek those people out.

zasdffaa 4y ago
I've been doing sql for decades. You can learn sql in weeks, a few months to get good at it, longer to get good at relational data modelling (I've seen some non-normalised messes) and years to learn the database underneath to get solid scalable performance out of it - and if you don't your business may sink. I think it fair to say if it had not been for me, 2 successful business would have died due to sql perf. problems. Edit: what this means is if you go for a shallow skill level it works at first but may cost later, and very heavily. Good back-end langauge skills, well, I can pick up C# in a few weeks and indeed did - because I had a ton of other language experience behind me. That isn't something you get in a few months - and I mean not just the language but the whole gamut of techniques for solid programming, and you can add functional programming on top. Then you need to understand about garbage generation and big-oh costs of algorithms so you don't do twatty things with linked lists. How about web dev? I know more about html/http/user interfaces than most web devs do and you don't have to look far to see the mess they made (I choose not to be a web dev). Maybe I set the bar high but when I see a list of skills, I assume it means "be actually good in these" not "pickem up as you go along" Perhaps people should be more clear about what they want. > It’s certainly not idiocy to seek those people out. Maybe you aren't looking for the level of skill that I assume you are. But be clear what full-stack means because others (me) may misunderstand it.
- icambron 4y ago