4 ms·
If you're starting a one man project, just take the one you're being the most productive in. If the project is a team effort, then it comes down to the team pre
by nedsma 10y ago
If you're starting a one man project, just take the one you're being the most productive in. If the project is a team effort, then it comes down to the team preferences or team members' willingness to change. From my experience, team adopting a completely new language isn't the big deal per se, more difficult is team dynamics, requirements/people changes, hiring new team members especially if your area can't provide many people with desired skillset. Take a look around what's the trend locally, for the vast majority of projects it's more important to deliver a quality project on time, than to code in a, now matter how, exotic (and other super attributes) language.
- eddieroger 10y ago"Go with what you know." It even rhymes. I'm all for learning stuff, and if I'm working on a project that has no particular deadline (or a deadline that's far enough out that I can deal with frustrations of learning), by all means use new and shiny. But if I have a real goal and a deadline, I'm going to use something I already know in and out so I can spend my time making, not learning. If I get something to production and find that it's performance is horrendous, I can always come back and optimize (or rewrite) later, but it's better to get something out and see if it even works than to be fighting a new syntax or picking middleware.
- nedsma 10y agoWe're on the same page here. :thumbs-up: