3 ms·

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 N

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.

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.