Venting

[joel]

Okay, time for me to vent for a few. I'm not going to (fully) name names, and it seems relatively unlikely that any of the people involved will ever bother reading this journal even if they found out it existed, but frankly, even if they do? This is my ranting. If you're here, you think it is about you, and you care about my opinion, then do something to fix the cause.

So I got asked, back in December, if I was willing to be part of a "conversion" team. For context, we have separate (but sitting next to each other / loanable / flexible) teams for Recorder ("Land and Vital Records"), Assessment & Tax (... and Appraiser), and Treasurer software. All of these are for local (county) government customers. I've been part of the Tax team since we first formalized the split into these teams. However, I've been the conversion specialized *on* the A&T (hereafter just "Tax") team since well before that, even. And the flip side is being the Tax specialized on the conversion team. So I say "Okay" because, frankly, there isn't anyone else who can fill the role, despite some misgivings.

I'm starting to wonder if I should have listened to those misgivings more and considered more whether saying "no" would have gotten me fired, because most of the things that I actually enjoy about work, that have made it a fundamentally different place to work... are missing from this team, and I can't figure out any way to get them to exist.

Granted, I may be spoiled; pretty much everyone around, if asked "Which team has the best 'team dynamic'?", would point at the Tax team. And I'm not talking about 'team-building' exercises. I'm talking about the fact that there is regularly laughter in our aisle, that banter and ribbing are par for the course, and that even when we don't agree about things, there is a general consensus that we need to find *something* that is at least tolerable to everyone, or at the very least put something temporary in place long enough to give us a chance to figure out a better answer -- and that it really is *temporary*, when that happens.

And I think part of the last paragraph is telling: while I am still technically sitting on the same aisle -- at least until later this week -- I wrote the entire paragraph speaking as if I were still part of that team. With the Tax team, we had two members off-site, another seven or so on-site, and generally did things like arranging for a team lunch once every two weeks (exactly as often as we had the planning meetings, and originally on the same day) where we all figure out somewhere to go and just hang out and eat lunch together. And the main difference between that and the office is how many straw wrappers are getting shot across the table at someone.

The conversion team, by comparison, has a total of five people, and three of them are off-site. Only myself and the manager are actually on-site, and she... well, she isn't a horrible person or anything, but she's the sort of person who things that talking about stuff means you're ignoring your work, because she really doesn't appear to have the concept at all. Or perhaps just doesn't exhibit it much around the office.

This means that it is difficult to build any sort of team dynamic at all, since most interactions are actually one-on-one rather than the team as a whole. Perhaps that is contributing to what set me off today, hard to say. Certainly it meant that I really was not comfortable saying several of the blunter things I otherwise might have to someone on the Tax team, had they done something similar... because anyone on the Tax team would have taken it and... you know, that really isn't quite it. It is that I wouldn't have *needed* to say anything so blunt *and directed* about it; the conversation I had this morning that was blunt but about the 'why' of a design would have sufficed.

Okay, time to back up a step. Of the four people on my team:

• L (the manager/lead/whatever) is more or less okay, though having a somewhat abrasive personality (in general, not just with me). But really, I can deal with that without it being a big issue. It isn't exactly like I'm a paragon of tolerance and benevolence all the time, either.

• K is nominally a developer but would almost be better categorized as a DBA, or at the very least a SQL expert. He knows how to do a lot of things in SQL that I can't even sanely keep track of. The only real issue is that this tends to lead to an "everything is a nail" sort of mentality. But he a pretty good personality, and apart from occasionally needing to be poked by phone because he loses track of following up on emails, he's reliable.

  Biggest day to day issue is that he tends to get a bit cantankerous about anything that might require a change in the existing routines. But he can usually be coaxed around if you can convince him that it is either (A) truly worthwhile, or (B) so low cost a change that it really is trivial.

• R is *extremely* good at ensuring that his code works; he is quite possibly more thorough about it than our QA folks, and they are probably the best QA folks I've ever worked with. Unfortunately, his method of developing is to make a copy of some vaguely similar code he has from some earlier task or project, drop it into place, and then beat on it piecemeal until he can get it to pass his testing.

  Now, I have to grant, the code does work. But he has, literally, 50 copies of what is basically exactly the same class (of significant size) with perhaps a dozen lines that change. Within what should be two methods, but refactoring also isn't a strong point. However, he also acknowledges his limitations and does seem interested in trying to learn how to do things better, I'm mostly just frustrated by being unable to help him get tot the point that the lightbulb suddenly turns on and he goes "Oh!" -- and I know full well that some people will *never* have that happen. I just can't tell if he's one of them.

• S is the one that set me off today, and is... well... more below the list, but I will just say that he is a classic case of someone who needs to have "If you are going to go off and do it your own way, for fuck sake DO IT RIGHT GODDAMNIT" beaten in until it sticks. However much that takes. He is not only extremely prone to the "quick and dirty" solution -- emphasis on the "dirty" -- but also extremely *proud* of it and of the opinion that everyone should do things that way.

So what set all this off? This morning on the stand-up call, S mentioned that one of the conversions had been running far slower than expected, and he had tried to cancel it and nothing happened. I said something like "it should have just finished the cycle for what each thread was working on, then terminated -- were they completely hung?" and got back something like "No, why would it terminate? There isn't anything in the read loop to do that". This sets off alarm bells, because the entire architecture is set up to make what he's talking about an impossible issue to have if you're writing it even remotely correctly. "Uhm. Is it an *ancillary* conversion?" Dreading the response, and accurately predicting that the answer was "Yeah". After a pretty serious inward mental wince, I said I'd talk to him after the call about it.

Cut to an hour or two later, when I manage to get my IM client patched up and functioning again. I send him an IM, and explain that the reason ancillary conversions don't support cancellation the way normal conversions do is that they aren't intended to be used for anything that would ever run for more than a couple of minutes at most, or in fact anything that would ever need to be interrupted, because -- among other things -- they don't store any state about how much they have or haven't accomplished. And that if we're going to change code we should just change the conversion itself to bring it up to spec, which will *also* improve the speed issues that were the cause of his wanting to cancel it in the first place.

Cut forward further, to about fifteen minutes before quitting time. I get an IM from him saying that he'd implemented it and checked it in, that it was easy, etc. Now keep in mind, I never said above that it was *difficult*, only that it was a *bad idea* because it was basically adding a feature that was only relevant if you were doing things *the wrong way in the first place*, which needed to be fixed *anyway*.

When I'm fully on my meds and nothing has been screwy lately, it is an extremely bad sign if I have to forcibly keep my temper in check while at work. Doubly so when it is at a *person*, rather than, say, a piece of equipment. People get the 'humans are fallible' pass. But *deliberately* spending much of a day doing something that you've been *told* is not something that should be done, instead of spending that same time *fixing the actual issue*? In a code-base that I'm the senior/lead developer for, that *I originally wrote* and you derived from (poorly), so that you can continue to fundamentally abuse the way the architecture was set up for absolutely zero benefit (and in fact noticeable drawbacks)? Yeah, that's enough to pretty seriously piss me off.

I won't even go into the amount he bitches about how all this new code "completely ignores the lessons learned in the legacy product", and how "documents were never the right way to go" (understand that 'Document' is quite probably the single most fundamental piece of our entire product, and that it was an architectural decision made for solid reasons back in 2002 *when they were deciding that legacy was no longer up to the requirements*), and so on. That's another post entirely.