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?
-
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
-
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?
Its nonsense to say he cant test. Your project needs to create a test database to test against, and the Lone Ranger needs to be testing his new functionality against that. You could create a script to create an empty version of your live db and load test data into it. He needs to amend his connection string to test the app against that, or at the very least if its SQL paste his changes in SSMS (or whatever your RDBMS client tool is) and run it against the test db. In the long term you could aim to create a suite of automated unit tests which are run before a deployment to reduce risk further. If its government work, here in the UK we have to conform to certain standards part of which is having a test strategy and evidence testing has taken place (and not against live data). We are audited on compliance to this. If you have similar in your locale,you could be at risk of failing an audit and losing business.
-
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?
Having read the Habits of high performing teams post last week, maybe High Psychological Safety comes in here. Unclear of the organisation structure of this team, and maybe this will lean more toward a manager person to sort, but here goes: From their perspective they might be in a defensive position (dont have time to test) and they maybe worried that you lot will criticise how bad his code is. So, the first step is to have them understand that all of you are their to work. Yes your code is going to be different to what we might expect, but the reason we have been assigned to work with you is because what you have made so far is good for the company. You have done good, it needs to expand, yes somethings will change, but we are not here to murder you (i am a sarcastic person, remove the last part if this sarcasm doesn't work for you) Address all concerns as a team, do a meeting - I worry X will be Y. Others either agree or disagree, gets rid of the mental thoughts. Figure out what needs to be setup and what does not need for a team. Source control is always needed.
-
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?
If the management have basically ignored the project for "a couple of years now" then they have only themselves to blame, and should be thinking in terms of a recovery plan from their lack of support. It's not possible for a single person to be truly their own QA (etc), while still inside a big system (the management!). Someone needs to be the proper "support" person that helps the 'LR' victim identify and resolve the (administrative / management) technical debt, so as to back out those years of problems. Victim blaming, just because you / I / someone else would have had different problems, isn't a productive way out of this double blind. If the LR walks, will the project be cancelled, or will it be a death march? Is it better to 'promote' the LR to being lead advisor to relieve them from some of the historical hidden pressure? It's still a problem, in many ways, with your (company's) management. Did they know they'd let the project stall, why did the take on the new project without a review? It's not what's under the rock that's the problem, it's the rock on top!
-
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
Golden standard is git, which is a bit hard to understand without previous experience of source control and a bit too intricate to use, especially from command line. Also it's hard to see the benefit of git versus the still rampant zip file + changelog + diff when working alone or in pairs. Palce 3+ people on a complex project and the time investment in learning git pays, especially if aided by a good client (which is NOT the command line*). * Command line git is powerful and it does make sense but it's a 10.000 levers and push buttons tools, awesome for a full time integrator but time consuming and error prone for a developer whose main competences are code, design, architecture of the product. If it was not for a particular git client, I would never have been sold on git itself. SourceTree is free and has a terrific log analyzer but the UI to manage the repository sucks, the tool I use (not mentioning because it's free only for personal use) has a less than optimal log analyzer but a perfect UI to manage the repository.
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
-
"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, 2013I've got to go along with JSOP on this one. I've seen far too often where software gets thrown onto production when it could not possibly have been executed, and then it's a huge shitstorm to try to get the bug fixed. Of course, that normally involves hacking something together. There might be times when testing is missed (i.e., didn't think of case X), but to say "I'll test by putting something into production" is grounds for immediate termination. Well, I wish it was. But I work with morons.
-
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?
Do you not have a team/group meeting where you discuss: 1) Massive Backlog 2) Continuous Improvements (where this would fall) 3) Code Reviews 4) Branches and the main branch stability? Without clarity of purpose and buy in, I assume it isn't happening. And as professional developers we spend 10% of our time doing continuous improvement. An analogy to painting is cleaning up when you are done. If I hire a painter, I expect him to leave a finished product free of masking tape, and if he used my brushes, they are cleaned, but if he used his, I think I still paid him to clean them... I am 100% okay if he does that on the jobsite as long as he cleans up before he leaves... So, we allocate it. Otherwise the code just starts cracking under it's own weight. With multiple developers we assign one person to be responsible to make breakthroughs (like parsing all the SQL and bind variables, getting that added to the build process, and either refactoring the code, or the "fixed when touched" approach and verified in code review).
-
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 had a similar problem. My solution was to not come back to the office and find another job instead. A better solution would of course be to first talk to him about the subject, the same way you did in this forum post. If this doesn't help, ask your boss to mediate, that's his job. If this doesn't help either... leave the company.
-
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?
Show him a benefit to being in a team. My current role is more implement and support, with a little business analysis. Moving into a team where others could answer the call was great. They were tech competent and even if I wrote the code using Hungarian notation, they could walk thru it. If a spec was there in full geek, they could translate. Each of us has our alignment and strengths, and are available to the others. As we don't dev, we do not do builds and tests. But communication tools of some kind. Does he have domain knowledge that is useful to all? Does he know (and share) the dark corners that need work? Lead, help, or go away.
-
"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, 2013You assume that there are infact hard copy "rules" to follow in the first place.. Chances are if there is even a "lone ranger" situation at all, there are merely arbitrary best practices and no actual rules being enforced. I can see both sides to this quandry. I am neck deep in being the "lone ranger" in a project (now 8 years). I have found the opposite problem. It was deemed accepted and almost preferred that it be only a resource suck for a single team member up until recently. So much time spent and with new leadership, I have been in the old "what is it you do here" chair. That has been disheartening. Now suddenly there a bunch of new "rules", expectations, documentation, support demands, and a whole "be a team player" narrative placed on me. Lots of productivity crushing "process", but still no Tonto. The one person army for the project may or may not have been of their own doing and is more a failure of project/product management and process. They may have gotten into some bad habits and now have become accustomed to being in their own sandbox. I sense of ownership maybe. To suddenly have to let others in to that sandbox, especially in a critical manner, can be perceived as hostile. But again, thats on management.
