6 ms·

So how about don't be stupid about it and instead make three engineers devote 1/3 of their time to this? That way it's a broadening rather than a redirection of

by brazzy 6y ago

So how about don't be stupid about it and instead make three engineers devote 1/3 of their time to this? That way it's a broadening rather than a redirection of their career, they can help each other, the on call duties are shared, and the business isn't dependant on a single person.

mrlatinos 6y ago
Dedicating a third of my time to a language I had no previous intention of learning is going to be a hard sell, even if you label it as "broadening." If I'm a python developer, I'm now spending less time on my core competency, giving other python developers an edge. Seems like you're actually narrowing my career, unless I wish to apply for jobs seeking mediocre Erlang programmers...
- bryanrasmussen 6y ago
  >If I'm a python developer, I'm now spending less time on my core competency, giving other python developers an edge. so this argues against the theory that learning other languages and other programming paradigms makes you a better programmer in the languages you already know.
  - Leherenn 6y ago
    Or at least, that it is less valuable than spending the same time learning your core language. This might be true based on your specific situation (relatively new to the language, but already know some other varied languages); I don't know.
- Ericson2314 6y ago
  A good engineer will prefer some language(s), but be able to figure out anything should the job require it. This career track shift stuff is complete bullshit. The workers are settled and and don't want change. And there's nothing wrong with clocking in and out and not giving a shit about your "career". But there is something wrong with the managers falling for this.
- gfodor 6y ago
  If you see your identity as an engineer to be one grounded in the languages you use, you have commoditized yourself, or are at least very junior. Programmers solve problems, usually with a mix of deep skill sets revolving around domain knowledge or knowing how to use computation, systems, etc to solve them. Competency in a specific programming language is far down the list of what defines the value of a specific individual engineer to an organization or project.
  - toyg 6y ago
    Well, that’s not how programmers are recruited in the real world though. Java shops will hire Java programmers, C# shops will hire C# hands, etc etc. Marketing yourself as a generalist problem-solver will get you, at best, in one of those nightmare scenarios where you’re the only programmer in a non-tech company.
    - nicoburns 6y ago
      That's why you don't market yourself as a generalist problem-solver. You market yourself as an expert in C# AND Python AND Swift AND... whatever else you know how to use. With appropriate signalling to communicate your experience levels with each. There are lots of senior roles that require oversight of multiple projects that are working with different tech stacks. Some companies specialise in a single language. But lots of companies have say 2 or 3 backend languages (say C++, Go, and Python), plus a website in JavaScript plus mobile apps in Java/Kotlin and Swift/Objective-C. Being able to dive into all of those makes you incredibly valuable to this kind of company.
      - XorNot 6y ago
        "Javascript" though isn't Javascript. I mean it could be, but it's worthless in that context because what you actually need to be productive is familiarity with the browser DOM, current frameworks for frontend or backend, and basic project structures. For Java it might be enterprise Java, it might be Android, in which case you need familiarity with those frameworks to be productive. For Swift it'll be iOS. No one's "diving into" the codebase for an iOS app starting from "I mostly do backend web app development in Golang". Are you an "expert" in all those things? I doubt it. In fact the worst possible thing you can generally write anywhere is that you're an expert in C++ which at this point is oh-so-many subdialects.
- tpxl 6y ago
  FWIW I agree with you. I'm a Java dev and learning a language that's similar to it (C, C#, Python, whatever) does nothing for me but take away from learning more of my language. Other comments say an engineer is supposed to solve issues with the tools given to them. I can solve issues in other languages, I just don't want to. How does that make me a bad engineer?
  - rixed 6y ago
    For one, because you select your tools and reject others not based on their rational merits. Second, because you are also likely to favor recruitment of other devs based on this cultural choice not on their merit, eventually creating a clique.
    - tpxl 6y ago
      Productivity and working knowledge of a tool do not count as rational merits? It takes years to really learn a language; a new framework and language per week is a stupid fad. If I run a Java shop I want a clique of Java devs, not Golang or Rust devs.
      - rixed 6y ago
        There is some truth in this, but less than commonly believed. A "multi cultural", Jack-of-all-trades kind of team, that have a broader knowledge of many tools and techniques but less in depth familiarity with any of them, is more likely to use less features from the languages and tools that they have picked for a few of their strong points only, and less likely to indulge themselves with a level of sophistication that benefits their ego (and job security) more than the project. > If I run a Jave shop So I know a Python shop must be a business that sells reptiles, but what does a Java shop sell?
        tpxl 6y ago
        Most of the tools we use are language agnostic - databases, message brokers, containers, kubernetes, etc. >So I know a Python shop must be a business that sells reptiles, but what does a Java shop sell? Coffee obviously.
- nicoburns 6y ago
  That depends what you learn. Spending 3 months working on a Rust project has done a lot more for my ability as a JavaScript developer (my strongest language) than spending those 3 months working on a JavaScript project would have.
kenhwang 6y ago
To me, this is the sniff test of a good engineer. All the good engineers I've known would've jumped at the opportunity to learn a new technology on company time/money. The engineers that refuse to learn generally don't grow.
- gfodor 6y ago
  Yup pretty much. Esp when it’s something like Erlang that passes the sniff test as something that likely will expand your knowledge in a meaningful way, and be a long lived technology.
- setr 6y ago
  The term used within my circles is 10x1 engineers -- they've replicated their first year of experience/learning 10 times over. Biggest thing to watch out for when hiring "senior" devs
- tuxcall 6y ago
  Yes, it doesn't matter if it's a programming language or another technology. That's engineers not worth keeping around, stuck in their old ways, sooner or later they'll make themselves obsolete. I'm not a <language> programmer. I'm a programmer period.
PragmaticPulp 6y ago
> So how about don't be stupid about it and instead make three engineers devote 1/3 of their time to this? If your product-critical cloud backend depends on people being knowledgeable in a specific programming language, you don't make it a 1/3 time side project for multiple engineers. Also, if you start giving people "1/3 time" responsibilities, you're one step away from "everything is top priority" territory. The point is: If you're going to write critical pieces of your infrastructure in a specific language, it's a requirement to have at least one person full-time dedicated to that piece of infrastructure. When things go wrong at scale, you can't depend on a group of people for whom this is a part-time side project.
- ProZsolt 6y ago
  You don't give it to 3 random people. You give it to a team which depends on it. It's not a side project because if that breaks your project breaks.
  - PragmaticPulp 6y ago
    My least favorite part about HN is trying to share advice based on real-world experience, only to people show up and armchair quarterback the situation with solutions that sound easy on paper. You'll have to trust me that we didn't just throw our hands up in the air when dealing with the Erlang situation. We tried a lot of the suggestions here and more. Erlang is one of those languages that, for whatever reason, lulls engineers into a false expectation that they can pick it up over a few weekends and start knocking out IoT-scale solutions serving 6- and 7-figure connection counts. Speaking from direct experience, that's not only untrue, but it's a dangerous misconception that leads to a lot of pitfalls. Don't get me wrong, Erlang is great if your problem set matches up neatly to core OTP functionality and well-defined patterns, but you don't have to stray far until you start finding difficult pitfalls that aren't easily addressed by engineers learning Erlang on the fly.
    - ProZsolt 6y ago
      Sorry if I wasn't clear. I'm not questioning why you switched from an otherwise unused technology. Sometimes it's the best way forward. My comment is meant for this sentence: > Also, if you start giving people "1/3 time" responsibilities, you're one step away from "everything is top priority" territory. I like to maintain and improve legacy systems and usually happy to do it. When I got a separate side-project I had constantly fight with my team why I should work on project X instead of contributing to our core project. If it was my whole team responsibility they were happy that somebody does it. Also, they wanted to invest enough time so it won't break.

by brazzy 6y ago

mrlatinos 6y ago

Dedicating a third of my time to a language I had no previous intention of learning is going to be a hard sell, even if you label it as "broadening." If I'm a python developer, I'm now spending less time on my core competency, giving other python developers an edge. Seems like you're actually narrowing my career, unless I wish to apply for jobs seeking mediocre Erlang programmers...

bryanrasmussen 6y ago
>If I'm a python developer, I'm now spending less time on my core competency, giving other python developers an edge. so this argues against the theory that learning other languages and other programming paradigms makes you a better programmer in the languages you already know.
- Leherenn 6y ago
  Or at least, that it is less valuable than spending the same time learning your core language. This might be true based on your specific situation (relatively new to the language, but already know some other varied languages); I don't know.
Ericson2314 6y ago
A good engineer will prefer some language(s), but be able to figure out anything should the job require it. This career track shift stuff is complete bullshit. The workers are settled and and don't want change. And there's nothing wrong with clocking in and out and not giving a shit about your "career". But there is something wrong with the managers falling for this.
gfodor 6y ago
If you see your identity as an engineer to be one grounded in the languages you use, you have commoditized yourself, or are at least very junior. Programmers solve problems, usually with a mix of deep skill sets revolving around domain knowledge or knowing how to use computation, systems, etc to solve them. Competency in a specific programming language is far down the list of what defines the value of a specific individual engineer to an organization or project.
- toyg 6y ago
  Well, that’s not how programmers are recruited in the real world though. Java shops will hire Java programmers, C# shops will hire C# hands, etc etc. Marketing yourself as a generalist problem-solver will get you, at best, in one of those nightmare scenarios where you’re the only programmer in a non-tech company.
  - nicoburns 6y ago
    That's why you don't market yourself as a generalist problem-solver. You market yourself as an expert in C# AND Python AND Swift AND... whatever else you know how to use. With appropriate signalling to communicate your experience levels with each. There are lots of senior roles that require oversight of multiple projects that are working with different tech stacks. Some companies specialise in a single language. But lots of companies have say 2 or 3 backend languages (say C++, Go, and Python), plus a website in JavaScript plus mobile apps in Java/Kotlin and Swift/Objective-C. Being able to dive into all of those makes you incredibly valuable to this kind of company.
    - XorNot 6y ago
      "Javascript" though isn't Javascript. I mean it could be, but it's worthless in that context because what you actually need to be productive is familiarity with the browser DOM, current frameworks for frontend or backend, and basic project structures. For Java it might be enterprise Java, it might be Android, in which case you need familiarity with those frameworks to be productive. For Swift it'll be iOS. No one's "diving into" the codebase for an iOS app starting from "I mostly do backend web app development in Golang". Are you an "expert" in all those things? I doubt it. In fact the worst possible thing you can generally write anywhere is that you're an expert in C++ which at this point is oh-so-many subdialects.
tpxl 6y ago
FWIW I agree with you. I'm a Java dev and learning a language that's similar to it (C, C#, Python, whatever) does nothing for me but take away from learning more of my language. Other comments say an engineer is supposed to solve issues with the tools given to them. I can solve issues in other languages, I just don't want to. How does that make me a bad engineer?
- rixed 6y ago
  For one, because you select your tools and reject others not based on their rational merits. Second, because you are also likely to favor recruitment of other devs based on this cultural choice not on their merit, eventually creating a clique.
  - tpxl 6y ago
    Productivity and working knowledge of a tool do not count as rational merits? It takes years to really learn a language; a new framework and language per week is a stupid fad. If I run a Java shop I want a clique of Java devs, not Golang or Rust devs.
    - rixed 6y ago
      There is some truth in this, but less than commonly believed. A "multi cultural", Jack-of-all-trades kind of team, that have a broader knowledge of many tools and techniques but less in depth familiarity with any of them, is more likely to use less features from the languages and tools that they have picked for a few of their strong points only, and less likely to indulge themselves with a level of sophistication that benefits their ego (and job security) more than the project. > If I run a Jave shop So I know a Python shop must be a business that sells reptiles, but what does a Java shop sell?
      - tpxl 6y ago
        Most of the tools we use are language agnostic - databases, message brokers, containers, kubernetes, etc. >So I know a Python shop must be a business that sells reptiles, but what does a Java shop sell? Coffee obviously.
nicoburns 6y ago
That depends what you learn. Spending 3 months working on a Rust project has done a lot more for my ability as a JavaScript developer (my strongest language) than spending those 3 months working on a JavaScript project would have.

kenhwang 6y ago

To me, this is the sniff test of a good engineer. All the good engineers I've known would've jumped at the opportunity to learn a new technology on company time/money. The engineers that refuse to learn generally don't grow.

gfodor 6y ago
Yup pretty much. Esp when it’s something like Erlang that passes the sniff test as something that likely will expand your knowledge in a meaningful way, and be a long lived technology.
setr 6y ago
The term used within my circles is 10x1 engineers -- they've replicated their first year of experience/learning 10 times over. Biggest thing to watch out for when hiring "senior" devs
tuxcall 6y ago
Yes, it doesn't matter if it's a programming language or another technology. That's engineers not worth keeping around, stuck in their old ways, sooner or later they'll make themselves obsolete. I'm not a <language> programmer. I'm a programmer period.

PragmaticPulp 6y ago

> So how about don't be stupid about it and instead make three engineers devote 1/3 of their time to this? If your product-critical cloud backend depends on people being knowledgeable in a specific programming language, you don't make it a 1/3 time side project for multiple engineers. Also, if you start giving people "1/3 time" responsibilities, you're one step away from "everything is top priority" territory. The point is: If you're going to write critical pieces of your infrastructure in a specific language, it's a requirement to have at least one person full-time dedicated to that piece of infrastructure. When things go wrong at scale, you can't depend on a group of people for whom this is a part-time side project.

ProZsolt 6y ago
You don't give it to 3 random people. You give it to a team which depends on it. It's not a side project because if that breaks your project breaks.
- PragmaticPulp 6y ago
  My least favorite part about HN is trying to share advice based on real-world experience, only to people show up and armchair quarterback the situation with solutions that sound easy on paper. You'll have to trust me that we didn't just throw our hands up in the air when dealing with the Erlang situation. We tried a lot of the suggestions here and more. Erlang is one of those languages that, for whatever reason, lulls engineers into a false expectation that they can pick it up over a few weekends and start knocking out IoT-scale solutions serving 6- and 7-figure connection counts. Speaking from direct experience, that's not only untrue, but it's a dangerous misconception that leads to a lot of pitfalls. Don't get me wrong, Erlang is great if your problem set matches up neatly to core OTP functionality and well-defined patterns, but you don't have to stray far until you start finding difficult pitfalls that aren't easily addressed by engineers learning Erlang on the fly.
  - ProZsolt 6y ago
    Sorry if I wasn't clear. I'm not questioning why you switched from an otherwise unused technology. Sometimes it's the best way forward. My comment is meant for this sentence: > Also, if you start giving people "1/3 time" responsibilities, you're one step away from "everything is top priority" territory. I like to maintain and improve legacy systems and usually happy to do it. When I got a separate side-project I had constantly fight with my team why I should work on project X instead of contributing to our core project. If it was my whole team responsibility they were happy that somebody does it. Also, they wanted to invest enough time so it won't break.