Happy 25th Commodore 64

Here's a couple of links around the 25th anniversary of the Commodore 64 [1], [2].

I started out programming on the Commodore in junior high school in the early 80s. Those were the best times to be into computers and programming. The Commodore 64 was a great machine with sprite graphics, sound, and 38911 Basic Bytes free.

I had the Commodore dot matrix printer and easy script word processor that my sister used in university. At that time she was about the only one printing her essays. In word processing things like cut and paste were sensational advanced features.

I had a 150 baud modem which cost over $100. The 2400 baud Hayes modem sold for over $1000 at the time.

Commodore brilliantly made their joystick port compatible with the Atari 2600 so it was easy to get controllers from the Atari and use them for gaming. And we spent many hours playing games on the Commodore64. Some of the best were Mule, Archon, Summer Games, 7 Cities of Gold, and on field football.

A choice in the matter

We recently missed our quarterly targets and had to preannounce. As often happens after a miss there was a round of downsizing. I'm fortunate and happy that I got through it OK.

This round was different than other RIFs with this company and other companies I've worked for. The timing was such that the downsizing was done in the late stages of a big development project. As a result the affected individuals will be staying on for a while longer until the big project finishes. Historically during a downsizing people would kind of just disappear like Syme in 1984.

Another thing that was different was that in the reorganization some individuals were offered new roles in the company. However they had the choice to decline the new position and be laid off instead with the same severance and access to unemployment insurance as those who didn't have a choice.

Almost all of the people who had a choice chose to stay on. However two individuals chose to take the severance and leave. Those who chose to leave have some similarities. One guy said that if they tighten up their expenses a little bit then he will be cash flow neutral on his wife's salary. The other guy is married with no children and his wife has a good job.

The people who seem to have a bit of a financial backstop to afford being out of work for potentially a while have chosen to take the severance. I don't believe they have new jobs lined up, they are just going to take their time and explore new career opportunities.

If you can afford it then it makes sense to take the severance if you are at all on the fence about staying. It would suck to decline severance today and then leave voluntarily in say six months and get nothing. Also all things being equal they should be confident they will find a comparable job at comparable pay in a reasonable time. The local tech economy is pretty robust right now. With a financial backstop they can afford to "gamble" that they can find something else quickly and pocket the difference in severance.

Code and Content

In this product release I spent a good bit of time implementing quite a few reports. Our product has a reporting engine and the report content can in theory at least be created by anyone. For the out of the box reports "anyone" turns out to be the programmers on the software development team.

Most software products to some extent at least allow individuals other than the original programmers to add on content to extend the product and make it better. The reporting engine in our main products is an example of this. Generally it's good to have this. It allows more people to be involved with making the product better. It also allows the programmers to focus on the underlying core functionality and allows others with more domain knowledge to work on those areas.

One part of software development that really uses this is games. Creating a commercial quality game is a large undertaking. The number of people involved in putting a release together is huge. I've noticed that the programmers are only a small percentage of the people invovled in getting a game ready. Far more people are involved putting together the content around the game. One of the programmers jobs is to set it up so that as much of the work as possible can be done by non-programmers, the creative content people. The content people will do things like design levels, add player information, create storyboards and such.

A good example of this is the park editor in the Tony Hawk underground games. This game has a park editor feature where the end user can design their own skateboard park. The game itself ships with hundreds of parks already created. The park editor is an example of where there can be a real nice separation between the code and the content. The programmers were responsible to create the park editor itself and make sure it worked properly and was easy and intuitive to use. The content people actually designed all of the parks in the game using the park editor. With good communication, the content people will be eating their own dog food and providing feedback to the programmers about how to make the park editor better and easier to use.

PureText

This is a very handy utility for just moving text between applications and cutting off the formatting cruft that messes things up. When I'm copying a number from Word into Excel or code from Eclipse to Outlook I almost always just want the text. The formatting from the originating application is no use in the target application. Before I had to use tedious options such as paste special or do the paste then select and reformat the text in the new application.

It turns out this is not necessary thanks to PureText. With PureText I copy in the usual way then use Windows+V to paste and all that gets pasted is the text without the formatting. Slick. Thanks for doing this Steve Miller.

The joy of Oracle outer join

I've been working on report definitions lately. The work involves writing various database queries which are the data source that feed the reports.

One of our requirements is that the reports are to be able to run on an Oracle or SQL Server database. So I'm keen to use common SQL that will work on both DB platforms as much as possible in order to avoid having to maintain separate Oracle and SQL Server queries.

Some of the reports require outer joins. In the past this would have required separate SQL. Oracle used an awkward (+) notation to indicate outer joins. SQL Server uses the more standard OUTER JOIN syntax.

I'd kind of resigned myself to this but then I remembered that Oracle now in 9 and later now supports the ANSI OUTER JOIN style for indicating outer joins. This is great and I was able to do my queries using outer joins reusing the same SQL for Oracle and SQL Server without requiring separate DB specific syntax. Thank you Oracle for adding this.

One thing I'd been a bit suspicious of with OUTER JOIN was that it seemed hard for me to grasp what was going on with how the tables were joined. There were joins going on in the FROM section as well as standard joins down in the WHERE clauses. I found it hard to grasp this.

But then I kind of had a eureka moment when I realised that in the FROM clause the OUTER JOINs were creating a virtual table off the primary table which was outer joined to the other tables. So then everything made sense to me thinking about the OUTER JOIN clauses as forming a single virtual table which was then joined and evaluated in the usual way down below in the WHERE clause.

Of course all of an SQL query is about forming a virtual table which is the query results but once I was able to visualize what was happening in the FROM clause the OUTER JOIN now seems quite natural and intuitive. I hope I won't have to ever go back to trying to remember which side to put the (+) on.

HTTP session attributes and Python

I've done a good bit of Servlet development over the last couple of years. I've generally found Servlet to be pretty good to work with. I feel Servlet is about the best part of J2EE.

The thing about Servlet was that when it came out in the late 1990s it had to compete for market share and developer mind share. They had to convince people to start using it. So Servlet does things that are developer friendly. For example within Servlet development the programmer has access to the full JDK. So you can do stuff like launch threads and use synchronized methods or go to the file system. This is great and I've developed a new appreciation for the richness of the Java5 JDK.

Also with JSP/Servlet it is fast and easy for a new user to get running quickly. Tomcat and the JDK are free to download. From a standing start you can get a hello world page up quickly in just a few minutes. The web.xml can be minimal and mostly stays out of the developer's way.

With Servlet the container helps the developer and adds useful functions like the HttpSession. What I really like about HttpSession is the session attributes. This is a delightful little feature. You just start using them by name with like session.setAttribute() and read them back somewhere else with session.getAttribute(). This is very useful to pass stuff around between different functions. I like it because it reminds me of Python where you just start using stuff and don't have to worry about it being declared or strongly typed. It's very convenient and developer friendly. The fast, convenient and easy to use session attributes are an example of how Servlet is designed to be developer friendly.



Unfortunately the Servlet experience is not typical of working with J2EE. I suspect with many of the other J2EE components like EJB the developer community was considered captive. Since they didn't have to compete for developer mind share they didn't spend very much time or effort thinking about the developer experience, developer productivity or being developer friendly.

No I'm not a spammer

I clicked over to this site to start a post and I'm greeted by this.




Sorry about the small image. In summary Blogger thought this is a spam blog. I wasn't allowed to make new posts and had to click on the link to get them to review the blog to get off the spam blacklist.

I clicked the link then Blogger reviewed me and of course said I'm OK in this e-mail.


from: Blogger Help
to: "cbmc64@gmail.com {U 947063870279 B 19504237}"
date: Aug 24, 2007 8:55 PM
subject: Re: [#190813934] Blogger Beta non-spam review and verification request: http://cbmc64.blogspot.com/
mailed-by: trakken.google.com

Hello,

Your blog has been reviewed, verified, and cleared for regular use so that
it will no longer appear as potential spam. If you sign out of Blogger and
sign back in again, you should be able to post as normal. Thanks for your
patience, and we apologize for any inconvenience this has caused.

Sincerely,
The Blogger Team


--
So I'm glad to no longer be considered a spammer. I wonder why I got marked as spam. Perhaps I have haters who flagged me for some unknown reason, lol. I'm not sure what else about this site might make the Blogger algorithm think I'm spam.

No worries, I'm glad the site wasn't deleted. I was thinking of making some changes to this site layout anyway so now this is more reason to. Being mistaken for spam though is pretty discouraging.

Productizing

It's remarkable how much stuff can be added to a product without adding any new end user features. Often an initial product release is tied to a specific sale to an individual customer. The customer has a specific environment and the development team is able to get the initial release done on time by building to just that setup.

After the initial sale you want to sell it to additional customers. At this point the initial customer specific release becomes more productized. That is, the application is made able to run in different settings. These are some of the things we've added to the main product in my office since the original release.

-added support for additional application servers
-added support for additional databases
-added support for new host servers i.e. Windows
-fully tokenized the user interface labels to support additional languages
-add support for right to left rendering in the user interface
-make it easier to customize or rebrand the user interface
-add support for running in a clustered application server with failover
-spent time on performance analysis and improved performance in high load environments
-Javadoc code review and improvements
-JUnit code review and improvements
-refactoring and streamlined the internal modules structure
-use xdoclet to generate EJB baggage
-added support for several new iterations of the device specification and new data models, while maintaining backwards compatibility and workarounds for non compliant devices
-rewrote almost the entire inherited code base

Together these changes required several person years of effort to implement. These structural changes added no new end user features, but were necessary to make the product saleable outside of the original customer.

This type of productizing is what makes future releases take longer than the original v1.0 release for a specific customer and environment. Making things generic and customizable always takes longer than being customer specific and rigid. Adding support for new databases, application servers and host servers causes the number of development and testing combinations to become much larger and that necessarily slows down the development cycle.

Investing in backup technology

There are some standard desktop hardware technologies around that can maintain developer productivity in the event of common failures.

A longstanding thing is desktop uninterruptible power system. Our office is in an industrial park. Power outages are a fact of life here. They occur during the day several times a year. A very basic desktop UPS for around $30 each gives the users 10 minutes backup power on their desktop to save their work in progress, shut everything down cleanly, and log out.

In some cases in addition to lost unsaved work it can be difficult and time consuming to restart some applications if they do not stop cleanly. JBoss and WebLogic are like this.

Without desktop UPS people can lose up to several hours work. When this happens it is very frustrating for the user. In addition to lost productivity it also affects morale. The power is going to go out at least once a year. What's three hours of productivity plus employee satisfaction worth? Is it worth a one time expenditure of $30 per desk? I'd think and hope so. What's the marginal cost of a $30 UPS relative to the amount spent on each cubicle?

A more recent innovation is the dual hard drive PC. With hard drive costs coming down these can now be added to a PC for around $300. With dual HD, when your primary hard drive fails, which it inevitably will, your backup is right there and you don't lose anything you had set up on your PC.

For a programmer, we have all kinds of stuff on our PC hard drives. Little Python and shell scripts we write. Stuff we download like Ethereal and all kinds of other stuff, JDBC drivers, JBoss, all kinds of other stuff we use every day. PDF and Javadoc documentation. Plus all the settings like Firefox bookmarks and Office settings, Eclipse. Getting a PC set up again is a tedious, frustrating and unenjoyable process for a developer to go through.

When a programmer loses his hard drive, then the time to get back in business is around two full business days. And hard drives fail. I'd say around 50% fail in the first 30 months in a new PC. I'd guess about 75% fail in the first 5 years. In my office I've been there 6 years. In that time I've been lucky to only lose a hard drive once at work. However almost everyone else I work with has had at least two HD fails in the last two years. Some have had three. Everyone has had at least one.

Is two days of developer productivity worth the $300 extra to include a dual HD on new PCs. I'd think so. If not then why is he working there, it costs more than $150 per day for him to be there. This is a small investment that will enhance productivity and morale and is well worth it.


I guess something that could inhibit a company from making these small investments to enhance productivity and employee satisfaction would be the concept of visible vs. invisible costs. If the employees time is not billable then the immediate cost of lost employee time to things like power outages and hard disk crashes is zero. There's no direct and immediate cost to things like employee frustration at avoidable lost time. However there is a real and measurable cost to things like desktop UPS or dual HD. So unfortunately the visible cost outweighs the much larger though invisible cost and the investment is not made.

For billable employees, if billable time is lost then that's financially painful to the employer and they should be inclined to make these small investments to keep that billable tap open. Still, for non billable programmers their time should be really just as valuable to the employer as billable programmer time is to a consulting type software company.

Software Project Variables

A little while ago I was at a house party. I got talking to a fellow who does creative work for marketing campaigns. I asked him if it's true that two thirds of the money spent on advertising is wasted. He agreed that it was.

He said with advertising you can have it fast cheap or good, pick two. That rule applies in a lot of areas. I remember the first time I saw fast cheap good. It was a sign on the wall of an auto body shop when I was a child.

A veteran developer at the office who has team led some key projects in company history had a slight twist on it with software projects. In a software project ther are four variables that are naturally balanced against each other. They are scope, schedule, resources and quality.

Scope is the features contained in the release. Sometimes the scope is based on a sale or a contract agreement so all of the features must be implemented to get paid. Sometimes with a more internally defined project there may be room to cut or scale back features so the project can be completed within the desired timeframe. Problems can occur in a software project when the original scope expands. If scope increases then this must be balanced against the other three factors. The problems can occur when features are just "added" but no allowance is made in terms of resources or schedule for the new work.

Like scope, schedule is often pre set based on external agreements so cannot be changed. Sometimes in a project this is the one variable which does not change throughout. Often the software team is evaluated by meeting scheduled dates above any other objective. Of the four project variables schedule is often the most difficult one to change after the project begins.

Scope and schedule are often balanced against each other. I've been on many projects over the years where somebody wanted to add something during the project. When the project manager informs that any addition in scope can only be accomodated by slipping the schedule, the feature request goes away. I can recall many instances over the years where the person requesting the feature changed his mind when faced with a schedule slip. I can't recall a single time when someone agreed to slip a schedule of an in progress software project in order to add new features.

Resources generally means the head count of people working on the project. This can be increased somewhat if necessary. But as Brooks points out, you quickly reach a point of diminishing returns when adding resources. One type of resource which is often added is overtime. That allows the team to stay smaller and more manageable while being able to get more done in the same amount of calendar time. Overtime does have its costs though as quality tends to slip in the long sessions and the extra hours tend to be less productive per hour as it adds up.

Which brings it to quality. The reality is that quality tends to be the easiest place to take the hit on when a project is too big and too complex for the time and resources allocated. The thing about quality as opposed to say features or schedule is that the programming team does not have to get permission to slip on it. It can just happen and nobody knows about the quality issues until after the fact.

Unlike a schedule slip or missing features, a quality shortcoming is not immediately obvious. So it's easier to maintain an illusion of a successful software project when in fact the project was not as successful as hoped. A quality slip can take different forms besides obvious defects in the running product. Low quality can appear when the code is poorly structured and hard to maintain. Code copy and paste is used instead of refatoring common pieces. Javadoc and JUnit is skimpy or skipped entirely. Quality can appear as an unintuitive user interface lacking polish. Quality problems can appear in the form of low performance or crashes under load.

For the develment team lead and manager, when a software project is getting started they need to communicate to the stakeholders the factors that are always balanced. Sometimes the people outside the development team want to push for lots of major features and an aggressive schedule. The software team needs to communicate clearly up front when it is obvious that the hit will be on quality if that is the only factor which is allowed to vary.

High Tech and the Monkeys

You may have heard the story of the monkeys and the cold water.

http://www.mountainhome.af.mil/news/story.asp?id=123027878

http://www.eve-tribune.com/index.php?no=1_26&page=4

I'm sure this happens in all industries, and it can happen a lot in high tech. What happens is that at some point there is some limitation, restriction, bug, inexperience, or lack of knowledge about some technology. So we start doing things in a certain non-optimal way to work around the bug or because we didn't know the correct way at the time. The incorrect way becomes the standard and we continue doing things that way far into the future, long after the original constraint has disappeared.

The thing with software is that we are often using leading edge technology. Often the new technology can contain bugs or limitations that requires workarounds that are kludgy, ugly or verbose. In later releases the problems from the earlier releases are fixed so the workarounds are no longer required. However the workarounds become standardized so we don't update the old code and continue to write new code to the old ways.

Also because of schedules we don't always have time to fully explore the libraries we work with. So if a new version of something comes out that makes it easier to accomplish some task, the programmers might not even know about it because they didn't explore all the new features and fixes in the new release. They just use the old code with the new libraries.

So you might come across stuff like this as generic examples.

Q: Why do we use all this verbose formatting instead of printf?
A: printf wasn't around until Java 1.5. This code was written before that so we did it that way.

Q: Why is the security stuff with JSP, EJB and roles so strange?
A: Well, _blank_ who doesn't work here anymore, set it up this way originally years ago. Plus there was a requirement at the time which was later dropped for a special 'guest user' mode that we had to accomodate. It just became the standard and was never revisited once it was working.

Q: Why is there so much awkwardness around setting and getting DATE fields with the database.
A: Originally five years ago there was a bug in the Oracle JDBC driver so we had to do these ugly workarounds with dates and UTC.
Q: But that JDBC driver bug was fixed years ago.
A: Yes well we didn't realize it was fixed and once we got it working after much pain it just became the standard way.


When new people join an established team with an older (like 2+ years) code base then the new person will often have a fresh untainted perspective and can point out some stuff that the existing developers were doing wrong or non-optimally. Sometimes the original developers will not be aware of all the newest library features, or will be operating under old constraints that no longer exist.

If you join a new team and are working with new technology and the existing code base is several years old, you may see stuff that might not make a lot of sense. There's a good reason it's there because of the monkeys.

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.