This is not true, technologies used are always outdated due to existing heavily invested old systems and clients don't wish to invest huge on new technologies.
At product companies, new technologies are must, because products are being used by many users and you have to support all new technologies. At the same time, to innovate and bring new features in the product, new features are planned to fit well in new technologies.
Interesting! I’m thinking about going in and adding definitions of what I mean by “agency” and “product company” because it makes sense that they might not hold the same meaning everywhere.
In India, they're broadly categorized into service and product companies.
Product companies follow the same definition you've mentioned in your post, and service companies can be anything from web dev agencies/startups building stuff for other companies to mass recruiters like Infosys and Accenture, who recruit tons of students through campus placements(known as career fairs in America if I'm not wrong) from nearly every single engineering and tech college, and usually allocate them randomly to support and maintenance projects, while severely underpaying them. The starting salary at these companies has been the same since 2 decades!
These huge mass recruiting MNCs have development work too, but it's like 5% of what they do.
Hence, the crazy amount of Indian people grinding Leetcode and Hackerrank, and trying to get into top-tier companies.
The company I work at is both product and service. We have our own Ed-tech products, as well as we do tech consulting and build Ed-tech products for other companies.
Not everyone’s experience is going to be the same as my own. This was mostly true at the agency I worked for and the product company I work for now. (I did say “usually” and noted an exception that’s similar to what you described.)
Let’s say both companies have frontend engineers that are really interested in using Vue. They’ve researched and decided Vue is the best frontend framework at this time. (I’m not saying this is true; this is hypothetical.)
At the product company, the existing frontend codebases are all in React. The amount of effort to convert any one of them to Vue would be astronomical. The frontend would need to be entirely rewritten. The impact to users would be minor. Even if one was switched, it would mean frontend engineers at the company would need to be experts in both React and Vue. The product company’s best bet would be to start the next new product in Vue, but maybe the company’s more invested in improving old products than creating new ones. The likelihood that these engineers will be using Vue anytime soon is unlikely.
At the agency we used Angular. If we wanted to use Vue, we’d have to wait for a new project to start that Vue would be appropriate for. Given the rate of new projects coming in at the agency, this would probably take a few months. The new project could be done in Vue, and the engineers could reflect and determine if they want to continue and use Vue on the next project and or go back to Angular. (While I presented this as a hypothetical, this actually happened at the agency after I left. They use Vue now.)
But not every agency is just like the one I worked for—some clients might have more demands about what technology is used (see my example about the client that insisted on ASP.NET—but we were still able to use .NET Core in another project). Some product-based companies have more flexibility. There are also plenty of companies that don’t fit in the “agency” or “product company” boxes.
I've been a professional C, Perl, PHP and Python developer.
I'm an ex-sysadmin from the late 20th century.
These days I do more Javascript and CSS and whatnot, and promote UX and accessibility.
I've worked for several agencies and have friends who work for product companies and my experience is broadly the same as Alli's.
Sometimes in agencies you have to use a particular technology, sometimes you get to pick and choose. As long as you can justify it to management and the client, it's usually ok - but this includes the justification that it's ok to add yet another technology to the list you have to support.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
This is not true, technologies used are always outdated due to existing heavily invested old systems and clients don't wish to invest huge on new technologies.
At product companies, new technologies are must, because products are being used by many users and you have to support all new technologies. At the same time, to innovate and bring new features in the product, new features are planned to fit well in new technologies.
I think that's mainly true for Indian agency-like companies. Not for other countries mostly.
Interesting! I’m thinking about going in and adding definitions of what I mean by “agency” and “product company” because it makes sense that they might not hold the same meaning everywhere.
In India, they're broadly categorized into service and product companies.
Product companies follow the same definition you've mentioned in your post, and service companies can be anything from web dev agencies/startups building stuff for other companies to mass recruiters like Infosys and Accenture, who recruit tons of students through campus placements(known as career fairs in America if I'm not wrong) from nearly every single engineering and tech college, and usually allocate them randomly to support and maintenance projects, while severely underpaying them. The starting salary at these companies has been the same since 2 decades!
These huge mass recruiting MNCs have development work too, but it's like 5% of what they do.
Hence, the crazy amount of Indian people grinding Leetcode and Hackerrank, and trying to get into top-tier companies.
The company I work at is both product and service. We have our own Ed-tech products, as well as we do tech consulting and build Ed-tech products for other companies.
Not everyone’s experience is going to be the same as my own. This was mostly true at the agency I worked for and the product company I work for now. (I did say “usually” and noted an exception that’s similar to what you described.)
Let’s say both companies have frontend engineers that are really interested in using Vue. They’ve researched and decided Vue is the best frontend framework at this time. (I’m not saying this is true; this is hypothetical.)
At the product company, the existing frontend codebases are all in React. The amount of effort to convert any one of them to Vue would be astronomical. The frontend would need to be entirely rewritten. The impact to users would be minor. Even if one was switched, it would mean frontend engineers at the company would need to be experts in both React and Vue. The product company’s best bet would be to start the next new product in Vue, but maybe the company’s more invested in improving old products than creating new ones. The likelihood that these engineers will be using Vue anytime soon is unlikely.
At the agency we used Angular. If we wanted to use Vue, we’d have to wait for a new project to start that Vue would be appropriate for. Given the rate of new projects coming in at the agency, this would probably take a few months. The new project could be done in Vue, and the engineers could reflect and determine if they want to continue and use Vue on the next project and or go back to Angular. (While I presented this as a hypothetical, this actually happened at the agency after I left. They use Vue now.)
But not every agency is just like the one I worked for—some clients might have more demands about what technology is used (see my example about the client that insisted on ASP.NET—but we were still able to use .NET Core in another project). Some product-based companies have more flexibility. There are also plenty of companies that don’t fit in the “agency” or “product company” boxes.
I've worked for several agencies and have friends who work for product companies and my experience is broadly the same as Alli's.
Sometimes in agencies you have to use a particular technology, sometimes you get to pick and choose. As long as you can justify it to management and the client, it's usually ok - but this includes the justification that it's ok to add yet another technology to the list you have to support.