What do you do with a person like this?
-
Background: I have a colleague who has been the Lone Ranger in a project for a couple of years now but recently that project's problems has become a much higher priority (it's a system for the gov't and we've landed a significant new contract to expand this service to a larger number of gov't agencies, ergo the higher visibility). A small group of us have been moved onto the project to help get everything up to snuff. He has long complained that he doesn't have the ability to test code before pushing it to develop, which is partially true. However, there is some basic testing he COULD do but apparently doesn't since I can't get my code tested for finding bugs in stuff he's pushed to develop. Things like testing the SQL to make sure it doesn't throw syntax errors or "Inconsistent types" (comparing a boolean to a string) Since he's been the Lone Ranger in this code for so long, he's a little prickly about us coming into his domain. How tactful should I be and how long should I remain tactful?
I think you are just venting, which is fine. Just don't let your venting turn into negative energy. If it does, that would not bode well for you, and people will start asking what to do with you. Something to think about perhaps.
-
Just found out he fixed the error 8 days ago but, should I have to keep rebasing my branch over and over just to get a clean run?
Presumably you took the branch from the main sequence, not a copy of his "private working code"? Someone needs to give him a lesson on only committing working code ... preferably with a cluebat.
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony AntiTwitter: @DalekDave is now a follower!
-
I think you are just venting, which is fine. Just don't let your venting turn into negative energy. If it does, that would not bode well for you, and people will start asking what to do with you. Something to think about perhaps.
Urgh, too true this... You point out problems with something, and you are "the negative guy" all of a sudden. People are just lazy and can't be bothered to deal with problems, they prefer to just pretend they don't exist until the have to. I guess the term is "reactive management" :sigh:
-
Background: I have a colleague who has been the Lone Ranger in a project for a couple of years now but recently that project's problems has become a much higher priority (it's a system for the gov't and we've landed a significant new contract to expand this service to a larger number of gov't agencies, ergo the higher visibility). A small group of us have been moved onto the project to help get everything up to snuff. He has long complained that he doesn't have the ability to test code before pushing it to develop, which is partially true. However, there is some basic testing he COULD do but apparently doesn't since I can't get my code tested for finding bugs in stuff he's pushed to develop. Things like testing the SQL to make sure it doesn't throw syntax errors or "Inconsistent types" (comparing a boolean to a string) Since he's been the Lone Ranger in this code for so long, he's a little prickly about us coming into his domain. How tactful should I be and how long should I remain tactful?
Give him this book: resources-on-software-architecture~your-code-as-a-crime-scene[^] :-\
-
Background: I have a colleague who has been the Lone Ranger in a project for a couple of years now but recently that project's problems has become a much higher priority (it's a system for the gov't and we've landed a significant new contract to expand this service to a larger number of gov't agencies, ergo the higher visibility). A small group of us have been moved onto the project to help get everything up to snuff. He has long complained that he doesn't have the ability to test code before pushing it to develop, which is partially true. However, there is some basic testing he COULD do but apparently doesn't since I can't get my code tested for finding bugs in stuff he's pushed to develop. Things like testing the SQL to make sure it doesn't throw syntax errors or "Inconsistent types" (comparing a boolean to a string) Since he's been the Lone Ranger in this code for so long, he's a little prickly about us coming into his domain. How tactful should I be and how long should I remain tactful?
MarkTJohnson wrote:
A small group of us have been moved onto the project ...
Presumably by a manager; he or she is the person that needs to resolve this issue. And Lone Rangers need to learn that the world will not stop turning if they fall under a bus.
-
Background: I have a colleague who has been the Lone Ranger in a project for a couple of years now but recently that project's problems has become a much higher priority (it's a system for the gov't and we've landed a significant new contract to expand this service to a larger number of gov't agencies, ergo the higher visibility). A small group of us have been moved onto the project to help get everything up to snuff. He has long complained that he doesn't have the ability to test code before pushing it to develop, which is partially true. However, there is some basic testing he COULD do but apparently doesn't since I can't get my code tested for finding bugs in stuff he's pushed to develop. Things like testing the SQL to make sure it doesn't throw syntax errors or "Inconsistent types" (comparing a boolean to a string) Since he's been the Lone Ranger in this code for so long, he's a little prickly about us coming into his domain. How tactful should I be and how long should I remain tactful?
"can't test"... I call bullshit. He can write an app that can exercise ANY stored proc in a sql server database. I know, because I've done it. There is absolutely NO EXCUSE for pushing (SQL) code out to production that hasn't be tested. NONE. Point of fact - using SSMS to write stored procs (or even just queries) is absolutely the best way to flesh out problems. SSMS won't even let you create a stored proc that isn't at least syntactically correct. We have several dozen scripts that we use to run complex stored procs with a fixed set of params, and we know exactly what we want in the result set. If your "lone ranger" programmer doesn't is more interested in his own agenda than actually being part of a team, the best way to handle it is to fire him. Right now. The sooner he's not a problem, the better things will get for the rest oft he team. I work with eight devs and four DBAs (also in a DoD environment), and EVERYBODY follows the rules regarding testing before deployment.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013 -
Background: I have a colleague who has been the Lone Ranger in a project for a couple of years now but recently that project's problems has become a much higher priority (it's a system for the gov't and we've landed a significant new contract to expand this service to a larger number of gov't agencies, ergo the higher visibility). A small group of us have been moved onto the project to help get everything up to snuff. He has long complained that he doesn't have the ability to test code before pushing it to develop, which is partially true. However, there is some basic testing he COULD do but apparently doesn't since I can't get my code tested for finding bugs in stuff he's pushed to develop. Things like testing the SQL to make sure it doesn't throw syntax errors or "Inconsistent types" (comparing a boolean to a string) Since he's been the Lone Ranger in this code for so long, he's a little prickly about us coming into his domain. How tactful should I be and how long should I remain tactful?
1. escalate the problem to management & audit as a risk issue, ie $$$ - they understand that 2. have management appoint a team leader who's word is absolute, implement DevOps - it's a whole team mindset, not a 'I' mindset - if he's not willing, point to the door, ta ta, you dont need him 3. implement pair programming with the person, but, 1 writes code, the other writes the tests for it - have him start on the tests 4. Implement the simplest DevOps you can start with - Jenkins is free, use Gauge or Gherkin/Cucumber etc, but start with something if he resists, point towards the door. If management dont want you to do it, get a Consultant as the fall guy to implement DevOps
-
Background: I have a colleague who has been the Lone Ranger in a project for a couple of years now but recently that project's problems has become a much higher priority (it's a system for the gov't and we've landed a significant new contract to expand this service to a larger number of gov't agencies, ergo the higher visibility). A small group of us have been moved onto the project to help get everything up to snuff. He has long complained that he doesn't have the ability to test code before pushing it to develop, which is partially true. However, there is some basic testing he COULD do but apparently doesn't since I can't get my code tested for finding bugs in stuff he's pushed to develop. Things like testing the SQL to make sure it doesn't throw syntax errors or "Inconsistent types" (comparing a boolean to a string) Since he's been the Lone Ranger in this code for so long, he's a little prickly about us coming into his domain. How tactful should I be and how long should I remain tactful?
Write a one-page document on what you feel are the most important deficiencies of that code. (Not more than a page, otherwise, it is unlikely to be read). Use third person as in "This code is doing things like this, preferably it should be like that", and so on. Send it to your manager, with Lone Ranger in cc. Let not your manager say "Why did you not point this out earlier".
-
"can't test"... I call bullshit. He can write an app that can exercise ANY stored proc in a sql server database. I know, because I've done it. There is absolutely NO EXCUSE for pushing (SQL) code out to production that hasn't be tested. NONE. Point of fact - using SSMS to write stored procs (or even just queries) is absolutely the best way to flesh out problems. SSMS won't even let you create a stored proc that isn't at least syntactically correct. We have several dozen scripts that we use to run complex stored procs with a fixed set of params, and we know exactly what we want in the result set. If your "lone ranger" programmer doesn't is more interested in his own agenda than actually being part of a team, the best way to handle it is to fire him. Right now. The sooner he's not a problem, the better things will get for the rest oft he team. I work with eight devs and four DBAs (also in a DoD environment), and EVERYBODY follows the rules regarding testing before deployment.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013every single line of code we write, c#, sql, etc. is peer reviewed during a pull request and also gets tested in our QA environment. Nothing ever gets deployed to Prod without being tested by our QA team first. If something makes it to Prod and is buggy, the QA team takes the hit first, then the dev.
#realJSOP wrote:
I call bullshit.
:thumbsup:
-
Background: I have a colleague who has been the Lone Ranger in a project for a couple of years now but recently that project's problems has become a much higher priority (it's a system for the gov't and we've landed a significant new contract to expand this service to a larger number of gov't agencies, ergo the higher visibility). A small group of us have been moved onto the project to help get everything up to snuff. He has long complained that he doesn't have the ability to test code before pushing it to develop, which is partially true. However, there is some basic testing he COULD do but apparently doesn't since I can't get my code tested for finding bugs in stuff he's pushed to develop. Things like testing the SQL to make sure it doesn't throw syntax errors or "Inconsistent types" (comparing a boolean to a string) Since he's been the Lone Ranger in this code for so long, he's a little prickly about us coming into his domain. How tactful should I be and how long should I remain tactful?
-
Background: I have a colleague who has been the Lone Ranger in a project for a couple of years now but recently that project's problems has become a much higher priority (it's a system for the gov't and we've landed a significant new contract to expand this service to a larger number of gov't agencies, ergo the higher visibility). A small group of us have been moved onto the project to help get everything up to snuff. He has long complained that he doesn't have the ability to test code before pushing it to develop, which is partially true. However, there is some basic testing he COULD do but apparently doesn't since I can't get my code tested for finding bugs in stuff he's pushed to develop. Things like testing the SQL to make sure it doesn't throw syntax errors or "Inconsistent types" (comparing a boolean to a string) Since he's been the Lone Ranger in this code for so long, he's a little prickly about us coming into his domain. How tactful should I be and how long should I remain tactful?
MarkTJohnson wrote:
He has long complained that he doesn't have the ability to test code before pushing it to develop
Do you mean production? I ask because most of the answers seem to be interpreting what you are saying as pushing to production without testing.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
-
Background: I have a colleague who has been the Lone Ranger in a project for a couple of years now but recently that project's problems has become a much higher priority (it's a system for the gov't and we've landed a significant new contract to expand this service to a larger number of gov't agencies, ergo the higher visibility). A small group of us have been moved onto the project to help get everything up to snuff. He has long complained that he doesn't have the ability to test code before pushing it to develop, which is partially true. However, there is some basic testing he COULD do but apparently doesn't since I can't get my code tested for finding bugs in stuff he's pushed to develop. Things like testing the SQL to make sure it doesn't throw syntax errors or "Inconsistent types" (comparing a boolean to a string) Since he's been the Lone Ranger in this code for so long, he's a little prickly about us coming into his domain. How tactful should I be and how long should I remain tactful?
Tactful for a month, hard later. I've been The Lone Ranger Under Pressure (out of necessity) more than once and I didn't acquire the capabilities of working in team, also to provide clean releases - after all nobody will test it or maintain it therefore I could build now and fix twhen. I was also cajoled in working with a Lone Ranger Because Probably Autistic who did not comment, design, document nor used any form of source control. Since he was the Depositary of All the Knowledge and was also the Holy Cow of the customer company, I lost, in three months straight I resigned. Granted, I did not resign because of him but his crappy way of working made what was a daunting proposition simply impossible.
GCS d--(d+) s-/++ a C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
-
I think you are just venting, which is fine. Just don't let your venting turn into negative energy. If it does, that would not bode well for you, and people will start asking what to do with you. Something to think about perhaps.
mainly venting, but still.
-
MarkTJohnson wrote:
He has long complained that he doesn't have the ability to test code before pushing it to develop
Do you mean production? I ask because most of the answers seem to be interpreting what you are saying as pushing to production without testing.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
No, I mean the develop branch of git that I'm supposed to branch off of. Code compiled but when I ran it kaBoom.
-
No, I mean the develop branch of git that I'm supposed to branch off of. Code compiled but when I ran it kaBoom.
That's could also be because he forgot to add some files to the branch - the usual indication of this is it runs fine on his local machine but when you switch to the branch you hit issues. If he can run everything fine when switched to that branch, the chances are he has forgotten to commit some file(s) to the branch.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
-
Tactful for a month, hard later. I've been The Lone Ranger Under Pressure (out of necessity) more than once and I didn't acquire the capabilities of working in team, also to provide clean releases - after all nobody will test it or maintain it therefore I could build now and fix twhen. I was also cajoled in working with a Lone Ranger Because Probably Autistic who did not comment, design, document nor used any form of source control. Since he was the Depositary of All the Knowledge and was also the Holy Cow of the customer company, I lost, in three months straight I resigned. Granted, I did not resign because of him but his crappy way of working made what was a daunting proposition simply impossible.
GCS d--(d+) s-/++ a C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
Not using source control even when you are working on your own is asking for trouble. I still find it hard to believe that some devs don't use some kind of source control - heck back in 1991 when I cut my teeth coding as a COBOL programmer, we used source control.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
-
Background: I have a colleague who has been the Lone Ranger in a project for a couple of years now but recently that project's problems has become a much higher priority (it's a system for the gov't and we've landed a significant new contract to expand this service to a larger number of gov't agencies, ergo the higher visibility). A small group of us have been moved onto the project to help get everything up to snuff. He has long complained that he doesn't have the ability to test code before pushing it to develop, which is partially true. However, there is some basic testing he COULD do but apparently doesn't since I can't get my code tested for finding bugs in stuff he's pushed to develop. Things like testing the SQL to make sure it doesn't throw syntax errors or "Inconsistent types" (comparing a boolean to a string) Since he's been the Lone Ranger in this code for so long, he's a little prickly about us coming into his domain. How tactful should I be and how long should I remain tactful?
How to Deal with Difficult People on Software Projects[^] Sounds like you've got a case of The Hostage Taker[^]. Very dangerous, but easy to fix. According to that website anyway :D
Best, Sander sanderrossel.com Migrating Applications to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript Object-Oriented Programming in C# Succinctly
-
That's could also be because he forgot to add some files to the branch - the usual indication of this is it runs fine on his local machine but when you switch to the branch you hit issues. If he can run everything fine when switched to that branch, the chances are he has forgotten to commit some file(s) to the branch.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
True, but so far it has been screwed up SQL command strings.
-
Presumably you took the branch from the main sequence, not a copy of his "private working code"? Someone needs to give him a lesson on only committing working code ... preferably with a cluebat.
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony AntiTwitter: @DalekDave is now a follower!
-
Background: I have a colleague who has been the Lone Ranger in a project for a couple of years now but recently that project's problems has become a much higher priority (it's a system for the gov't and we've landed a significant new contract to expand this service to a larger number of gov't agencies, ergo the higher visibility). A small group of us have been moved onto the project to help get everything up to snuff. He has long complained that he doesn't have the ability to test code before pushing it to develop, which is partially true. However, there is some basic testing he COULD do but apparently doesn't since I can't get my code tested for finding bugs in stuff he's pushed to develop. Things like testing the SQL to make sure it doesn't throw syntax errors or "Inconsistent types" (comparing a boolean to a string) Since he's been the Lone Ranger in this code for so long, he's a little prickly about us coming into his domain. How tactful should I be and how long should I remain tactful?
As a former "Lone Ranger" I found that source control was the issue when bringing in a wider team. We have been in the position where I would merge my changes back to the base line, he would get the latest version from the base and it would fail to even compile with hundreds of errors. If we then deleted his version and then copied directly from my source it worked perfectly. Be very sure where the problem lies before putting on the hob nail boots.
Never underestimate the power of human stupidity - RAH I'm old. I know stuff - JSOP
