Cashed in stock options

I recently experienced something that many in high tech get to do. I cashed in some stock options. I often didn't think I'd ever get to. The first options I was granted were in 2001 with my previous employer. And it's only now that I saw anything from them.

The company stock price unfortunately tumbled after they acquired my previous employer. When we joined we were granted options. We've also gotten additional options at annual review. In the subsequent grants, the stike price was lower based on the lower stock price.

With the new CEO, the company has done better, and the market price has improved. Some of the options in the subsequent grants are now modestly in the black. So I decided to cash some. I would have preferred to wait because they aren't far in the black at this point and the company has a strong upside potential. However I have some short term financial issues which unfortunately created a need for a shorter term view of things.

I didn't know what the process was to cash out. I thought it would be just click some buttons and the money would be there. There was a bit more to it than that; it's an interesting process which requires a bit of patience.

Our company employee stock plan is handled by e*trade. Once the trading window was open I logged in. etrade has an excellent user interface and bringing up the screen and selecting the 750 option shares to cash on a same day sale was very easy and intuitive. So on the first eligible day, a Tuesday, I did the clicks and the order was executed immediately as expected. Great.

But then I was a bit surprised. The execution was immediate but then I learned that the trade was not "settled". The help said settling takes around 3 business days, but sometimes longer for employee stock plans. Well Friday came and went and it was still unsettled. It wasn't until the next Friday that it settled, 10 days after the execution.

I got the etrade e-mail saying it was settled and was excited. But then there's another step. After settling it takes a bit longer for the proceeds to get into my etrade account. So Friday became Monday and then the money was there.

Now to spend the money I had to get it from my etrade account into my regular chequing account. I had a link set up between my etrade account and my chequing account. It was very simple to do the cash transfer between the etrade US money stock account and my Canadian bank account. But this time I wasn't surprised when it said it would be the next day for the money to appear in my bank account.

Finally the next morning the proceeds from the stock options was indeed in my bank account. It was two weeks after the order execution. So now I know what to expect. I hope to be able to cash out some more options. If the stock price can go up by around $2, then that would be very nice. At that level our original grant after the takeover, which is the largest grant, would be worth cashing. Also due to some SOX accounting thing or whatever, our original grants are actually fully vested, so the potential gain would be pretty nice.

All together I cleared an amount about equal to the take home pay from one paycheque. We get paid twice a month. So not bad, can't complain. It was a nice reward for the hard work over the years. I still have lots of options uncashed so if we can have a nice stock price run then that could be good for me.

For etrade I give them a very positive review. Their site is excellent. It's secure and easy to use. The user interface is laid out logically and navigation is straightforward. There's plenty of context help. With the alerts I always knew what was going on through the process. In the future I hope to be able do some investments again. I would be inclined to use etrade for that based on my experiences with them here.

Timestamps and productivity

A few years back with the company that my current employer acquired there was this big death march development project. The project was crucial to all the good things that happened later and everyone was on board with it.

I was arriving for work at a crazy early time and working steadily through the day, leaving around regular end of day time.

There was this other guy I noticed who arrived shortly before 8 each morning. He'd still be there when I left. I noticed that he'd be sending out e-mails and doing check ins around 8:30 in the evening. I thought at the time, man that guy is putting in long hours, a solid 12+ hours a day.

A few months later in the lunch room we happened to get talking about that project. I mentioned about the long hours he'd worked on it. His reply surprised me. He said that he'd just been working around 7:45 AM to a bit after 5 PM each day. Then he'd log in remotely at night from around 8:30 PM to 9 PM. It was while logged in remotely that he'd continue with what he'd been doing during the day. Hence the evening e-mails and check ins. To me not realizing about remote desktop it seemed that he'd been working longer hours than what he did.

Remote desktop is nice. It's great when you have family commitments and such. You can get home at the usual time and when necessary log in from like 8 PM and work several hours from home if necessary, while not being disruptive to family responsibilities.

My company is good in that we care about the amount and quality of work that people do, not the hours worked. Some companies unfortunately are preoccupied with hours worked, although this has limited correlation to quality and productivity. There's stories over on Joel on Software about people staying a couple of hours late in the evening to work on something, then going home and waking up 3 AM to dash off a quick 'done' e-mail and getting all this credit for pulling an all nighter because some PHB was obsessed with e-mail timestamps.

Still, it's important to get credit for all the work that you do. So if you're topping up your regular work day by logging in remotely then it's good to send out an e-mail in the evening or do a check in. It makes you look good and draws attention to the extra work you do. Also it's not a bad habit to invest 10-15 minutes in the evenings to log in remotely and check your late day e-mail that might have come in after you left. It will make you look good if you can reply before the next morning.

10 years in high tech

As of today I've been working in high tech for 10 years now. I started full time at PRIOR Data Sciences back in January 1997. Wow, 10 years of this. I started full time right after my last exam in December in my Computer Science degree at the Technical University of Nova Scotia.

While at TUNS, I did all of my three Co-Op work terms at PRIOR, and they asked me to come on full time after I graduated. That was a huge good break getting on with PRIOR for that first work term back in January 1995. Of course I had to do a good job to get invited back for more work terms and subseqent full time.

In the 10 years lots has happened. PRIOR did a management buy out, then was later acquired by xwave. I navigated through Y2K and the dot com boom/bust. I've switched jobs on my own, been acquired a couple of times, and survived numerous downsizings. I'm lucky I've never been out of work in high tech. I've prospered financially in this career.

Things were different in 1997. At that time it was exciting. It seemed the possibilities were unlimited. PRIOR had a good team I still think well of including Martin M, Sean B and Jim P. They were outstanding individuals. Not just technically but they got the finer things in life like La Maison which I thought was so cool to be around. It made me aspire to reach that level myself.

My career is linked to my personal life. Very shortly after starting full time I was engaged, then married by the end of 1997, with a child by 1998. My life away from work has affected my career and vice versa. I've made moves in my career that I wouldn't have without personal considerations. I've also not made career moves I would have made if I was single and unattached.

I started out as a programmer. Today I'm still a programmer. That's a bit disappointing looking at it from the big picture, considering what seemed possible and even likely starting out. Still I like programming and I'm pretty good at it. I'm happy to keep doing it as long as someone will pay me well and slightly more each year to do it.

So 10 years in. Can I last another 10 years? I hope so. I don't have much else to go on so I hope I'm able to stick around.

Versatile programmers

I work as a programmer for a small consultingware ISV. Since we're small, everyone has to be flexible and take on roles outside their primary area from time to time.

Programmers tend to be higher up the skills chain than some others in an ISV. As a result we have the ability to be reassigned to a number of non-programming roles at the same skill level or lower. These tasks could include in no particular order

QA testing
creating product documentation
creating online help files
sales engineering
professional services
producing training materials
delivering live training sessions
level 1 and 2 tech support
consulting
providing a reassuring presence on a customer site
creating content to demonstrate at trade shows
attending trade shows


In general there is little to no transferrance the other way into the core programming team. This is because it is generally difficult to impossible to quickly reposition someone up the skills chain instead of down it. For example it would not be realistic to try to cold reassign a tech writer or level 1 tech support rep from their usual role into the programming group for a couple of weeks to help the product team meet an end of month deadline. They don't have the required skills and experience to function effectively as programmers. So the standing programming team can only lose resources, and never gains them.

In larger companies, it should be possible to properly separate the programmers from the other roles. The other teams are big enough to be properly staffed and are expected to fill in their own shortfalls using their own means. In a smaller company we have to be more flexible and cannot just isolate the programmers from having to occasionally do non-programming tasks. Especially in consultingware, which is about smaller numbers of big sales, we have to be responsive to sales opportunities. When you're close to a big sale you do what you have to to make that sale. The success of the products and the company depends on it. Sometimes the distinction between the core product and a customization can be somewhat blurry. If the programmers can help make the difference in a short term big opportunity then that's worth doing.

In general it's not economical to reassign programmers to other roles since programmers tend to cost more than the roles they are taking on. So assigning a programmer who averages a loaded $100K a year to do tech writing or level 1 tech support than can be adequately staffed at a loaded $50K a year isn't cost effective in the long term.

There is a hidden cost to reassigning programmers. The cost is that the programmers cannot advance the core products when they are doing other tasks. At Microsoft there is a really good saying among the programmers: "If you're not writing code then what are you doing?" That really focuses the mind on what the programmers are there for. What's more important that a programmer should be doing than creating source code. Every day a programmer spends not writing code is a loss for the products he would otherwise be advancing. This cost is not immediately apparent, and may seem negligible in the short term. However over time it can be extremely costly if the core product becomes uncompetitive in the marketplace.

So the programmers immediate manager, product management and the company in general must be educated to understand the potential costs of reassigning programmers. In general requests for programmer reassignment should be carefully reviewed and challenged, and rejected if a compelling business case cannot be made for it.

In a dysfunctional environment, the programming team would be like a buffet table where any other group can help themselves at any time to a warm body or two to cover over a local shortfall. If you have a small programming team to begin with and you've got one person doing phone/email tech support, another one out of town at a trade show, another on another continent holding hands on a customer site, another helping set up a sales demo, two others over helping out with a QA cycle, and someone else conducting training sessions then you basically have nobody working on the actual products which will then be at risk of becoming uncompetitive. That's an extreme example but you have to be vigilant to keep the programmers writing code.

A use for Internet Explorer (XML viewer)

Normally I have little use for Internet Explorer, except at annoying sites that only work with IE. I switched to Firefox years ago and have never regretted it. Hello tabs!

However a smart guy at work showed me a handy thing that IE is actually useful for. IE does a pretty good job of rendering raw XML. It shows it in a nicely formatted, color coded way where you can open and close the branches to narrow focus to a specific area.

This is useful for me because I deal with SOAP a lot at work on the server side. Clients visiting the internal web service tend to be shaky and get themselves into a bad state, and do strange things that cause problems. We necessarily log all of the SOAP/XML that we send and receive. When a problem occurs it is very useful to see the exact SOAP content that was sent or received on the wire.

Now viewing SOAP content can be a pain. On our side we use Tomcat and Xerces. While this is robust and reliable, it also generates the XML all on one line. This is fine for a computer to process but hard for a human to read. Previously I had to copy and paste from the log file into a text editor and insert line breaks manually to see the actual valid XML/SOAP we sent that the client was having problems with.

Using IE, there's a much faster, easier and better way.

Create a document on your desktop called t.xml.
Make sure your settings have IE as the default application for .xml files.
Right click on t.xml and open using a text editor.
Replace the existing t.xml content with the XML copied from the log file.
Save t.xml and close.

Then just double click t.xml on your desktop and it comes up nicely formatted in IE with all the attributes and namespaces and everything right there. This is very handy and a real time saver.

HP

So HP has had some negative publicity lately. What an idiot that board member was to make those leaks and cause all that trouble. That was good of Patricia to take one for the team.

I still think well of Hewlett Packard. I've always thought well of HP. Back when I was in high school, they were considered a very prestigious company. They made the engineers calculators and the ultrasound machines and the testing equipment. I once read this article that HP had resorts around the world for their employees and that it was great to work there. Back then I hoped I could work at HP some day.

The PC I'm writing this from is an HP pavilion. If I ever get a digital camera I'll be looking for an HP one. Back at PRIOR Data Sciences, they had HP laser printers. I got talking to a sysadmin one time about laser printers and problems I'd seen with printers at other sites. What he said was this: the thing about printers is, go with HP. Don't fool around with anything else, you'll regret it.

Alas, times changed. They got out of calculators. They spun off the medical and test equipment into Agilent so that HP, a decades old company, could try to present itself to the late 90s stock market as some kind of dot com startup. D'oh, so much for that plan. Then Carly Fiorina dismantled the "HP Way." Nice one Carly.

A friend of mine who's an engineer had an interview with Agilent a couple of years ago. I was excited when he told me. We both recalled the old HP reputation, and agreed that Agilent was the good HP, the original HP. I recall he ended up landing another job before things progressed very far, so it goes.