«Who’s going to support any Elixir code? What if you get hit by a bus? (which reads: «please stop what you’re doing, you’re harming the team and the company«)
It’s a little more subtle than that I think. OK, the author is a Star Trek fan, right? Remember when they had a critical mission to get help for a kid on the ship, and then Data goes nuts and takes over the ship, flying it to a different destination? That could be what the author is doing from their team’s perspective.
I’ve observed two major projects where a single engineer decided on a different language from what the rest of the team was using without getting at least a few other people on board, and the result has been consistent: the project either dies, or gets or rewritten in the language the rest of the group already knows.
Who’s going to support any Elixir code? What if you get hit by a bus? (which reads: «please stop what you’re doing, you’re harming the team and the company«)
No, that interpretation is completely wrong. It’s “I’m concerned you haven’t established buy in and you’ll leave us with a hard to understand, unmaintainable project that we can’t onboard people”. And that’s a valid concern in engineering.
If the author doesn’t get that, then perhaps they’re too immature to make a case for adopting a new language because they see their coworkers as negative, obstructive presences that do not recognize their greatness. Such engineers are usually under-seasoned and haven’t yet grasped that engineering is a team effort.
«If some of us take the plunge and learn Elixir, how relevant will we be with the job market and its then-current trends in say 5 years?«
That’s people speak for “sell me on Elixir”. And they’re right - finding engineering jobs is often linked to matching a set of buzzword languages and they’re uncomfortable at the thought of being challenged with “why would you use Elixir? Is there a market fit for it?” You’re a language advocate, tell them how the language helped you become better at accomplishing your tasks and how that translates to being more capable and marketable.
I recognize in the author some of myself earlier in my career. Because of my “I am so productive, so smart” attitude, it left me easily exploited and over stressed. I’ve since drawn back to getting buy in from my team and trusting them, as I believe they have genuine intent to help out. I often spend more time listening to them in meetings than commenting as I’m trying to get a feeling for what the team feels they can handle.
I recognize in the author some of myself earlier in my career. Because of my “I am so productive, so smart” attitude, it left me easily exploited and over stressed.
Yeah, this keeps biting me too. I know it’s a problem and I try to challenge myself on it, but it’s an easy trap to fall into. When did you realize it was an issue for you? How did you break the cycle?
Glad you asked!! 🙂 I realized I had a problem when at my previous job when I noticed I felt on edge all the time, watching the #sentry-alert channel 24/7, and had an eventual breakdown where I ended up running into the woods to cry and another breakdown at work two days later. It was at that point I came to terms that I was feeling anxious 24/7, I wasn’t happy, and I needed a therapist to work with me on relearning emotions and anxiety management.
I left that job and decided that the next one would be on my terms, that I would consciously avoid becoming “the indispensable engineer”, and I would not let myself become addicted to work. When you’re “indispensable”, you’re never allowed to take time off and in the end, you and everyone else are quite disposable. All things have an end and being “indispensable” is an illusion.
I focused my job search purely off of culture fit and respect. No personal attacks allowed, period. I’ll accept heated emotions but I decided that even a hint of personal attacks was a sure sign of an abusive environment and that was only going to hurt me. I guess “psychological safety” was at the forefront of my mind. We will always make mistakes and we need a culture where you can try for more, screw up, admit it and ask for help. Environments where that doesn’t exist means that people do as little as possible to avoid the blame. I needed the flexibility to “not be perfect”. And I needed a place where people could rely on me to just help with a problem and never blame. In return, I could also get help without getting blamed.
When I got the job I’m at now, my first real action on handling that overwhelming issue of being “do everything” was to set hard time boundaries at work - when it was after work and on the weekend, I would not fix something until the next applicable workday or unless someone specifically reached out to me and we both agreed after a discussion that it was important enough to fix right now. If it wasn’t a demonstrable P0 that had actual business consequences, then it was to be done later.
My second act was to focus on “getting a life”. And doing that required my to really think about what I was using work to avoid handling and take that to my therapist to help me tackle those issues.
TL; DR - I got a therapist, set boundaries and focused on getting a life. 😁
This is not at all how you persuade coworkers to use a different programming language.
I would recommend that the author watch Lessons Learned from Adopting Clojure.
Jay Fields describes in detail how he got DRW to use Clojure.
It’s a little more subtle than that I think. OK, the author is a Star Trek fan, right? Remember when they had a critical mission to get help for a kid on the ship, and then Data goes nuts and takes over the ship, flying it to a different destination? That could be what the author is doing from their team’s perspective.
I’ve observed two major projects where a single engineer decided on a different language from what the rest of the team was using without getting at least a few other people on board, and the result has been consistent: the project either dies, or gets or rewritten in the language the rest of the group already knows.
No, that interpretation is completely wrong. It’s “I’m concerned you haven’t established buy in and you’ll leave us with a hard to understand, unmaintainable project that we can’t onboard people”. And that’s a valid concern in engineering.
If the author doesn’t get that, then perhaps they’re too immature to make a case for adopting a new language because they see their coworkers as negative, obstructive presences that do not recognize their greatness. Such engineers are usually under-seasoned and haven’t yet grasped that engineering is a team effort.
That’s people speak for “sell me on Elixir”. And they’re right - finding engineering jobs is often linked to matching a set of buzzword languages and they’re uncomfortable at the thought of being challenged with “why would you use Elixir? Is there a market fit for it?” You’re a language advocate, tell them how the language helped you become better at accomplishing your tasks and how that translates to being more capable and marketable.
I recognize in the author some of myself earlier in my career. Because of my “I am so productive, so smart” attitude, it left me easily exploited and over stressed. I’ve since drawn back to getting buy in from my team and trusting them, as I believe they have genuine intent to help out. I often spend more time listening to them in meetings than commenting as I’m trying to get a feeling for what the team feels they can handle.
Yeah, this keeps biting me too. I know it’s a problem and I try to challenge myself on it, but it’s an easy trap to fall into. When did you realize it was an issue for you? How did you break the cycle?
Glad you asked!! 🙂 I realized I had a problem when at my previous job when I noticed I felt on edge all the time, watching the
#sentry-alertchannel 24/7, and had an eventual breakdown where I ended up running into the woods to cry and another breakdown at work two days later. It was at that point I came to terms that I was feeling anxious 24/7, I wasn’t happy, and I needed a therapist to work with me on relearning emotions and anxiety management.I left that job and decided that the next one would be on my terms, that I would consciously avoid becoming “the indispensable engineer”, and I would not let myself become addicted to work. When you’re “indispensable”, you’re never allowed to take time off and in the end, you and everyone else are quite disposable. All things have an end and being “indispensable” is an illusion.
I focused my job search purely off of culture fit and respect. No personal attacks allowed, period. I’ll accept heated emotions but I decided that even a hint of personal attacks was a sure sign of an abusive environment and that was only going to hurt me. I guess “psychological safety” was at the forefront of my mind. We will always make mistakes and we need a culture where you can try for more, screw up, admit it and ask for help. Environments where that doesn’t exist means that people do as little as possible to avoid the blame. I needed the flexibility to “not be perfect”. And I needed a place where people could rely on me to just help with a problem and never blame. In return, I could also get help without getting blamed.
When I got the job I’m at now, my first real action on handling that overwhelming issue of being “do everything” was to set hard time boundaries at work - when it was after work and on the weekend, I would not fix something until the next applicable workday or unless someone specifically reached out to me and we both agreed after a discussion that it was important enough to fix right now. If it wasn’t a demonstrable P0 that had actual business consequences, then it was to be done later.
My second act was to focus on “getting a life”. And doing that required my to really think about what I was using work to avoid handling and take that to my therapist to help me tackle those issues.
TL; DR - I got a therapist, set boundaries and focused on getting a life. 😁
This is not at all how you persuade coworkers to use a different programming language.
I would recommend that the author watch Lessons Learned from Adopting Clojure.
Jay Fields describes in detail how he got DRW to use Clojure.
Not knowing Star Trek that well, I thought that the Prime Directive was about the Prime Directive of Agile Retrospective (https://www.retrospectivewiki.org/index.php?title=The_Prime_Directive)