What's it all about, Alfie?

Well... today starts the first of my last ten days here at the Shop. It's an interesting time - seeing who is chosen to step up and take over pieces of the work I've spent seven and a half years building. It's surprising, and at the same time, about the only choices they can make.

As for me, I'm trying to get done all that I can - given the limited time I have. I can't work on projects that aren't going to be done, it'd be better for me to spend time getting things moved off to other people. But there are a few things I can do, and I'm ticking them off as quickly as I can.

But there's no doubt about it. I'm in the coasting/dispensing phase. I've written up a ton of stuff, people now need to read it and then come back with questions for me. I'm sure it'll get busy, but that's OK, I knew it'd happen.

It's an odd feeling. Anxious... a little nervous... but it's something that it just a part of the job. I'll get through it.

Well... I got a call today from Jeff H. at CTC, and the offer he presented was just too good to pass up. I accepted (verbally) on the phone, and he was thrilled. So was I. He's sending the paperwork out today and I should get it tomorrow. I'll do what's necessary to formally accept the offer once I get it, but that's simply a formality.

I've got a new job!

I was chatting with a few friends about it, and they encouraged me to let my current manager know today, as opposed to tomorrow morning with a formal letter. There's no reason to wait, and it gives them the evening to come to terms with it and begin the planning of what to do on my last ten days. Looking at it that way, I had to see the logic. So I told him.

Interestingly, his first words were: "You're kidding me, right?"

Nope.

We talked about what might have lead to this decision. He's been aware that I haven't been happy for the last several months, and it hasn't come as a complete surprise to him. Still... there's a lot of stuff that needs to be transitioned, and it's going to be up to him to decide how to do it. At this point, I'm answering questions and doing what they want, but I seriously doubt if they are going to be having me do any new work because I can't possible finish it in ten days.

Still... who knows.

More importantly, I'm moving on. It's been long overdue. Jeremy left nearly three years ago, and back then I didn't think I'd last the year. I lasted three. That's a lot of staying power. Troy left 9 months ago, and that was really the final blow. I knew I needed to get out. Thankfully, the position at CTC could not be a better fit. I'm excited about what's ahead, and understandably a little nervous.

Wow.

Yeah... remote access to work is both a blessing and a curse. There are a few times when it's nice to be able to be at home and get a little work done, but in reality, my work is done on several monitors, with (literally) a dozen different Vim sessions open and at least a half dozen shells open to edit, compile, run, monitor and debug the code. It's work. So having a laptop with a 14" screen is not really getting that kind of work done, but in a pinch, it can be done.

No, realistically, it's the support of production systems that remote access is for. That's where it really pays for itself. If you have to get in and fix a database issue, or do a quick fix to a script, then there's nothing like it. Nothing. Getting in a car, driving 45 mins to the office at midnight is just not realistic. You need to be able to do some things - triage the problem, remotely in a few minutes. That's what remote access into work is for.

So while "new guys" look upon it as a liberating, no almost empowering status symbol. "I have remote access now." But then a few years on, they realize that they have no recourse when work needs to be done on off-hours. So it's the thoughtful, or egocentric person that refuses remote access even when it's asked that he have it.

Such was the case today I learned of a co-worker in another land. This co-worker is going to hold up the deployment of a multi-million dollar system because he doesn't want to come in on the weekend and refuses to accept the offered remote access solution so it can be done from home. Interesting idea. Part of me is impressed at this guy's sense of boundaries. There is work, and there is home, and they are not to be confused with one another. Bravo.

But if I were this guy's boss, it'd be a simple business fact of life. One person, no matter how well-intentioned, respected, kind, generous, and giving, can hold up a multi-million dollar project. No one. Period. If he can't do it, then he's got one choice - get it or get out. It's as simple as that. Management is not about being nice. It's about managing a project with risks and rewards. If one person has the ability to hold up that process, then they are a fundamental risk that needs to be addressed. That risk must be eliminated, or at least significantly reduced.

And while I admire his bravado, I am appalled at his arrogance. I don't want to answer problems in the middle of the night. But I do. It's a fact of life in a team where the business runs 24x5. Period. I've taken countless calls - from this guy in the middle of the night, and not complained about it. Yet he feels he's entitled to be the one holdout to this invasion of our personal time.

Good for him. But if I were this guy's manager he'd be toeing the line or walking out the door. It's that simple. This place needs to have a little sacrifice. There aren't enough people to cover things completely all the time. You have to take the lumps now and then. And by making this stand, he's saying there's no reason to do it, and thus empowering the next person to take a similar stand.

If this catches on, there's not going to be anyone for him to call when he needs help. I'm sure he doesn't care, as he'd blame us for not being available.

So I label this person an International Prima Dona. They believe the rules apply to everyone except them. They are the One, after all. In the end, he's nothing more than someone expecting special treatment, and that's likely to get him special treatment by a lot of folks. I hope he's really ready for it.

I have users in many different timezones, and I do my best to keep them all straight - most of the time. But there are times - around the switches where I'm not exactly sure what the time is in London - or Hong Kong. So a few years ago, I got VelaClock for my Mac.

It's a wonderful little Dashboard widget that allows me to keep track of each timezone in a nice, little, compact widget. It's much better than the World Clock widget from Apple, and it's got all kinds of nice little capabilities that I just don't use.

This morning, I noticed that they released version 2.1.11. It's too bad the auto-updater in the widget doesn't work, but that's no big deal. I can go to the site and download it from there. Nice to have for people dealing with a lot of different timezones.

I've been writing an XML file generator in Python hooking into a few data sources (systems) here at the Shop. I'm really quite pleasantly surprised at how easy it is to do all the little things you need to do. Formatting, logging, database, it's all there. With a decent access to the data, and a nice object model, it's downright pleasant.

I have to admit I'm surprised. I expected a more 'stripped down' language than this has shown itself to be. Yes, it's supposed to be all wonderful and that, but until you really need to dig into it, refactor it, and do all the little things that you're not going to find in a simple 'Hello, World!' app, you can have your doubts, as I did mine.

The object model is nice, if not a little confusing. The proliferation of self is a trifle annoying - can't this be inferred from scope? Maybe not. It's something that I can get over, but it is a bit odd at first.

The indenting at least makes things look nice. The speed is first-rate, I'll give you that. There isn't anything I can complain about there.

If I spent a lot of time in it for a few weeks, I'm sure I'd pick up a lot of habits that would make it very nice to write in. Libraries, or finding those libraries like the XML DOM, are real time savers, and yet it takes time to look them up, learn how to use them, etc. Time worth spending, but time you need to spend.

I have to say... it's not PHP, but it's really quite nice.

Over the course of the last few months, I've had a few run-ins with a co-worker and while I initially put it off as a bad manners, lately, I've come to realize that this person is really exceptionally rude - yet thinks of themselves as humorous.

I'm sure there are literally thousands of people we all meet every day like this. They believe that the way to establish some connection with a person is to prod, poke fun, and then with a wink and a nod, let that person know that they aren't serious. To a point, this is understandable. People can be nervous in all manner of ways, and this can manifest itself in a lot of weird behavior, but when this goes too far, it's really quite counter-productive to the work environment.

Unprofessional Behavior. That's what it is. Simple as that. Out on the street, you are free to be as rude and nasty as you can stand. Doesn't make it right, just means that no one really has to deal with you - but you. But in a work setting, this is not really helpful. I've probably made it worse by allowing it in the first place. I should have just spoken up and said "Hey, funny 'Ha ha', but please, let's keep it professional, OK?"

Unfortunately, I've had to get far more blunt with some folks I've worked with. Sad that they didn't take the more mild hint, and I've had to actually say "You're making fun of me, right?" and when they agree, I say "Have you no shame? Please stop." I've been lucky - that usually does it, but in some cases, it's best to just walk away.

There are people that believe they know you, that they are you buddy, and so they say these rude things, as if to say "Hey, you'd only let a friend do this - right?". Wrong. I would never let a friend do that, and I'd never do it to a friend. What kind of friends do you have, anyway? Convicted felons and Wanna-be Stand-Up comics? Give it a rest.

Well... today I started to 'clear the air' with this guy. I got about a sentence into it and realized that he's completely clueless about what he's doing. Has no idea - honestly. Oh... maybe that's environmental, or maybe it's how he's been raised... I don't know. But I decided that there's no reason to has it out with him. None. He's not going to understand it and it'll just seem like I'm picking on him for no reason. After all, he was being "nice" to me.

In these cases, it's time to walk away. Really. He's free to attract as many "friends" as he can with these particular social skills. I only have to work with him. When I see his particular brand of 'humor' in communication, I'll just have to write it off as nonsense, and move on. I'm not interested in being insulted and winked at, as if that makes it all better, and he's not about to change how he deals with "friends".

I've run into this a lot in at least a few languages - Java and Python. The coder thinks he's saving something by saying:

  import java.util.Date;
  import java.util.Vector;
  import java.util.Stack;

as opposed to simply saying:

  import java.util.*;

I mean really... what are we saving here? Nothing. Exactly nothing. The reading of a file? No... it's still got to read what it reads for the three classes from the one jar file. Microseconds on the compile - maybe. But what have you done? You've forced all additional developers to enumerate all classes they are using. Why? Is it really that important?

It gets worse in Python. I ran into the following code:

  import logging.config, os, sys

where the normal developer would say:

  import logging, os, sys

Can't imagine we've gained anything by just loading the config if we're really do any logging, chances are we're going to actually log. But what I found out today is that this can cause a ton of trouble in systems with the thread package built-in and using the dummy_thread.py stub.

For these guys, you really need to do the following:

  try:
      import thread
  except ImportError:
      import dummy_thread as thread

and in doing this we are able to use the thread package as if it always existed - even when it doesn't. Decent. And the logging package does this - so long as you import it properly. If you try to, oh, I don't know... say import just the logging.config package this isn't done and then all of a sudden the dummy_thread.py isn't pulled into play and you get import errors in the python logging libraries.

Argh!

So I have to ask around and see who might have done this and for what reason. I don't want to make a change that will break something just to get something else to work. We need to have everything working, and if that means we need to put more work into this guy, then so be it, but I'm very clear that this is code written here and not a part of the core Python code.

It's something I'm going to have to deal with on this little project. It's not fun, but it's what I have to do.

I'm continually amazed at the lack of documentation that most developers I meet write. They don't think it's necessary for their work - after all, they wrote it. Who else needs to understand it? Who else needs to use it? Well... if they need to use it, they'll come and talk to me and I'll walk them through it and then they'll be OK.

It's an incredible double-standard. If they ask for docs from me for something (and most developers I work with have, from time to time) I give it to them. Why? Because I wrote it. I wrote it for myself, and then built the code based on those docs. I know they didn't write the docs otherwise, they'd give them to me.

No, and I've run into a class of developer that if I don't have docs for a process or procedure ready, they want them as opposed to the "talk through". I have to provide it for them so they can make their process or procedure. But when I ask for it, they think I'm being unreasonable. These people are just lazy, no two ways about it.

But the general mass of developers that don't write docs, or even comment their code so that it's at least able to be followed by someone are the ones that get me. They know the value of the docs, but still they refuse to write them. They know it'd make things a lot easier, but they aren't concerned about making the other guy's life easier... they had it hard, so why make it easier on the guy following them? Selfish, is all I can think of. Unkind as well.

So I'm sitting here realizing that I have very little in common with developers like this. I'll continue to work with them, but it's a waste of my time to expect them to change. Maybe they'll run into someone that gets them to write them, and then see the value in having them. But until that day comes there's nothing I can do to make them see the err of their ways. Sad.

I can't help but feel sad for a guy that I've been working with for over seven years. Yesterday, he was "let go" by the trading-side of the business, and then offered a job on the development-side of the shop. Don't get me wrong, I think he'll be a fine developer. But getting that one-two punch in the gut yesterday had to hurt. I don't care who you are.

We can all be pushed to our limits and show our less wonderful sides to people. It's what happens. Stress causes us to get more "kill or be killed" and that, in turn, suppresses our kindness and tolerance for others, and we show a face to others we might not want to show. It's happened to me, it'll happen again. It's happened to this guy, and it had to be a contributing factor in his getting released from the business-side.

The reason I feel for this guy is that becoming a developer for him now is a nice landing, but it's like having once been a Vegas Headliner and then going back to teach elementary school kids how to sing and dance. It's a huge blow to the ego. I don't care who you are.

Some may certainly get over it faster than others, but we're still in the first 24 hrs. and that's definetely in the "ouch" phase of this particular life-lesson. I just wonder if management is really thinking he's going to stick this demotion out. Sure, the economy is not strong, but this is the financial sector, and there always seems to be jobs out there - someone is making money. If not on the market, then on the volatility. So I wonder if he's going to stick it out.

I hope he finds what he's looking for. Whatever that is.

I noticed this morning that one of my price injectors was hung up in a poor, sick little infinite loop when the service (vendor provided) had died and then I restarted it. I had not coded up the library to close and re-open the connection. In an attempt to make my application fault-tolerant to this service's restarts, I decided to dig in and add in all the pieces I needed to properly reconnect when the service was restarted.

If only it were easy.

The first thing I had to do was to unroll where I was in the processing so that I'd pause what I was doing (or trying to do) when an error with the service was detected. That didn't take too long, but I wanted to make sure I didn't put in the logical equivalent of the goto statement, so it took a little bit of work to handle it properly.

Once that was done I needed to have the main thread detect this condition and then close/re-open the connection. Here's where I really started to run into problems. While the code appeared to be what I needed, I would get just a few attempts and then a double free core dump. Every time. And it was always in the vendor's API code. It seemed that no matter what I did there was no way to avoid this problem. Crud.

So what if I tried to "go around the horn" and exit the app with an error condition and then have the guardian script that started the app, and restarts it in the case of a core dump would see this and restart the app. That's OK, but what if it fails right away? Well... that's the problem. So what I tried next was to put a retry loop on the creation of the connection to the service. Maybe that would work.

Better. It seems that so long as the connection isn't ever really made, you can call the open() call as many times as you need to get the job done. I'm getting a lot closer. Now that I have a way to exit the app with an error and restart it with a retry loop all I had to do was to make sure we didn't litter the directory with core files. The final problem was that trying to close a troubled connection lead to the same double frees that I was getting in the first place.

So I had to put in even more logic to the wrapper classes on the vendor's API so that I could be assured that the application could exit cleanly and then the restart would take care of waiting until the service was up again.

Finally I had something. It took a few hours, but in the end I have a system that's fault-tolerant to the vendor's service restarts and that's what I wanted to build today. It's going to make it much stronger a system. Good news.