|
|
|
|
|
by pawelwentpawel
1342 days ago
|
|
From a perspective of a coder on a team, I think that strategically selecting which novel things to learn is a good thing career-wise. Fun aspect aside, one gets paid to learn new stuff which can later result in better future opportunities. As an example, as a junior dev back in 2015 or so, I was told to use one of the very first versions of Swift to develop a production-ready mobile app. Was it fun? Totally! Did I learn a lot? Absolutely! Did we almost trash the project and had a massive delay because of the early bugs, problems, refactoring with new updates, and because we were still learning? Hell yeah! The final payoff was pretty good for developers, but not for the final business objective which was getting a product out ASAP. Our users didn't care about what tech we used. Following from the above, I think it's important to distinguish two different aspects of the novelty - one is completely new tech ('global' - new to everyone) and the second is tech that's new to the team that is about to use it (let's call it 'local'). Global: That's the hole we got into using the first version of Swift. The team got stuck with problems that no one has ever had yet and we had to invest our time to solve them. The biggest risk was ending up with a completely new problem and no guarantee that anyone on your team will be able to solve it. There is no Github issue for it and no helpful stranger on Stack Overflow. It's pretty bad if it happens in a critical area. From a project perspective, I'd say it's better to wait for someone else's time and money budget to iron those problems out first if you want to increase your chances of having a production-ready product within a predictable timeframe. Local: This comes with a different set of risks. If you're working within a larger organization, how many other developers know this newly introduced tech? If the team that has introduced it quits, will there be anyone able to pick it up? If your project is on a critical deadline, do you have enough time to let developers get up to speed? I'd think about this decision from the perspective of investment. Ironically, I have also experienced the reverse - some companies use tech so old that developers have to learn it as something completely novel. The only dev that maintained the codebase might be retiring and the option is to rewrite or hire a person with a spark for archeology. |
|