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?
a) Extremely. b) About 30 seconds should suffice.
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony AntiTwitter: @DalekDave is now a follower!
-
a) Extremely. b) About 30 seconds should suffice.
"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?
You said that it's partially true that he can't test his code before submitting it. For some reason, this wasn't a big deal before, but now it is because the project is higher profile with more people working on it, probably with harder deadlines. If I understand the situation correctly, he needs to be available to help downstream developers debug his code when it doesn't work. The tricky part is that those developers can't interrupt him until they're reasonably sure that the problem lies with his code. It's no fun to be interrupted for this kind of thing, so it will encourage him to test his code to whatever extent possible. In parallel with this, it sounds like you need automated tests that he can run, and that the downstream developers will have to create those tests. I assume this because, otherwise, he could presumably run those tests himself, whether automated or not. This is not a question of tact but should be seen as a reasonable way to speed up development.
Robust Services Core | Software Techniques for Lemmings | Articles
-
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?
It depends if you want to be the next Lone Ranger. Remember, there can be only one.
-
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?
Following the Dilbert principle[^] you need to promote him to the technical lead of the project. That will keep him happy at the same time as not losing the knowledge of the current solution.
Wrong is evil and must be defeated. - Jeff Ello
-
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
