2 ms·

resists learning anything about the other technologies in his projects' tech stacks Sorry for quoting out of context, but I also do that. The reasoning goes: w

by wruza 4y ago

resists learning anything about the other technologies in his projects' tech stacks Sorry for quoting out of context, but I also do that. The reasoning goes: when I have to do something and it’s clear how to do it, there is no need for “the other way”. I perceive it as changing routes daily just for novelty, against boredom. Old tools have nuances, so do new ones. But the work is done by me + tools, so the best combination is me + what I know to the bone. Is this bad for a developer? Does that stress colleagues often? No catch, just asking. And I do learn ofc, after some “it sucks too much” threshold. But years of early development taught me to raise that bar much higher than my procrastination pikes, otherwise I end up in a loop of jumping tech and never get satisfied. Edit: to make it clear, other described “traits” I do not have.

LordGrey 4y ago
I think your approach to this situation is fine. There are poor ways to handle it, though. A recent example: The developer maintains a tool that communicates with another internal system maintained by another group. That system is being migrated from a suite of applications running on internal blades to something that runs on kubernetes. The migration affects how processes are accessed (IP addresses and ports), and changes are required on our end. This developer does not know anything about kubernetes and does not know anything about the changes in the other system. He does not understand why any access methods may have changed, and he is irritated that an external system is pushing a new requirement onto his task list when it worked perfectly fine before. To be fair, he does not need to know anything about kubernetes to make this change, but his resistance to the modification almost demanded an explanation of why it is necessary, and then it devolved into the situation I just described.
- troon-lover 4y ago
- bluefirebrand 4y ago
  > he is irritated that an external system is pushing a new requirement onto his task list when it worked perfectly fine before. Imo, He's honestly entirely justified in being annoyed by this. It sounds like the other team has unilaterally decided to complicate things by migrating to kubernetes and breaking backwards compatibility. If it's just as simple as updating config files to point to new IP addresses that's one thing (which would be better solved with DNS honestly) but it sounds like it's a bigger breaking change than that, which is kind of bullshit. If you are changing an internal service at a company it's your job to get buy in from the clients of your service beforehand, not just cram the changes forward and expect them to adapt.
toast0 4y ago
> Is this bad for a developer? Does that stress colleagues often? No catch, just asking. I dunno if it's bad for you, but it's often better for the business to use fewer tools that are good enough than to use more tools that are perfect. There are often people that need to go between tasks for various reasons, and when tasks share tools, it can be easier to understand what's going on. For colleagues, a team member that's always trying to pull in new tools is causing stress because someone needs to redirect them towards using something already there.

by wruza 4y ago

LordGrey 4y ago

I think your approach to this situation is fine. There are poor ways to handle it, though. A recent example: The developer maintains a tool that communicates with another internal system maintained by another group. That system is being migrated from a suite of applications running on internal blades to something that runs on kubernetes. The migration affects how processes are accessed (IP addresses and ports), and changes are required on our end. This developer does not know anything about kubernetes and does not know anything about the changes in the other system. He does not understand why any access methods may have changed, and he is irritated that an external system is pushing a new requirement onto his task list when it worked perfectly fine before. To be fair, he does not need to know anything about kubernetes to make this change, but his resistance to the modification almost demanded an explanation of why it is necessary, and then it devolved into the situation I just described.

troon-lover 4y ago
bluefirebrand 4y ago
> he is irritated that an external system is pushing a new requirement onto his task list when it worked perfectly fine before. Imo, He's honestly entirely justified in being annoyed by this. It sounds like the other team has unilaterally decided to complicate things by migrating to kubernetes and breaking backwards compatibility. If it's just as simple as updating config files to point to new IP addresses that's one thing (which would be better solved with DNS honestly) but it sounds like it's a bigger breaking change than that, which is kind of bullshit. If you are changing an internal service at a company it's your job to get buy in from the clients of your service beforehand, not just cram the changes forward and expect them to adapt.

toast0 4y ago

> Is this bad for a developer? Does that stress colleagues often? No catch, just asking. I dunno if it's bad for you, but it's often better for the business to use fewer tools that are good enough than to use more tools that are perfect. There are often people that need to go between tasks for various reasons, and when tasks share tools, it can be easier to understand what's going on. For colleagues, a team member that's always trying to pull in new tools is causing stress because someone needs to redirect them towards using something already there.