3 ms·

Hell, I've seen this as a lead/senior engineer. I'm seeing it right now, in fact, as a person on our team wants to write some stuff in language X, which nobody

by sidlls 9y ago

Hell, I've seen this as a lead/senior engineer. I'm seeing it right now, in fact, as a person on our team wants to write some stuff in language X, which nobody else on the team has experience with, and which isn't used anywhere else in the company, and to solve a problem that is perfectly well solved (in both development time and performance) with the language and tooling we already use. As far as I can tell this engineer just wants to stick "built stuff in X" on his resume. He doesn't have a good reason to not use our existing stack. If I were the manager I'd demand more technical justification.

dmoy 9y ago
To be fair I've been on the underling side of that where I wanted to build some new server we needed in a new language (coincidentally, Golang), but it was honestly just for curiosity/shits&giggles. It became somewhat of a running gag for ~5 years where every new service we needed I'd suggest Golang.
criddell 9y ago
I'm a senior engineer and I'm also the person that wants to use the shiny new thing. I'm just learning Go and I'm itching to find a project to use it on. It's super hard to justify it though when C# or Python would work just as well and those are languages that we already use.
- sidlls 9y ago
  The best time to do it is on a new project or component of an existing system, in my opinion. It doesn't make it a good idea, but it can be a nice way to introduce something new and possibly more productive.
richardknop 9y ago
But this also might be a problem of a company not providing any improvement / career prospects for your programmers. If working as a programmer means sticking to C# or Visual Basic or Python codebase and just working on adding new features or new business logic to your application for years and years, many engineers will not find that fulfilling. The best engineers will always want to learn about new tech and approaches (dev ops, containers, PaaS, automation, new languages and tools, AI / machine learning etc). You cannot blame them for leaving. What you should instead do is provide interesting challenges for them, if they want to use some new technology, work on finding a justifiable use case that management will approve for it. I understand that for a company that treats tech as a cost centre this approach makes sense but then they can't wonder when best engineers keep leaving to proper tech companies that do actual R&D and where they can become best engineers they can be. You need to allow your best programmers to learn new tech and progress in their career or else they'll eventually leave for greener pastures and you'll be left with mediocre people who are content and don't want to learn new things. It's like that analogy I have heard over and over again. CFO asking CTO: What happens if we invest in developing / training our people and they leave? CEO replies: What happens if we don't and they stay?
- sidlls 9y ago
  This has nothing to do with whether engineering is a "cost center" or not. It's about fundamentally what is important about the practice of engineering. Whether to use Python or Go or Java or Rust or whatever is rarely anything other than bike shedding. In those cases where it's not, the key problems are rarely which language is technically better: more often the problems are associated with labor supply and how well the proposed language' ecosystem plays with existing implementations'.

by sidlls 9y ago

dmoy 9y ago

To be fair I've been on the underling side of that where I wanted to build some new server we needed in a new language (coincidentally, Golang), but it was honestly just for curiosity/shits&giggles. It became somewhat of a running gag for ~5 years where every new service we needed I'd suggest Golang.

criddell 9y ago

I'm a senior engineer and I'm also the person that wants to use the shiny new thing. I'm just learning Go and I'm itching to find a project to use it on. It's super hard to justify it though when C# or Python would work just as well and those are languages that we already use.

sidlls 9y ago
The best time to do it is on a new project or component of an existing system, in my opinion. It doesn't make it a good idea, but it can be a nice way to introduce something new and possibly more productive.

richardknop 9y ago

But this also might be a problem of a company not providing any improvement / career prospects for your programmers. If working as a programmer means sticking to C# or Visual Basic or Python codebase and just working on adding new features or new business logic to your application for years and years, many engineers will not find that fulfilling. The best engineers will always want to learn about new tech and approaches (dev ops, containers, PaaS, automation, new languages and tools, AI / machine learning etc). You cannot blame them for leaving. What you should instead do is provide interesting challenges for them, if they want to use some new technology, work on finding a justifiable use case that management will approve for it. I understand that for a company that treats tech as a cost centre this approach makes sense but then they can't wonder when best engineers keep leaving to proper tech companies that do actual R&D and where they can become best engineers they can be. You need to allow your best programmers to learn new tech and progress in their career or else they'll eventually leave for greener pastures and you'll be left with mediocre people who are content and don't want to learn new things. It's like that analogy I have heard over and over again. CFO asking CTO: What happens if we invest in developing / training our people and they leave? CEO replies: What happens if we don't and they stay?

sidlls 9y ago
This has nothing to do with whether engineering is a "cost center" or not. It's about fundamentally what is important about the practice of engineering. Whether to use Python or Go or Java or Rust or whatever is rarely anything other than bike shedding. In those cases where it's not, the key problems are rarely which language is technically better: more often the problems are associated with labor supply and how well the proposed language' ecosystem plays with existing implementations'.