|
|
hmmm, not to sure what to think, a bit mean
it's a bit on the nose, and a bit on the cheek, and a bit on the chin, and now a bit ...
if you can't laugh at yourself ... then laugh at someone else??
(I mean we can't all be Germans can we?)
pestilence [ pes-tl-uh ns ] noun
1. a deadly or virulent epidemic disease. especially bubonic plague.
2. something that is considered harmful, destructive, or evil.
Synonyms: pest, plague, CCP
|
|
|
|
|
Schadenfreude is one of my favorite words.
|
|
|
|
|
Is it also true that a person who's constipated really couldn't give a sh*t?
Ravings en masse^ |
---|
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein | "If you are searching for perfection in others, then you seek disappointment. If you seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
Or don't take the medication at all, and become the bartender at James Bonds favorite pub.
"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment
"Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst
"I don't drink any more... then again, I don't drink any less." - Mike Mullikins uncle
|
|
|
|
|
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!
|
|
|
|
|
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!
|
|
|
|
|
Harsh but fair
"We can't stop here - this is bat country" - Hunter S Thompson - RIP
|
|
|
|
|
clue bat - I like it.
Charlie Gilley
<italic>Stuck in a dysfunctional matrix from which I must escape...
"Where liberty dwells, there is my country." B. Franklin, 1783
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
|
|
|
|
|
It depends if you want to be the next Lone Ranger. Remember, there can be only one.
|
|
|
|
|
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.
|
|
|
|
|
Good advice. 🙂
I second the idea that new developers should help with dedicating some of their time to implementing unit tests. Regardless of how difficult the testing circumstances are, that should still be a realistic option.
|
|
|
|
|
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.
|
|
|
|
|
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"
|
|
|
|
|
mainly venting, but still.
|
|
|
|
|
|
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.
|
|
|
|
|
"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
|
|
|
|
|
every 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.
|
|
|
|
|
I'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.
|
|
|
|
|
You 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.
|
|
|
|
|
I've been a "lone ranger" as well, and even then, I had rules. Since I was "just the programmer", I insisted that someone else look at the app in question before I submitted it for deployment.
When I joined the my current team, they had rules in place, and if I want to work here, I have to follow those rules. If a given programmer isn't mature enough to adapt to changes to his environment, he can damn well go find another job, because "lone rangers" don't do anything but hurt the software and the company's reputation when crap slips into production due to a lack of testing. Beyond that, EVERYBODY works late when something breaks. I don't like working late. Or on weekends. Especially when it's not my fault.
".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
|
|
|
|