4 ms·

You don't need to be a full-blown sysadmin to know how to do basic deployments, and learning these things will make you a better developer. Yes. True

You don't need to be a full-blown sysadmin to know how to do basic deployments, and learning these things will make you a better developer. Yes. True. However, it is also true that we have a limited amount of time per week and a limited number of weeks on Earth. Time spent learning sysadmin-y stuff is less time spent mastering developer-y stuff. Think about what it means to be a "full stack" engineer in 2023: - Unix literacy including common tools (awk, sed, grep, etc) - Docker, etc. - Relational data stores - Key/value and document stores - Base frontend technologies (HTML, CSS) - Frontend frameworks and the associated language - Build pipelines to tie it all together I've never worked with anybody who's deeply knowledgeable at all of them, or even most of them. I would submit that it is practically impossible to master all of them while also holding a full-time job and writing and shipping production code, and staying "current" on all of the above, unless you're willing to go way past 40-hour weeks. I've grown extremely disenchanted with "modern" software development. Your typical full stack engineer is frankly bad at most of the damn stack and they're not great at any of it. Nobody masters anything anymore. You get people with IQs three standard deviations above normal thinking they need to spin up an armada of AWS crap just to render "Hello World" in 2023. And they still manage to make a mess of it. I can't tell how much of this is brain damage and how much of it is a sociopathic commitment to resume-driven development. In practicality, I'm a fan of "T-shaped" engineers. Master a piece or two of the stack, and have light knowledge of the adjacent layers and what they do. e.g. If you are an application-level coder you should know what Docket/K8s/etc are and when/why you might use it and when you should eschew them. And honestly I think it should be eschewed fairly often. The places you can go with a bit of good old vertical scaling are pretty impressive in 2023. A single box with e.g. 24 cores, 64GB of RAM, and fast solid-state storage is a god damn supercomputer when it comes to spitting out web pages. Think about how far Stack Overflow got with that model and at which point you might start to outgrow them. --- edit: By "mastery" I mean "fairly comprehensive competency" and not "be a recognized global authority." You can fluently use 50-75% of what the tool offers and you know what the other 25%-50% is so you can learn it and utilize it when needed. You can ship code using this tool that is maintainable and performant. For example, perhaps you've never utilized partitioning in Postgres but you know what it is and you understand the appropriate use case for it so you can learn employ it when needed.

kcb 4y ago
Unless you're one of the very few known as top in a field, mastery of a specific technology adds very little value and is always in danger of becoming more legacy than relevant. That's in comparison to someone with enough knowledge to assist in or handle any phase of getting a product into the the hands of customers and making money. Most things don't need master level work or knowledge to be successfully implemented.
- JohnBooty 4y ago
  mastery of a specific technology adds very little value I disagree in the strongest possible terms but it's certainly possible that we're working with different definitions of "mastery" so I'll give you mine. My version is perhaps actually closer to "competency" rather than "deep under-the-hood knowledge." I'm talking about somebody who knows how to use a screwdriver without stabbing their own eyeballs out, and when to use a screwdriver, but isn't necessarily like... inventing new types of screwdrivers or innovating in the field. Somebody with Postgres "mastery" should have a strong command of basic normalized table structures, they should know how to construct useful indexes, they should know the downsides of over-indexing, they should know how to find and optimize slow queries, and they should at least know of somewhat advanced topics such as partitioning, materialized views, foreign data wrappers, and so on. It is okay not to have a clue how to set up e.g. partitioning but you should know what it is so that you can learn about it and employ it when needed. Somebody with "mastery" of an application framework such as Rails should be competent at basic OO design, they should be familiar with Ruby structures and idioms, they should understand what goes where in Rails' MVC paradigm, they should be able to write comprehensive and performant tests, and they should know how Rails' asset pipeline builds and emits front end code. I would not expect them to have mastery of Ruby's metaprogramming, but I would expect them to know what it is and have some idea of how Rails uses it to extend Ruby. (I realize Rails is controversial, but I'm not talking about anything Rails-specific. Feel free to substitute your language+framework of choice) In short, the sort of working knowledge you might commonly gain with 1-3 years of real-world production experience with a given piece of the stack. Or perhaps less if you were really focused on it and just learning it full time. Without guidance, folks with less knowledge than this tend to produce absolutely unscalable, unmaintainable spaghetti code for anything larger than a toy project. To return to the screwdriver analogy, they can kind of use a screwdriver but they're constantly stripping screwdriver heads at which point either the project is ruined or they need some help from more practiced craftsperson. always in danger of becoming more legacy than relevant I would certainly agree that you can go too deep to be useful as a "full-stack" developer. For example, if you really understand Postgres internals and can write your own extensions and have a bunch of commits in Postgres itself, cool, but what happens when our next client wants us to work on their MySQL-based app? And while Postgres is unlikely to die anytime soon, what happens if you've achieved that level of expertise in a tool that does fall by the wayside? I've certainly "mastered" a few tools that are distant memories.

kcb 4y ago

Unless you're one of the very few known as top in a field, mastery of a specific technology adds very little value and is always in danger of becoming more legacy than relevant. That's in comparison to someone with enough knowledge to assist in or handle any phase of getting a product into the the hands of customers and making money. Most things don't need master level work or knowledge to be successfully implemented.

JohnBooty 4y ago
mastery of a specific technology adds very little value I disagree in the strongest possible terms but it's certainly possible that we're working with different definitions of "mastery" so I'll give you mine. My version is perhaps actually closer to "competency" rather than "deep under-the-hood knowledge." I'm talking about somebody who knows how to use a screwdriver without stabbing their own eyeballs out, and when to use a screwdriver, but isn't necessarily like... inventing new types of screwdrivers or innovating in the field. Somebody with Postgres "mastery" should have a strong command of basic normalized table structures, they should know how to construct useful indexes, they should know the downsides of over-indexing, they should know how to find and optimize slow queries, and they should at least know of somewhat advanced topics such as partitioning, materialized views, foreign data wrappers, and so on. It is okay not to have a clue how to set up e.g. partitioning but you should know what it is so that you can learn about it and employ it when needed. Somebody with "mastery" of an application framework such as Rails should be competent at basic OO design, they should be familiar with Ruby structures and idioms, they should understand what goes where in Rails' MVC paradigm, they should be able to write comprehensive and performant tests, and they should know how Rails' asset pipeline builds and emits front end code. I would not expect them to have mastery of Ruby's metaprogramming, but I would expect them to know what it is and have some idea of how Rails uses it to extend Ruby. (I realize Rails is controversial, but I'm not talking about anything Rails-specific. Feel free to substitute your language+framework of choice) In short, the sort of working knowledge you might commonly gain with 1-3 years of real-world production experience with a given piece of the stack. Or perhaps less if you were really focused on it and just learning it full time. Without guidance, folks with less knowledge than this tend to produce absolutely unscalable, unmaintainable spaghetti code for anything larger than a toy project. To return to the screwdriver analogy, they can kind of use a screwdriver but they're constantly stripping screwdriver heads at which point either the project is ruined or they need some help from more practiced craftsperson. always in danger of becoming more legacy than relevant I would certainly agree that you can go too deep to be useful as a "full-stack" developer. For example, if you really understand Postgres internals and can write your own extensions and have a bunch of commits in Postgres itself, cool, but what happens when our next client wants us to work on their MySQL-based app? And while Postgres is unlikely to die anytime soon, what happens if you've achieved that level of expertise in a tool that does fall by the wayside? I've certainly "mastered" a few tools that are distant memories.