Iyfjky

Question

I appologize if the title is too idiomatic, but I don't know how to explain the case without it.

Short version(non-technical). I have a coworker who has for some reason or another not learned a necessary skill that equates to 5 minutes of skimming a manual or looking up a YouTube video. Really, it should have been a skill that he attained a year and a half ago.

Our manager, wants me to complete a project in a poorly thought out way, when the solution to the problem is for the coworker is to just learn a simple piece of software. The manager should know this, it has been explained to him in the past.

Longer version(technical).
I am a software developer and I came to my current job to help with infrastructure problems. I'm the first real developer the company has hired. The other developer learned under the previous IT directors, but hasn't really taken initiative in the 2 years he's been on the job(several years with the company).

We're trying to transition to using Git. I've been using it for 7 or so months, no problems. All that has to happen is for my coworker to download GIT, and read a tutorial I provided to the team half a year ago. He hasn't done it.

Now, my boss, who isn't a developer, and maybe not all that technical, wants to institute git in an extremely convoluted way. He knows that my coworker doesn't know it, and it has been explained several times that all we need is for him to start using it.

Questions

How do I explain the situation(again) to the manager without causing waves?

How do I get the optimum result without drawing attention to my manager's failure to act

How do I keep my coworker out of trouble(he leaves and company goes down the tubes)?

I literally don't know how to phrase things to my manager. He's condescending and patronizing as it is. The entire situation seems like a lose-lose to me.

What do you personally lose if the manager proceeds with implementing Git in their convoluted way, encountering your colleague's shortcomings along the way? Seems to me you should just stand back and let them get on with it, and then possibly fail. The manager and possibly the company might "lose" but you would not. If you don't stand to gain anything by taking this responsibility and then, probably, failing then why get involved? — May 22 '15 at 9:32
"5 minutes of skimming a manual or looking up a YouTube video" - you're dangerously trivialising Git for a newcomer, particularly if he's well set in patterns of work that are appropriate for other systems (eg. SVN). In a company/team as small as yours, superficial knowledge may be more dangerous than none. — May 22 '15 at 9:57
Sounds to me like you are the one making this a lose-lose. Your manager is taking action. You just just don't like the way he plans to institute GIT. — May 22 '15 at 10:35
" I'm the first real developer the company has hired." - Then you know how important it is to cross-train. Some people, including myself, get a little confused when hooking everything up in a project. Some Architecture folks helped walk everyone through Subversion and TeamCity, specifically for their projects. Why can't you take the 10 minutes to help your teammate? — May 22 '15 at 12:25

Mark C. 8861819 · Accepted Answer · 2015-05-22 12:39:00Z

I see a couple of areas for "improvement" here.

I'm the first real developer the company has hired.

So you've identified a gap in some domain knowledge/areas. That's good; that means you know you need to work more closely and be the leader that the team needs to succeed. That encompasses getting everyone up to speed and getting necessary things, like a source control, in place early.

We're trying to transition to using Git. I've been using it for 7 or so months, no problems

"You" using it, doesn't constitute the "Team" using it. Git is a tool, much like many things in Software Development. If you know it, it only helps you, and if you really know it well, then why haven't you cross-trained anyone else on it? If it's that easy and seamless, you should be able to knock it out in 5 minutes. Explain it's usefulness, maybe show this person how many people utilize it.

"Here's how you hook it up to our project. Here's how you push/pull down/commit every so often. Here's how you resolve conflicts. This is going to help us both collaborate and be effectively developing in unison on this project."

As for implementing Git, I would take a very basic approach:

The problem we're trying to solve is X. The way that we solve X is by using a source control/repository and that will allow Person A and myself to work together and share the same files, without stepping on each others toes. If we don't use Git - it opens the door to all kinds of issues, etc.

I think that this could be handled without getting your manager involved. If you know how to use Git, and you are inline with the best practices, put a small powerpoint or something together and document the process and why it's useful. Deliver a step-by-step guide, or something, that will let people put their trust in you and show them that you know what you're talking about. Use screen shots, Git analytics, whatever you have to. Just reconcile this with humility. If your boss is condescending - that's their problem. Not yours. You don't have to live like that - just be your best and do the best job you can do.

"Git" is a tool that helps groups of people coordinating changes. One person using it isn't very helpful at all (it helps some, but doesn't solve important problems). It must be used by everyone or it becomes pointless for a group to use. — May 22 '15 at 12:42
@gnasher729 Correct. It is essentially the same thing as Subversion, which is what I use. Did you see room for improvement in my answer somewhere? Feel free to edit. — May 22 '15 at 12:43
@Jimmy, while I'm no expert at learning git(we should have been learning it at the same time), I have written tutorials, pulled him aside and shown him how it works, different software, etc. I can only send so many *"Can you install this piece of software/run this command and come by my desk with your laptop when you have a free minute..." type e-mails or drop-ins without it being harassment. He's a fair bit older than me, which doesn't help me claim his time. I'm think I'm just going to have sit at his desk and not leave until he actually installs and clones everything. — May 24 '15 at 5:58
@nobrandheroes Ã¢Â€Â” Maybe you need to plan 2 hours, not "a free minute". — Jun 20 '15 at 16:10

Elysian Fieldsâ™¦ 96.8k46292449 · Answer 2 · 2015-05-22 13:42:27Z

The better perspective....

I'd worry about throwing yourself under the bus.

Imagine this conversation:

"Hey boss, why are you implementing the process with Git the way you
are?"

"Well your coworker won't use Git."

"I know! He won't read the tutorial I gave him six months ago. It's so simple!"

"You have known the solution to this problem for six months and haven't explained it to him? Or helped him learn it?

"Well I sent an email and he should read it and become an expert like me!"

"You are the subject matter expert and the coworker doesn't know this technology. Why didn't you take 30 minutes or an hour and explain it to him in detail?"

"... I don't have a good answer to that at all."

Specific questions

How do I explain the situation(again) to the manager without causing waves?

Until you have spent considerable time explaining Git to your coworker (perhaps include your boss in these conversations) you are going to cause the above.

Setup a 30-60 minute meeting where you present the benefits of version control. For the first part do NOT TALK ABOUT GIT AT ALL. Seriously aim for 60 minutes. Act as if your coworker and manager have no idea about VCS at all.

After this, present Git and explain how it resolves current issues you have

Then present how you think the workflow for Git should work

Walk through several examples that you and they will actually have.

How do I get the optimum result without drawing attention to my manager's failure to act

See the hypothetical conversation. If I was your manager, I'd probably be annoyed that our developer can't seem to figure out a basic solution which works for a small team which is a solved problem in software development.

You can't just stick your head in the ground and get defensive and blame your coworkers. Maybe git is too complicated for your team. If that's the case, it's not your manager's fault - it's your fault for not suggesting something more simple (perhaps SVN - it's far easier conceptually to understand than git/mercurial).

You have to work with the tools and people you get to work with. Sometimes in business you can't have optimal solutions because of [x, y, z] factors.

An inefficient working process is better than a perfect efficient process which is not implemented or followed.

How do I keep my coworker out of trouble(he leaves and company goes down the tubes)?

You will take the responsibility for something not working. You are the expert here and if the system fails who will be responsible? You will. Not your coworker, but you, the subject matter expert.

He's condescending and patronizing as it is

I would take time to consider whether your manager is actually condescending or simply frustrated that a "simple" issue has resulted in so much wasted time.

Most managers are annoyed when they have to make decisions and create processes that their team are experts on because of that team's indecision for HALF A YEAR over.

Git is still confusing to me sometimes and I have been using it for a few years. Some people learn different ways I found the standard write ups for GIT worse than useless. But I found a few that walked me through and explained in a way that worked better for me. A meeting where you demonstrate use may be the kickstart to help the developer get a start. — May 22 '15 at 20:04
Git can be confusing. But we arent taking about complex workflows. At this point it is just pull, push, and clone. I've done manual tutorials with him as well. — May 23 '15 at 18:11
@nobrand you realize to push you need to understand the way git handles commits right? — May 24 '15 at 3:05
@enderland What do you mean the way git handles commits? Maybe I'm missing something specific to git? — May 24 '15 at 5:34
@enderland. Just rereading your main post, because you make good points, however, I think because maybe I wasn't clear enough, that I've caused you to make assumptions. Git and our implementation is a mandate from our boss, we received it at the same time, several months ago, and that's when I learned it, and he didn't. All our projects are git repos, and I've made multiple in person attempts to guide him through it, but I've been unable to get him to even install it. Our boss is well aware of where we are stuck in the process. I'm not blaming anyone, but I concerned how to present it as such. — May 24 '15 at 5:49

ColleenV 2,753928 · Answer 3 · 2015-05-22 12:08:01Z

You need to decide if you're going to be part of the problem, or part of the solution. If it really is as simple as you think it is for your coworker to get up to speed on Git, do you know why he hasn't done such a simple thing? If he is as important to the company as you've stated (he leaves and company goes down the tubes), and the manager knows your coworker doesn't want to learn to use Git, this convoluted way of implementing it may be the only compromise the manager can come up with.

I would attack it as if I were debugging a piece of code. First understand why things aren't working right, then figure out the appropriate solution. Right now it seems like you've decided the root problem is that your coworker is lazy, but that's not a problem you can solve. I think if you dig a little deeper, you might be able to find something you can do to make the situation better without throwing your coworker under the bus or telling your manager that you think his course of action is dumb.

Talk to your coworker and find out what the real issue is there. Some folks have a different learning style than others. I learn best with self-directed reading, but some folks learn best by having someone walk them through it. If you showed him the basic steps to get his code into Git, make a change, and then check it in, and then let him know if he had a question about how to do something you would be available to answer it, he would feel more comfortable transitioning. I think your attitude that learning Git is a trivial amount of effort is a big part of the problem here. You're the local expert, but if he asks you for help, you're going to make him feel dumb because he can't just read a tutorial and figure it out.

Very few people do things (or don't do things) without some underlying reason or motivation, and usually the obvious reason isn't the real reason. Avoiding change is not that uncommon - changing how you do something takes a lot of effort and has the risk that you'll make mistakes and look stupid while you're learning the new system. So, your coworker isn't lazy, he just doesn't like feeling incompetent. How would you feel if someone handed you a set of bagpipes, some sheet music, and pointed you at a YouTube video after telling you how easy bagpipes are to play? It might be easy for a trained musician to figure out but maybe not so much for a developer.

It's possible that if you just helped your coworker learn Git so they had more confidence in their ability to use it, you would not only solve the problem, but also end up looking pretty good to your manager, having a better working relationship with your coworker, and not have to deal with some convoluted implementation of Git.

I also am not good at picking things up myself. It is painful to me to try and navigate how-to material without someone to help. It really sets my teeth on edge when people tell me "just look at this video and figure it out -- it's easy!". For me it is not easy. If the coworker has problems like mine, what would help is an official "get acquainted with Git" session lasting maybe an hour or so. If you can get your manager to show up, it might help with the implementation issue. — May 22 '15 at 17:59
@Francine Ã¢Â€Â” Sure. A "get acquainted with Git" session is necessary, for the whole team. People who know Git already may be used to very different processes. For version control, one process has to be defined and shared in the team. A tool without the process is nothing. — Jun 20 '15 at 16:38
Maybe he fears to make make something that overwrites current code in "central?" repository (assumed workflow), and also when he is working with something he doesnt know how to fix the merging, how to find the correct code to merge with if he worked on something earlier, how not to lose the work he did on something else, while he turns to work on something together with you or other coworkers. Merging conflicts can be hell and you can feel like an idiot using half a day to just scour around the VCS tool to try and get code together that already works, in the beginning VCS was a huge timewaster — Apr 14 '17 at 11:09

Mark C. 8861819 · Accepted Answer · 2015-05-22 12:39:00Z

I see a couple of areas for "improvement" here.

I'm the first real developer the company has hired.

So you've identified a gap in some domain knowledge/areas. That's good; that means you know you need to work more closely and be the leader that the team needs to succeed. That encompasses getting everyone up to speed and getting necessary things, like a source control, in place early.

We're trying to transition to using Git. I've been using it for 7 or so months, no problems

"You" using it, doesn't constitute the "Team" using it. Git is a tool, much like many things in Software Development. If you know it, it only helps you, and if you really know it well, then why haven't you cross-trained anyone else on it? If it's that easy and seamless, you should be able to knock it out in 5 minutes. Explain it's usefulness, maybe show this person how many people utilize it.

"Here's how you hook it up to our project. Here's how you push/pull down/commit every so often. Here's how you resolve conflicts. This is going to help us both collaborate and be effectively developing in unison on this project."

As for implementing Git, I would take a very basic approach:

The problem we're trying to solve is X. The way that we solve X is by using a source control/repository and that will allow Person A and myself to work together and share the same files, without stepping on each others toes. If we don't use Git - it opens the door to all kinds of issues, etc.

I think that this could be handled without getting your manager involved. If you know how to use Git, and you are inline with the best practices, put a small powerpoint or something together and document the process and why it's useful. Deliver a step-by-step guide, or something, that will let people put their trust in you and show them that you know what you're talking about. Use screen shots, Git analytics, whatever you have to. Just reconcile this with humility. If your boss is condescending - that's their problem. Not yours. You don't have to live like that - just be your best and do the best job you can do.

"Git" is a tool that helps groups of people coordinating changes. One person using it isn't very helpful at all (it helps some, but doesn't solve important problems). It must be used by everyone or it becomes pointless for a group to use. — May 22 '15 at 12:42
@gnasher729 Correct. It is essentially the same thing as Subversion, which is what I use. Did you see room for improvement in my answer somewhere? Feel free to edit. — May 22 '15 at 12:43
@Jimmy, while I'm no expert at learning git(we should have been learning it at the same time), I have written tutorials, pulled him aside and shown him how it works, different software, etc. I can only send so many *"Can you install this piece of software/run this command and come by my desk with your laptop when you have a free minute..." type e-mails or drop-ins without it being harassment. He's a fair bit older than me, which doesn't help me claim his time. I'm think I'm just going to have sit at his desk and not leave until he actually installs and clones everything. — May 24 '15 at 5:58
@nobrandheroes Ã¢Â€Â” Maybe you need to plan 2 hours, not "a free minute". — Jun 20 '15 at 16:10

Elysian Fieldsâ™¦ 96.8k46292449 · Answer 5 · 2015-05-22 13:42:27Z

The better perspective....

I'd worry about throwing yourself under the bus.

Imagine this conversation:

"Hey boss, why are you implementing the process with Git the way you
are?"

"Well your coworker won't use Git."

"I know! He won't read the tutorial I gave him six months ago. It's so simple!"

"You have known the solution to this problem for six months and haven't explained it to him? Or helped him learn it?

"Well I sent an email and he should read it and become an expert like me!"

"You are the subject matter expert and the coworker doesn't know this technology. Why didn't you take 30 minutes or an hour and explain it to him in detail?"

"... I don't have a good answer to that at all."

Specific questions

How do I explain the situation(again) to the manager without causing waves?

Until you have spent considerable time explaining Git to your coworker (perhaps include your boss in these conversations) you are going to cause the above.

Setup a 30-60 minute meeting where you present the benefits of version control. For the first part do NOT TALK ABOUT GIT AT ALL. Seriously aim for 60 minutes. Act as if your coworker and manager have no idea about VCS at all.

After this, present Git and explain how it resolves current issues you have

Then present how you think the workflow for Git should work

Walk through several examples that you and they will actually have.

How do I get the optimum result without drawing attention to my manager's failure to act

See the hypothetical conversation. If I was your manager, I'd probably be annoyed that our developer can't seem to figure out a basic solution which works for a small team which is a solved problem in software development.

You can't just stick your head in the ground and get defensive and blame your coworkers. Maybe git is too complicated for your team. If that's the case, it's not your manager's fault - it's your fault for not suggesting something more simple (perhaps SVN - it's far easier conceptually to understand than git/mercurial).

You have to work with the tools and people you get to work with. Sometimes in business you can't have optimal solutions because of [x, y, z] factors.

An inefficient working process is better than a perfect efficient process which is not implemented or followed.

How do I keep my coworker out of trouble(he leaves and company goes down the tubes)?

You will take the responsibility for something not working. You are the expert here and if the system fails who will be responsible? You will. Not your coworker, but you, the subject matter expert.

He's condescending and patronizing as it is

I would take time to consider whether your manager is actually condescending or simply frustrated that a "simple" issue has resulted in so much wasted time.

Most managers are annoyed when they have to make decisions and create processes that their team are experts on because of that team's indecision for HALF A YEAR over.

Git is still confusing to me sometimes and I have been using it for a few years. Some people learn different ways I found the standard write ups for GIT worse than useless. But I found a few that walked me through and explained in a way that worked better for me. A meeting where you demonstrate use may be the kickstart to help the developer get a start. — May 22 '15 at 20:04
Git can be confusing. But we arent taking about complex workflows. At this point it is just pull, push, and clone. I've done manual tutorials with him as well. — May 23 '15 at 18:11
@nobrand you realize to push you need to understand the way git handles commits right? — May 24 '15 at 3:05
@enderland What do you mean the way git handles commits? Maybe I'm missing something specific to git? — May 24 '15 at 5:34
@enderland. Just rereading your main post, because you make good points, however, I think because maybe I wasn't clear enough, that I've caused you to make assumptions. Git and our implementation is a mandate from our boss, we received it at the same time, several months ago, and that's when I learned it, and he didn't. All our projects are git repos, and I've made multiple in person attempts to guide him through it, but I've been unable to get him to even install it. Our boss is well aware of where we are stuck in the process. I'm not blaming anyone, but I concerned how to present it as such. — May 24 '15 at 5:49

ColleenV 2,753928 · Answer 6 · 2015-05-22 12:08:01Z

You need to decide if you're going to be part of the problem, or part of the solution. If it really is as simple as you think it is for your coworker to get up to speed on Git, do you know why he hasn't done such a simple thing? If he is as important to the company as you've stated (he leaves and company goes down the tubes), and the manager knows your coworker doesn't want to learn to use Git, this convoluted way of implementing it may be the only compromise the manager can come up with.

I would attack it as if I were debugging a piece of code. First understand why things aren't working right, then figure out the appropriate solution. Right now it seems like you've decided the root problem is that your coworker is lazy, but that's not a problem you can solve. I think if you dig a little deeper, you might be able to find something you can do to make the situation better without throwing your coworker under the bus or telling your manager that you think his course of action is dumb.

Talk to your coworker and find out what the real issue is there. Some folks have a different learning style than others. I learn best with self-directed reading, but some folks learn best by having someone walk them through it. If you showed him the basic steps to get his code into Git, make a change, and then check it in, and then let him know if he had a question about how to do something you would be available to answer it, he would feel more comfortable transitioning. I think your attitude that learning Git is a trivial amount of effort is a big part of the problem here. You're the local expert, but if he asks you for help, you're going to make him feel dumb because he can't just read a tutorial and figure it out.

Very few people do things (or don't do things) without some underlying reason or motivation, and usually the obvious reason isn't the real reason. Avoiding change is not that uncommon - changing how you do something takes a lot of effort and has the risk that you'll make mistakes and look stupid while you're learning the new system. So, your coworker isn't lazy, he just doesn't like feeling incompetent. How would you feel if someone handed you a set of bagpipes, some sheet music, and pointed you at a YouTube video after telling you how easy bagpipes are to play? It might be easy for a trained musician to figure out but maybe not so much for a developer.

It's possible that if you just helped your coworker learn Git so they had more confidence in their ability to use it, you would not only solve the problem, but also end up looking pretty good to your manager, having a better working relationship with your coworker, and not have to deal with some convoluted implementation of Git.

I also am not good at picking things up myself. It is painful to me to try and navigate how-to material without someone to help. It really sets my teeth on edge when people tell me "just look at this video and figure it out -- it's easy!". For me it is not easy. If the coworker has problems like mine, what would help is an official "get acquainted with Git" session lasting maybe an hour or so. If you can get your manager to show up, it might help with the implementation issue. — May 22 '15 at 17:59
@Francine Ã¢Â€Â” Sure. A "get acquainted with Git" session is necessary, for the whole team. People who know Git already may be used to very different processes. For version control, one process has to be defined and shared in the team. A tool without the process is nothing. — Jun 20 '15 at 16:38
Maybe he fears to make make something that overwrites current code in "central?" repository (assumed workflow), and also when he is working with something he doesnt know how to fix the merging, how to find the correct code to merge with if he worked on something earlier, how not to lose the work he did on something else, while he turns to work on something together with you or other coworkers. Merging conflicts can be hell and you can feel like an idiot using half a day to just scour around the VCS tool to try and get code together that already works, in the beginning VCS was a huge timewaster — Apr 14 '17 at 11:09

Search This Blog

Iyfjky

How to not throw a coworker under a bus?

3 Answers
3

The better perspective....

Specific questions

Your Answer

Post as a guest

3 Answers
3

3 Answers
3

The better perspective....

Specific questions

The better perspective....

Specific questions

The better perspective....

Specific questions

The better perspective....

Specific questions

Post as a guest

Comments

Post a Comment

Popular posts from this blog

What does second last employer means? [closed]

List of Gilmore Girls characters

Confectionery

Category

Random preview

How to not throw a coworker under a bus?

3 Answers 3

The better perspective....

Specific questions

Your Answer

Sign up or log in

Post as a guest

Post as a guest

3 Answers 3

3 Answers 3

The better perspective....

Specific questions

The better perspective....

Specific questions

The better perspective....

Specific questions

The better perspective....

Specific questions

Sign up or log in

Post as a guest

Post as a guest

Sign up or log in

Post as a guest

Sign up or log in

Post as a guest

Sign up or log in

Post as a guest

Comments

Post a Comment

Popular posts from this blog

What does second last employer means? [closed]

List of Gilmore Girls characters

Confectionery

3 Answers
3

3 Answers
3

3 Answers
3