3 ms·

It's technically correct what you are saying but it's a "businessy" way of looking at the landscape. Developers (and orgs even more) should try and always expan

It's technically correct what you are saying but it's a "businessy" way of looking at the landscape. Developers (and orgs even more) should try and always expand their area of competence, not limit themselves to one area (not saying they should be experts in all). A good piece of tech should make you want to learn a language more (RabbitMQ/Erlang, PostgREST/Haskell, Pandoc/Haskell/).

kornish 9y ago
> It's technically correct what you are saying but it's a "businessy" way of looking at the landscape. For sure. Hence my business-oriented qualification "If an organization is going to be changing and maintaining software...". > Developers (and orgs even more) should try and always expand their area of competence, not limit themselves to one area. About developers: absolutely. Constant growth is a must. About large and mature orgs: agree. That's what R&D budgets are for. About startups: disagree. Invest only in what you need to ship product and gain differentiated competitive advantage. When there's an infinite queue of features to build and bugs to fix, not taking on unwarranted technical debt is key - and it's easiest to take on accidental technical debt when you don't have experience in a tool, language, or ecosystem. I think a point expressed elsewhere in this thread is worth reiterating: language agnostic APIs (e.g. a HTTP API) mean that I don't have to care what language something is implemented in to use it. That's a Good Thing. Learn Erlang to hack on RabbitMQ? Sure, for fun. But if I'm putting it in prod for customers, I care more about how my application code - in a language I'm strong with - interfaces with it than the internals.