How to code an inline Java Thread

This is an example for how to create an inline Java thread and launch it. The Thread Javadoc describes it in pieces and this is a complete example.

import java.util.Date;

public class InlineThreadDemo {

    public static void main(String[] args) {
        System.out.println(
            "parent thread " + new Date(System.currentTimeMillis()));
        // launch child thread using inline declaration
        new Thread(
            new Runnable() {
                public void run() {
                    try {
                        Thread.sleep(10 * 1000);
                    } catch (Exception e) {
                        e.printStackTrace();
                    }
                    System.out.println(
                        "child thread  " + new Date(System.currentTimeMillis()));
                }
            }).start();
        System.out.println(
                "parent thread " + new Date(System.currentTimeMillis()));
    }
}

The output from the program will be someting like this.

parent thread Mon Apr 30 22:14:02 ADT 2007
parent thread Mon Apr 30 22:14:02 ADT 2007
child thread  Mon Apr 30 22:14:12 ADT 2007

Dial tone, kleenex, Google

I got talking a little while ago with a smart guy at work. He's a veteran developer, doing it longer than I have. We have some similar views about how software should be built.

Anyway we got talking about software quality and reliability, a favorite subject. Of course when the subject is reliability the discussion immediately goes to dial tone. That was kind of interesting, we don't talk about dial tone in terms of reliability. We talk about reliability in terms of dial tone. So dial tone ends up defining reliability instead of the other way around.

It can be pretty good when you have so much mind share that the product ends up defining the term instead of the other way around. For example a guy's girlfriend could ask him to pick up some Puffs Kleenex at the drug store when he's there. That request makes good sense because everyone uses the term Kleenex to describe facial tissue. If someone says to "Google" on something, they of course mean to look it up on the Internet using a search engine.

Usually when creating software or some other product you want to achieve that kind of dial tone, kleenex, Google status. You want to have so much mind share that people define the term using the product instead of the other way around.

However there can be a downside to this if the association is a negative one. For example if someone says something is a "1.0" thing, what they mean is the historic negative experience with the version 1 release of software. That is full of bugs, slow, underfeatured, hard to use. It may not even be called version 1.0, but someone can call it that and then you're in trouble.

Another example would be calling something a "WordPerfect 6.0 for Windows". WP 6.0 for Windows is the definition of the horrible product release. Delivered late, it was extremely unstable, crashing constantly, losing data and frustrating users. That product release was a blow from which WordPerfect never recovered.

Interestingly I know a fellow who was a WP fan. He of course agreed that 6.0 for Windows was bad. However he said 6.1 was much more stable, and by 6.2 they had a good solid product. Unfortunately for WordPerfect, by the time 6.2 was out they had lost virtually all of their market share to Microsoft Word, so 6.2 was pretty much irrelevant. I wonder how many people out there know that 6.2 is pretty good, compared to those who know that 6.0 wasn't. Probably not too many. After 6.0, most people like me just tuned out WordPerfect.

So when someone calls something a "WP 6 for Windows" then you know that it's a bug filled disaster, even if the product has nothing at all to do with word processing.

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.