3 ms·

And I'd submit that a "good" engineer is, by definition, the kind that understands when it's appropriate to use new technologies, and when it's not — and "Look,

by rosser 11y ago

And I'd submit that a "good" engineer is, by definition, the kind that understands when it's appropriate to use new technologies, and when it's not — and "Look, shiny!" isn't, IMO, a good enough reason. And pushing — let alone threatening to move on — to use new tools when they aren't appropriate? Please, go be someone else's problem.

Karunamon 11y ago
It looks like you two are in violent agreement. Here's the problem: Everything, no exceptions, starts out as "Look, shiny!". Usually, you need to play with it to find out if you even have a use case to justify spending the resources to do a formal evaluation. Reading the docs is a poor substitute for deploying it. Now what the article talks about is "shiny!" being pushed into production. No, no no no no. Never do that. There's no excuse for just dropping new untested shit into prod where customers can trip over errors - I think everyone can agree? But if hypothetical you is preventing your hypothetical engineers from indulging their curiosity and trying out new things to see if there's even a business case to be made for production use ("But there's no time" counts here), you're hamstringing the engineers and hamstringing your business.
- cookiecaper 11y ago
  Yeah, this is a good summary. There should be room for experimentation in isolated, non-production environments if the engineer in question is trusted and can propose a hypothesis better than "I think this will make my resume better". That stuff shouldn't be rushed out to prod without thorough vetting both internally and externally, which, much to the dismay of junior engineers (and not-so-junior engineers with bad judgment), often means letting a tool age a little bit before you bet the company on its stability. Unless the tool truly revolutionizes your particular line of business, and let me pre-emptively state that there's a 99.99% chance that it doesn't even if you think it does, there is no harm in letting other people be the guinea pigs.
- 15155 11y ago
  > in violent agreement. Violent agreements are lovely when they're sorted out by the market: at the moment, the best engineering talent I know would not be caught dead working on (just as an example) PHP. There's simply no need to let your skills and salary stagnate when you can get paid more for working with the state of the art elsewhere. Demand is simply too high, and like anything, there's tradeoffs: you can get anyone to do anything for enough money. But "great talent," "cheap," "low autonomy," "fossilized tools," will require some compromise.
a_small_island 11y ago
Why are you so angry? No snark, honestly just wondering what experiences has led to this in a managerial aspect

by rosser 11y ago

Karunamon 11y ago

It looks like you two are in violent agreement. Here's the problem: Everything, no exceptions, starts out as "Look, shiny!". Usually, you need to play with it to find out if you even have a use case to justify spending the resources to do a formal evaluation. Reading the docs is a poor substitute for deploying it. Now what the article talks about is "shiny!" being pushed into production. No, no no no no. Never do that. There's no excuse for just dropping new untested shit into prod where customers can trip over errors - I think everyone can agree? But if hypothetical you is preventing your hypothetical engineers from indulging their curiosity and trying out new things to see if there's even a business case to be made for production use ("But there's no time" counts here), you're hamstringing the engineers and hamstringing your business.

cookiecaper 11y ago
Yeah, this is a good summary. There should be room for experimentation in isolated, non-production environments if the engineer in question is trusted and can propose a hypothesis better than "I think this will make my resume better". That stuff shouldn't be rushed out to prod without thorough vetting both internally and externally, which, much to the dismay of junior engineers (and not-so-junior engineers with bad judgment), often means letting a tool age a little bit before you bet the company on its stability. Unless the tool truly revolutionizes your particular line of business, and let me pre-emptively state that there's a 99.99% chance that it doesn't even if you think it does, there is no harm in letting other people be the guinea pigs.
15155 11y ago
> in violent agreement. Violent agreements are lovely when they're sorted out by the market: at the moment, the best engineering talent I know would not be caught dead working on (just as an example) PHP. There's simply no need to let your skills and salary stagnate when you can get paid more for working with the state of the art elsewhere. Demand is simply too high, and like anything, there's tradeoffs: you can get anyone to do anything for enough money. But "great talent," "cheap," "low autonomy," "fossilized tools," will require some compromise.

a_small_island 11y ago

Why are you so angry? No snark, honestly just wondering what experiences has led to this in a managerial aspect