Work Rants

I found this actual error message today while working with a vendor application: Okay, it wasn't that exact error message. And that's my code. BUT, the first part is verbatim. This is a server-side, vendor-provided, and above all, released product. This is not a beta; we paid someone to give us that error message. What am I supposed to do with that message. My code called your code and it told me "Unable to get resources." Guess I'll just take a nap till those resources can be gotten. Over the years I have seen both vendor applications and custom code where programmers are throwing away valuable information by not properly sending errors up the stack.   You should always, always, ALWAYS send your errors up the stack! * The error above could easily have been something like this: See, now I know something! This is a java.lang.NullPointerException exception in the file MeaningfulError.java - on line 11. That's an informativ

A few days ago, the Powers That Be at my institution rolled out a change to our web authentication scheme. Previously, we were using a proprietary system that somehow played nice with Active Directory. The changed made Active Directory Federation Services play nice with our proprietary system - making ADFS do the real work. Now, we live in the world of Integrated Windows Authentication. I'm all for that, mainly because the proprietary system was a PITA in a lot of cases. This new change makes a lot of thing easier. Plus, now logging onto your workstation logs you into our webapps! Well, not for me. I use a Chrome and Firefox. Well, not yet anyway .... It works great for Safari users on a Mac. However, I use Chrome mostly and Firefox for development testing.  How on earth do I tell Chrome what servers are okay to do Microsoft Integrated Login with? I guessed there was a way to configure Chrome and Firefox to do this, and it turns out there is! However, it&

I have some thoughts on planned downtime. Ultimately it boils down to this: is the planned downtime caused by urgent, impending, and guaranteed doom? If yes, then by all means have the downtime whenever you can. If not, affected as few customers as possible, by the numbers. Planned system downtime should minimize impact to system usage - period. By "System Usage" I mean real customers using the system. I recently had a discussion with the systems group about a necessary outage on a system I support. Something important, but not urgent had the possibility to cause downtime on the system. However, if something went wrong and we had to restart a server, the server might not come up. This was deemed as needing pretty serious attention (which I agreed with). They found a fix and wanted to put it into production, as an emergency, planned downtime. We had a downtime window coming up, but this should probably happen before the window. They suggested an evening. Google Anal

Today, a lady got a promotion. Let's call her Gretchen. I had dealings with Gretchen before, however they were not good. Gretchen needed some content in the portal I manage. Simple enough. Unfortunately, it was going to take some time to identify her stakeholders specifically. Impatience was wining over doing something right. They wanted to cram the content onto every employee's layouts - despite the fact that most of those employees would have no idea what this content was. At the time, I still had the quixotic notion that I could keep the portal relevant, compelling, and relevant. I pointed out that having that additional kind of noise in the portal was not a good thing. If we waited a week or two, I could set it up so the tab only went to the people who needed the content. They said tough shit - we'll do this now. Fast forward a year and we find their tab that had to be pushed to the entire employee population that didn't mean anything to them, complete with

Management is important. Work is about people, not work. Sure the people have to get work done. However, it seems like those assholes never get along. In my experience, when executive leadership needs a new manager, they tend to find someone who's kicking ass at their current job and promotes that person to the next level. Then they throw the newly promoted person to the wolves. Hey, they kicked ass before, surely they will figure it out, right? Not always. People are promoted to their greatest level of incompetence - The Peter Principle.  As an employee, it is important that we are preparing ourselves for our next promotion. Someday, some poor, misguided manager might give us one.  A few years ago, I was promoted from Lead Programmer to Assistant Managing Director. My training was a couple of conversations and then I was sent into the management wilderness to find my own way. As it turns out, I'm a big Maximizer . I already read some books to help me deal

This week, a good friend of mine, came back to Lubbock to a work related trip. I spent the better part of the day yesterday catching up with him. I had forgotten how much we did while we were in grad school. We worked together briefly in the ATLC, we worked in the same lab in Computer Science, we were constantly at Crickets or Abuelo's, or Rosa's eating. I've been on plane trips with him and on car trips with him.  All of that was ten years ago. He moved down to Abilene and then back to Houston. He got a job at NASA, where he has done very well for himself. He has a wife and a daughter now.  While we both have had ten years to grow up and mature, in a lot of ways, our relationship is pretty similar to what it was years ago. While neither of us had a lot of responsibility or accountability to those things which come with maturity, I think we were both pretty grown up already. We were both in our late 20's and neither of us was very wild. Since he moved out