poor performance vs. overtasking

Apropos of a recent Dilbert it got me thinking of how certain problems can manifest themselves.

suppose an employee's performance is not up to standard. this would include the following symptoms

• excessive overtime
• missed deadlines
• poor quality of delivered work

on the other hand suppose an employee has been overtasked, assigned more work than there is time to complete. the evidence of overtasking includes

• excessive overtime
• missed deadlines
• poor quality of delivered work

well what else to say? it may not necessarily be 100% of one or the other. also since the symptoms are the same there may be very sharp disagreement between management and the employee what the real problem is.

lol Acer

I noticed a recent comment by Acer about the new Microsoft tablet. I found that amusing about "negative impact" on the Microsoft ecosystem.

Speaking of harming the ecosystem. Back at Core Networks and SupportSoft there used to be some Acer gear around. They were famous for blurry monitors and desktop PCs that failed prematurely. I once told the IT guy to not bring in any more Acer equipment as

Acer = white box clone = junk

Naveen moment

Years ago I read the story of Naveen Jain at InfoSpace. An interesting tale of that time.

This is the sequence I found remarkable from January 2001. On January 10 Jain left InfoSpace. Then this

... word spread that Jain was looking at office space in the same Bellevue building to start his own wireless company. His business concept involved micropayment technology — using a cellphone, for instance, to order and pay for a latte at Starbucks and having it ready when the customer walked in the door.

...

The board decided it had no choice but to ask Jain to return and run InfoSpace as chairman and CEO

I wonder what it would have been like to be an InfoSpace employee at that time. Jain leaves, ok, absorb that. Then, because he has some incredible idea that is so potent they have to bring him back.

So that's what a Naveen moment is. You're going about your business and then some incredible, unbelievable thing comes along and it's true.

It doesn't have to just be business or personnel type stuff. Back at SupportSoft one time there was an issue our server was not processing Inform messages from certain devices. It turns out that the DSL modem was emitting malformed XML, failing to escape an ampersand & character that had been typed into a text field during the config for the sales demo. That of course crashed the XML library we used to parse the Inform.

So we told the vendor what the problem was. Then the Naveen moment: we were asked if we could put in a workaround on our side! How can an XML parser be expected to parse something that isn't XML. Yet after some grumbling we did figure out a workaround. We put a preprocessor in front of the XML library to find the specific issue of unescaped ampersand. sheesh.

You don't want to be at a company that has too many Naveen moments.

active directory integration

Everywhere I've ever worked the network has been Active Directory (AD).  Now AD is fine, it does some things very well.

So a couple years ago at work they brought in MKS Integrity. There was training and the MKS consultant worked in something like "MKS is enterprise, you just log in as yourself using your regular AD credentials". At the time I thought, wow that's cool. It was to me unheard of some app that didn't have it's own separate login module.

Well a couple years have gone by and one of the good innovations in software is that AD integration is now pretty much standard for corporate webapps. It's no longer just a selling point for big iron, enterprise class type software like MKS. I should say I like MKS and I can say it is a solid product line.

At this time AD integration is widely available including in open source systems such as Jenkins. It's to the point where it is now quite noticeable if some app comes along which does not offer AD login out of the box - I'm looking at you Rally! Before it was standard we would just passively accept having separate login to however many corporate apps we used but now it is highly annoying when faced with having to "create an account" and keep track of yet another login and password. It's really inexcusable at this point for any commercial intranet type app to not have AD login out of the box.

In just a couple of years it has become so natural and expected when faced with some new internal web app to of course login as yourself using your network login. What else would you log in as? It's been a good development this standardization around AD integration.

back to the Perl future

I've been with the development integration team for a little over a year now. The team had been around for a couple of years before I joined. A lot of the DI team's code is in scripts. And almost all of the scripts are in Perl.

Now this was a change for me. I hadn't looked at Perl in years. I dabbled with it a bit back at Core Networks like over 10 years ago. The truth is somewhere around 2001 I happily converted to Python and never looked back.

But I knew when I joined DI it is a Perl shop. There are a number of Perl developers in the office many of whom have common roots in previous companies to our current employer. All are over 30. I can say that the active Perl developers are technically sharp with good judgment. So if they used Perl extensively over the years and still actively use it then I know there's something there; it's good technology.

But with me Perl has taken some getting used to. The syntax just seemed to be hard to grasp. So I knew I needed to catch up. So I did some self education. I heard good things about Leaning Perl so I ordered it with my own money. The Llama book is a very good read. It presents the material in a very sensible way. It provides the key information to get rolling without getting sidetracked with being pedantic, weird and obsolete syntax forms, or going off on tangents. I definitely recommend Learning Perl to anyone finding themselves getting started on Perl development or maintenance.


It is useful the book is presented training style with exercises at the end of the chapters. These were quite valuable to work through as they force the reader to really better grasp what was presented by actually using it.

So finally I can properly grasp the legacy code and better understand what's going on. I gained some more respect for Perl from this book. There is a certain power with all of the shortcuts and special rules. Perl does have the ability to produce moments of satisfaction when working with it.

It's the kind of thing I think you need to be working with it pretty much every day. So lately I've found at work when I need a little script to do a bit of work I've been using Perl more just to get more ad hoc experience.

So the Llama is a good start. I'll let this absorb for a few months or so then start on some more Perl reading when I'm ready. I think Intermediate Perl would be a good next title.

update

It's been a while since I've posted. I haven't forgotten about this site. I'm glad Google still knows about it and steers some visitors here. I still work in software and I haven't lost interest in programming and software development. I guess I ran out of things to write about.

So what have I been up to the last year and a half or so? Around a year ago I joined a new team at work. I now work in Development Integration (DI). It's kind of a support role for developers and QA. We still write code but not so much shipping product code. We aren't testers or automated test developers but we do support QA and automated testing and continuous integration. We don't own the builds but we work with development and the build teams to support builds. We aren't gatekeepers but we support the dev teams enlightened use of CM.

It's been a good move for me. My company is big enough that we can have separate teams that do development integration work. After over 14 years in the cubes as a heads down coder I was ready to try something new.

There have been two rounds of downsizings this year. Luckily I managed to survive both. These were the first RIFs since I joined back in 2008. I didn't write about them because I've written on that subject in the past and I didn't have anything new to say. I hope the company can get back on track and it will be more stable again going forward.

In my year with DI I have observed some things and formed some thoughts. So I have a couple of posts to do in the coming weeks.