Well, I'm the QA guy, so choosing development technology isn't in my list of responsibilities. We use Selenium, these days with Java, to handle our automated UI. Still, I can't help but listen to the developers gnaw on their leashes, right? We're a large enough enterprise that the preferences of the guys at the keyboard doing the coding is very nearly irrelevant in comparison to stated corporate strategies, so when an engineering lead says use Go, there's plenty of opinions getting thrown around.
First Pushback
Why?
That's right. Any good engineer starts with "why". Sometimes, this actually works. It kind of depends on your audience though. Customers and clients usually never have a clear understanding for asking for a specific technology, so starting with this question usually gives the engineer a good bit of leverage over what happens next when choosing a tech stack. This is important. A developer who uses a stack he is familiar with is more likely to succeed in producing working software. There's a problem though when the person making the request is a senior engineer charged with making such decisions.
Second Pushback
It'll slow me down.
As mentioned before, the developer who uses familiar tools is more likely to succeed. It's also true that he'll succeed faster using tools he knows. In the case of talking with a senior engineer, this argument also might work. If enough of the team has no experience with a tool, the case might be strong enough to choose a tool everyone is more familiar with. It might not always be the tried and true tools the older engineers know, but it also might not be the newest shiny new thing. This argument can also be pushed aside to carry out some overriding need. Sometimes a company commits to things publicly in a big way, which then dictates what happens next.
Final Argument
Tread lightly.
The technology field has a reputation for being a young man's game. I don't particularly know why, and I refuse to guess because I taught myself programming at 34 years old and have been on quite a ride in the last 6 years. I don't argue against learning new things for a few very good reasons. Every new technology is a new bullet point. New technology smells like "innovation" to the entrepreneur class. This means that employment follows almost more assuredly than being an expert in a particular stack. I'm not saying you should never get good, that's always the right goal. It's just equally prudent to put on new hats every so often.
First Pushback
Why?
That's right. Any good engineer starts with "why". Sometimes, this actually works. It kind of depends on your audience though. Customers and clients usually never have a clear understanding for asking for a specific technology, so starting with this question usually gives the engineer a good bit of leverage over what happens next when choosing a tech stack. This is important. A developer who uses a stack he is familiar with is more likely to succeed in producing working software. There's a problem though when the person making the request is a senior engineer charged with making such decisions.
Second Pushback
It'll slow me down.
As mentioned before, the developer who uses familiar tools is more likely to succeed. It's also true that he'll succeed faster using tools he knows. In the case of talking with a senior engineer, this argument also might work. If enough of the team has no experience with a tool, the case might be strong enough to choose a tool everyone is more familiar with. It might not always be the tried and true tools the older engineers know, but it also might not be the newest shiny new thing. This argument can also be pushed aside to carry out some overriding need. Sometimes a company commits to things publicly in a big way, which then dictates what happens next.
Final Argument
Tread lightly.
The technology field has a reputation for being a young man's game. I don't particularly know why, and I refuse to guess because I taught myself programming at 34 years old and have been on quite a ride in the last 6 years. I don't argue against learning new things for a few very good reasons. Every new technology is a new bullet point. New technology smells like "innovation" to the entrepreneur class. This means that employment follows almost more assuredly than being an expert in a particular stack. I'm not saying you should never get good, that's always the right goal. It's just equally prudent to put on new hats every so often.
