3 ms·

I'm struggling with this exact thing at work, but the problem is that I'm terrible at "generating excitement" for my direction. I treat all my coworkers as peer

I'm struggling with this exact thing at work, but the problem is that I'm terrible at "generating excitement" for my direction. I treat all my coworkers as peers, with full respect and compassion and without telling them what to do. Whenever I try to gently nudge them in my direction, I get a heap of pushback. If it's not clear, I'm also terrible at persuasion and influencing people, so I don't really know how to fix this situation. I like my company and my boss, but my brain is screaming "CHANGE YOUR ORGANIZATION OR CHANGE YOUR ORGANIZATION" 24/7. Any suggestions?

v-erne 5y ago
Disclaimer: Unfortunately I believe that engaging others is always a case of emotional intelligence and communication skills. There is no amount of rational arguments that can bring them on Your side if they do not feel that You are right. With emphasis on feel - we all are highly irrational creatures and almost all decisions are emotional. If You do not understand what kind of feelings Your communications (both verbal and written) generates in Your team mates than You will never be highly effective with convincing anyone to bring on any kind of change. Having said that, can You describe what kind of direction You are talking about? What type of change do You want to see and why do You thing there is pushback?
- activitypea 5y ago
  I'll try to do it without doxxing myself too much. The team is criminally prone to overengineering. Feels like they read GoF and Uncle Bob's stuff, stopped there and concluded that engineering is a solved problem, with no tradeoffs involved. They're writing 2003-style Java in a language that's not particularly conducive to OOP (Javascript). Any time I solve something by writing a plain old function, my MRs are brigaded with kind suggestions that have an undertone of condescension. "Do you think this would be better solved by implementing the [Strategy pattern]?", "This hashmap seems a little out of place, have you considered adding some encapsulation here?" etc. The signal to noise ratio in the codebase is woeful and finding out how anything works requires a JetBrains IDE and spelunking gear. I don't mind that, I love brownfield projects. The problem is that we keep moving in this direction and that I'm being forced, or at least firmly suggested, to keep producing more "brown". The lead agrees that the codebase could be improved, but believes the churn (a couple of longstanding members with a revolving door of people) is on par with the rest of the industry and since the company is happy with us why fix what isn't broken. The team lead also don't code pretty much at all, so it's hard for them to perceive it as a priority. And the company is happy with us because the specific work we're doing is incredibly valuable -- we could be doing half as good. and still blow every other team out of the water because of the intrinsic value of our work. As long as our production doesn't go down every other day, we're the starchildren :\
  - v-erne 5y ago
    Is this overengineering attitude coming from those few longstanding members? Because if so, I don't see how You can convince them of the value of simplicity (and that any kind of abstraction have a cost) if they themselves does not see value in it. This intuition can only come from long exposition to consequences of adding to much of accidental complexity. And what is more by openly contradicting their intuitions You directly threaten their status in company (because Your solutions will be directly opposing their way of solving things). There is of course second possibility - are You sure that the problem is not You ? Are there other team members that also complain? OOP style of programming takes a lot of time to get used to, but sometimes it can work if programmers are familiar enough with it. The use of strategy pattern can be good if there is enough variability in parts of algorithm that is being implemented. Personally I hate this style but its because I lack imagination (which is necessary to select proper patterns and create proper abstractions). I can only create them as an afterthought (by extracting them from existing codebase). But I know that there are people that can do it up front and hit the right spot enough times (and refactor if not).

v-erne 5y ago

Disclaimer: Unfortunately I believe that engaging others is always a case of emotional intelligence and communication skills. There is no amount of rational arguments that can bring them on Your side if they do not feel that You are right. With emphasis on feel - we all are highly irrational creatures and almost all decisions are emotional. If You do not understand what kind of feelings Your communications (both verbal and written) generates in Your team mates than You will never be highly effective with convincing anyone to bring on any kind of change. Having said that, can You describe what kind of direction You are talking about? What type of change do You want to see and why do You thing there is pushback?

activitypea 5y ago
I'll try to do it without doxxing myself too much. The team is criminally prone to overengineering. Feels like they read GoF and Uncle Bob's stuff, stopped there and concluded that engineering is a solved problem, with no tradeoffs involved. They're writing 2003-style Java in a language that's not particularly conducive to OOP (Javascript). Any time I solve something by writing a plain old function, my MRs are brigaded with kind suggestions that have an undertone of condescension. "Do you think this would be better solved by implementing the [Strategy pattern]?", "This hashmap seems a little out of place, have you considered adding some encapsulation here?" etc. The signal to noise ratio in the codebase is woeful and finding out how anything works requires a JetBrains IDE and spelunking gear. I don't mind that, I love brownfield projects. The problem is that we keep moving in this direction and that I'm being forced, or at least firmly suggested, to keep producing more "brown". The lead agrees that the codebase could be improved, but believes the churn (a couple of longstanding members with a revolving door of people) is on par with the rest of the industry and since the company is happy with us why fix what isn't broken. The team lead also don't code pretty much at all, so it's hard for them to perceive it as a priority. And the company is happy with us because the specific work we're doing is incredibly valuable -- we could be doing half as good. and still blow every other team out of the water because of the intrinsic value of our work. As long as our production doesn't go down every other day, we're the starchildren :\
- v-erne 5y ago
  Is this overengineering attitude coming from those few longstanding members? Because if so, I don't see how You can convince them of the value of simplicity (and that any kind of abstraction have a cost) if they themselves does not see value in it. This intuition can only come from long exposition to consequences of adding to much of accidental complexity. And what is more by openly contradicting their intuitions You directly threaten their status in company (because Your solutions will be directly opposing their way of solving things). There is of course second possibility - are You sure that the problem is not You ? Are there other team members that also complain? OOP style of programming takes a lot of time to get used to, but sometimes it can work if programmers are familiar enough with it. The use of strategy pattern can be good if there is enough variability in parts of algorithm that is being implemented. Personally I hate this style but its because I lack imagination (which is necessary to select proper patterns and create proper abstractions). I can only create them as an afterthought (by extracting them from existing codebase). But I know that there are people that can do it up front and hit the right spot enough times (and refactor if not).