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.

happy trails Joel

My long time favorite tech blogger Joel Spolsky of joelonsoftware has now signed off.

It was a great site in its heyday. Thanks for the memories and great articles Joel! And the forums were great in their heyday, the hub for those programmers who "get it".

Alas, like a great TV series the writers "ran out of things to talk about" and the last years weren't as good as the first. It was indeed time to shut it down on the 10th anniversary. The later years were OK, but like Seinfeld nobody says that the last 3 seasons were near as good as the first three.


It wouldn't be cool to bring it up in the forums but I was thinking of when did Joel jump the shark? Was it when he started requiring log in to post in the forums?

For me it was the "very special Joel" when he had this wrenching ethics crisis about accepting freebies from site sponsors such as Peer1 hosting. And going forward he would voluntarily begin paying for these things that previously he quite openly admitted he was getting for free in exchange for the product placement on his popular site. The site just wasn't the same after that.

4 in 17

At work I've expressed interest in being involved in the recruiting process. As it happens we're thinking of bringing in a co-op student for the January work term. My team leader remembered I'd expressed interest in recruiting and asked if I wanted to attend the phone interview.

I agreed and me and the lead manager went to a conference room to phone the candidate. He is not a local student.

The phone interview went ok. It was around a half hour. After the interview though I had my own decision. Maybe I shouldn't say my decision but instead I'll tell a story from the past which has always stuck with me.

Back at PRIOR around 10 years ago a co-worker was talking about a TUNS course. A TUNS prof lived on his street and he volunteered to mark the compilers course. He got talking about the students in the course. There were 17 students in that compilers course. The assignments were code heavy and my coworker got to see the code they were writing to mark it. It was a third year course and everyone who took it passed.

He commented on the course afterward. Based on the code they wrote, of the 17 students in that class only 4 were good enough to work at PRIOR. The other 75% weren't talented enough for PRIOR. [I believe 3 of the 4 did do at least a co-op work term at PRIOR as it happened and 1 or 2 ended up joining full time]

For some reason that has always stuck with me. 4 in 17. TUNS had a good reputation and a number of good grads came out of there and went on to successful careers both in graduate school and in industry. Still only about 25% even in a class like that were really good.

So in product development, you need to be patient and choosy in recruiting. It can be a challenge wading through unqualifieds looking for people who can come in and be reliable contributors. With co-ops better to leave a position unfilled than to bring in someone clearly in the other 13 of 17 just to fill it.