-3

This might be nothing to others, but personally, I need help.

I recently working with this coworker and they are the main reason I consider to quit my job. Boss tells me that they and my working "style" is quite different.

They were developing a CMS(Content Management System) before I was involved by their request to share the burden. It was built with Nuxt starting with a copy from another project. The first problem I noticed with this work was that despite it was using Nuxt(Vue.js), it was needlessly using jQuery(hide elements, add classes, and so on), which stressed me a bit(recently I easily get stressed). I told the coworker to avoid jQuery and they agreed. So far so good.

After I pushed some git commits, I got angry messages from the coworker. Even though I resolved those very simple conflicts before the push, somehow their files were full of conflicts caused by me. And they said that I didn't mention the push before I push. I eventually concurred about it. But it's weird that I should use Git like SVN. I also had my doubt that they also have faults. I saw 5~8 files were not git added from their computer, and they were developing on the master branch directly. I proposed that each of us should use our own branches to resolve this, which they initially disagreed with.

Recently, I got a mention from my boss that my coworker is worried about my part using Bootstrap-Vue. Their part was not using it and instead, most modules were handmade using global variables. And they said this difference might cause some "conflict" in the future, and proposing that we should unify our developing method. I agreed while I'm not sure what kind of conflict they were expecting. But I suspect that the coworker doesn't know how to use Bootstrap(other coworkers also suspect this) and might force me to do my work their way, which I hate.

It's not even been a month, but I keep getting some big and small frictions with this coworker ever since I start working on the CMS. I know that I'm being hasty, but I almost had it. I think it's time for me to quit my job for a few months after 6 years of work. But before I do that, I want to know how to resolve these frictions in the future if possible. It would be also great to find a solution to this current matter.

8
  • 3
    @JoeStrazzere the OP has been there 6 years, that interview was a while ago and the staff likely changed…
    – Solar Mike
    Aug 29, 2021 at 11:58
  • @SolarMike I initially thought so too, but now I think he said it for the next job interviews. Aug 29, 2021 at 12:00
  • @JoeStrazzere I added a new question to find a solution to the current issue. Sorry to add this late. Aug 29, 2021 at 12:07
  • "They were developing a CMS" They were developing a Compact Muon Solenoid? That's quite impressive.
    – Stef
    Aug 30, 2021 at 15:18
  • 1
    @Stef Hahaha, OK, I'll clarify. It's a Content Management System. Aug 31, 2021 at 1:45

3 Answers 3

9

Let's break this down from a different perspective.

The other developer was working on a project and requested help. You show up and start doing things differently. You then start complaining about how things are being done, don't follow their lead, and rather than being helpful, you are actually causing additional work.

I would highly suggest that to reduce the friction here that you take a step back and code things the way the other developer has set it up. If you have any questions, ask them. If you want to go a different direction, talk to them first. If you want to use toolkit A and they are using B then just use B. If they say no then it's a no.

A big challenge to development is when people don't follow standards that are set down. It doesn't matter if the standards aren't that great. What matters is that the project is consistent. In this situation you are the one not following the project standards.

There is always be a "better" way of doing things but that doesn't necessarily mean you should throw out what is currently being done.

4
  • 1
    Well said I agree totally in fact I would go a little further.
    – Brad
    Aug 31, 2021 at 8:06
  • I disagree with this to some extent. When some organisation don't even have some basic baseline about organizing their work properly, it is not a big challenge to overcome, it's shit to cope up with or run away. In industry there are standard way ot oraganize even some beginner team and use tools,.While I only have OP version, we can tell those people don't even understand what they're doing and refuse to even consider progress. So either OP cope up with it or he run away. Please don't call "challenge" what it is not. It is an insult to the developper that overcome real "challenge"
    – Walfrat
    Aug 31, 2021 at 8:21
  • 1
    @Walfrat: When a small team is actively working against each other then the project will fail. OTOH, if OP follows the other dev's directions then there exists at least some chance for success. It won't be the prettiest code, and it will likely need a fair bit of refactoring but at least they have a shot at release. When OP is later in charge of his own project then s/he can set the standards bar quite a bit higher.
    – NotMe
    Aug 31, 2021 at 23:47
  • "at least some chance for success" yeah and in case of failure who would be blame ? Of course "it depends" but i'd say that there are far more chance for the competent developer to be blamed instead of the others.
    – Walfrat
    Sep 1, 2021 at 6:59
4

I have a feeling this has nothing to do with Workplace but rather some Software architecture part of StackExchange. And your post makes me want to ask almost nothing but questions.

After I pushed some git commits, I got angry messages from the coworker. Even though I resolved those very simple conflicts before the push, somehow their files were full of conflicts caused by me.

Shouldn't Git stop and warn about that? How is that even possible?

And they said that I didn't mention the push before I push.

Ridiculous, that's 90s work methods.

I eventually concurred about it. But it's weird that I should use Git like SVN.

Why did you concur to that? How is it your job to fix his conflicts? How is it your duty to use Git like SVN?

I also had my doubt that they also have faults.

I never even saw your code and I also have serious doubts just from what I read from your post.

I saw 5~8 files were not git added from their computer, and they were developing on the master branch directly. I proposed that each of us should use our own branches to resolve this, which they initially disagreed with.

Again why did you accept that disagreement? You seem to just cave in to workflows that are both pointless and outdated. Git workflow doesn't require any of this. And working on the master branch with several people then complaining about other people giving you conflicts and blaming them screams ignorance about Git. If he doesn't add things to Git, and then gets conflicts, it's his fault entirely.

Recently, I got a mention from my boss that my coworker is worried about my part using Bootstrap-Vue. Their part was not using it and instead, most modules were handmade using global variables.

I have no opinion on the former (not a Vue expert, used Bootstrap once), but I really fail to understand why you would use handmade modules with global variables unless it's a company design. Your post is lacking crucial information, such as why do you use these homemade modules rather than a publicly available module.

And they said this difference might cause some "conflict" in the future, and proposing that we should unify our developing method. I agreed while I'm not sure what kind of conflict they were expecting.

Having homemade modules/frameworks and public ones will certainly bring design conflicts at some point, but the real question is why would your homemade ones work better and why should you use theirs instead of a tried and tested public one?

But I suspect that the coworker doesn't know how to use Bootstrap(other coworkers also suspect this) and might force me to do my work their way, which I hate.

Again, you're not saying half of what you should.

  1. Why do you use homemade modules/frameworks instead of public ones?

Saying "I hate his way" justifies nothing, please explain why he uses his own modules in the first place, and why it's better than bootstrap-vue. If it isn't, you should be arguing that his way is wrong, not caving in to it.

  1. Why do you accept conflictual statements from your coworker when he clearly does not use proper workflow?

Not using Git properly and then blaming you is complete incompetence shoved on your shoulders. That's not something you should let slide.

  1. Why do you cave in to him in these conflicts?

Why in the world do you "concur" with someone whom you know is not using Git properly, is not willing to do something as simple as branching, and blames you when he pushes only part of his work and then gets conflicts?

This is either a technical problem, in which case you are not at the right place, or a personality problem where you cave in for no reason at all to bad practices and irresponsible/incompetent behaviour.

2
  • 1. That's what I'm going to persuade. It's still ongoing. 2. There is a misunderstanding. I said "they initially disagreed with" git add, but they eventually agreed with it. I didn't agree to their term. 3. I agree it was illogical. I tried my best to persuade them, but they are so stubborn and I wanted to move on. So I thought sending them messages about my push from time to time was a small price to pay, which now I regret. And... I wasn't quite sure about the Git usage. Aug 30, 2021 at 1:17
  • 2
    @Asimpleuser it's a bit late for that, but rule of thumb: NEVER agree "temporarily" to something in the business world. Saying "yes" once means saying "yes" forever, because changing workflows in a company is something nobody wants to ever have to do. If you cave in to do absurd things, you'll do them forever.
    – Mahboi
    Sep 1, 2021 at 8:47
-1

The answer to the problem is right here

Stressed by a coworker who's generally against my working method


The team's/department/companies working method should be what is written here.

Normally as a new member of a team; be it writing software or climbing a mountain you should be the one to fit in. From your post regardless of what problems the project has, it is clear you at the moment are not the person who wishes to "fit in". This is no doubt causing more problems and thus not really helping with the burden.

As you are still a newbie after only 6 years, your leaving should be no great problem for the company, thus no loyalty issues need to arise. So the discission is yours. Although I doubt you are serious about leaving, as that is a personal decision that you need to make on your own. This seems to be more like just a moan, a chance to air your frustrations, as indicated from the detailed account. Either way, I wish you luck in the future.

0

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .