We've hired a new CEO at work. Since I joined Core Networks in the summer of 2001, this is the fifth CEO I've had. We also preannounced this quarter. This is the third time in the last seven quarters we've preannounced. I don't think many people are expecting the new leader to just maintain the status quo.
In the nine years I've been in software, there's been some interesting times. I've been acquired three times. I've survived eight downsizings. I left a job on my own. I've been fortunate to not yet been downsized. I've also not yet been in an office or company that was shut down. So far so good.
As always I'm grateful to on the inside working in high tech. The pay and benefits are good. The coffee is free. The work can be challenging and interesting at times. The cubicles are comfortable. The office is climate controlled. The PC is fast and the monitor big.
The change is a fact of life in high tech. I sometimes miss the stability and continuity of PRIOR Data Sciences back on Spring Garden Road. It was civilized, things were done a certain way. Spring Garden Road was happening and downtown. Alas, PRIOR is no more.
Sunday, April 09, 2006
Monday, April 03, 2006
I'm LinkedIn
I heard from a former coworker last week. She invited me to join her network on LinkedIn. It looked interesting and I respect her, so I joined. So now I'm LinkedIn, yay for me.
My network only contains the one person, so I should try to increase it I guess. I'm not sure who I should ask to join. It would be a good time to try to find some of my old TUNS (now DalTech) fellow students and find out how they are doing. Back then around 1/2 the TUNS CS Class of 1997 joined Nortel, who I'm sure would have hired the other half too if we'd wanted to join. I wonder what became of them. At least of some of them are likely still there, but certainly not all of them.
My friend's network was interesting. She has around 12 people. Some of the names I recognized as people I'd worked with before. One guy I knew from St. Mary's and TUNS. Some of the others were well known players in the local startup scene. It was pretty good company to be in, so it's nice to be remembered positively after we'd worked together in the past.
One time there was this insane Core Networks project where she was team lead and everyone was working really hard on it. There was a key integration testing weekend before the first baseline went to the test team, and she said that everyone was on call and had to come in if problems were found in their area. I had a quiet weekend. On the Monday after she told me she'd phoned everyone else in the department over the weekend except me with code issues. No problems were found in my code. That's kind of a party trick I have of writing all kinds of features and lines of code with very low defect rate, something I take pride in. I take bugs in my code personally, but in my career I've noticed that few others do. Most people I've ever worked with are indifferent to bugs in their code.
It has made me realize I've been part of the Halifax software startup scene for nearly five years now. In my own modest way I've contributed to building a new company, and to building the Halifax software industry. I think it will be interesting to see what directions my career takes in the next five years.
My network only contains the one person, so I should try to increase it I guess. I'm not sure who I should ask to join. It would be a good time to try to find some of my old TUNS (now DalTech) fellow students and find out how they are doing. Back then around 1/2 the TUNS CS Class of 1997 joined Nortel, who I'm sure would have hired the other half too if we'd wanted to join. I wonder what became of them. At least of some of them are likely still there, but certainly not all of them.
My friend's network was interesting. She has around 12 people. Some of the names I recognized as people I'd worked with before. One guy I knew from St. Mary's and TUNS. Some of the others were well known players in the local startup scene. It was pretty good company to be in, so it's nice to be remembered positively after we'd worked together in the past.
One time there was this insane Core Networks project where she was team lead and everyone was working really hard on it. There was a key integration testing weekend before the first baseline went to the test team, and she said that everyone was on call and had to come in if problems were found in their area. I had a quiet weekend. On the Monday after she told me she'd phoned everyone else in the department over the weekend except me with code issues. No problems were found in my code. That's kind of a party trick I have of writing all kinds of features and lines of code with very low defect rate, something I take pride in. I take bugs in my code personally, but in my career I've noticed that few others do. Most people I've ever worked with are indifferent to bugs in their code.
It has made me realize I've been part of the Halifax software startup scene for nearly five years now. In my own modest way I've contributed to building a new company, and to building the Halifax software industry. I think it will be interesting to see what directions my career takes in the next five years.
Monday, March 06, 2006
Hammer that keyboard
Here's a tip if you spend most of your work day working at a computer, like most programmers do. It is a lot faster to use the keyboard than the mouse. The mouse slows you down. You have to interrupt yourself to reach over and it is slow and imprecise to use. Then you have to interrupt yourself again to get back to the keyboard.
You will be more productive if you learn the keyboard accelerator shortcuts for the programs you use heavily during the day. Any professionally written application has them. Many good applications allow them to be customized so you can create a binding for a command you use a lot that takes three menu clicks to invoke with the mouse. The keyboard shortcuts will just save you tons of time if you learn and master them. It is a small investment in time that will pay off many times over.
I find it surprising at work how few people realize the benefit to using the keyboard over the mouse. As programmers we write the applications so should want to make them fast and easy to work with to test, yet a lot of people don't.
One time a couple of years ago a co-worker was struggling and using his mouse awkwardly with his left hand. I said to him, "I thought you were right handed." He said he was, but he was having carpal tunnel problems in his right hand so was trying to start using the mouse left handed to lessen strain on his right hand. I suggested to him that he should learn to use keyboard shortcuts and avoid using the mouse at all as much as possible. He gave me a kind of "nnnyaa, I don't really want to do that" look. What can you do? Even with a career threatening condition he still wasn't eager to consider the potential of the keyboard. It's kind of funny because he was a GUI developer so he had the ability to put in all the hot keys and get the default focus and tab indexes right to make it easy on himself.
Pulling it together with this post, and my previous posts on leveraging your IDE, and Google desktop search, there is a theme. My point is that there is a lot you can do to be more productive without working any longer or harder. Optimize your work environment to make things easier for yourself.
You will be more productive if you learn the keyboard accelerator shortcuts for the programs you use heavily during the day. Any professionally written application has them. Many good applications allow them to be customized so you can create a binding for a command you use a lot that takes three menu clicks to invoke with the mouse. The keyboard shortcuts will just save you tons of time if you learn and master them. It is a small investment in time that will pay off many times over.
I find it surprising at work how few people realize the benefit to using the keyboard over the mouse. As programmers we write the applications so should want to make them fast and easy to work with to test, yet a lot of people don't.
One time a couple of years ago a co-worker was struggling and using his mouse awkwardly with his left hand. I said to him, "I thought you were right handed." He said he was, but he was having carpal tunnel problems in his right hand so was trying to start using the mouse left handed to lessen strain on his right hand. I suggested to him that he should learn to use keyboard shortcuts and avoid using the mouse at all as much as possible. He gave me a kind of "nnnyaa, I don't really want to do that" look. What can you do? Even with a career threatening condition he still wasn't eager to consider the potential of the keyboard. It's kind of funny because he was a GUI developer so he had the ability to put in all the hot keys and get the default focus and tab indexes right to make it easy on himself.
Pulling it together with this post, and my previous posts on leveraging your IDE, and Google desktop search, there is a theme. My point is that there is a lot you can do to be more productive without working any longer or harder. Optimize your work environment to make things easier for yourself.
Friday, February 24, 2006
Skateboarder NYC v1.0 game
I've released another game that I wrote.
Skateboarder NYC v1.0 is now available for download over on my free games site.
It's freeware and the Python source code is available.
Enjoy!
Skateboarder NYC v1.0 is now available for download over on my free games site.
It's freeware and the Python source code is available.
Enjoy!
Monday, February 06, 2006
All nighter
Last week I pulled an all nighter at work. I hadn't done one since the death march project last year.
A problem was found in some code that was to be used for an imminent customer demo. It turned out to be a newly discovered bug in the same troublesome code from the project last year. Fortunately I was able to find and fix the problem, and the demo went more smoothly.
It was a long night. I was finished up some other stuff and putting on my jacket to leave at around 8 PM when my director comes running out of his office to tell me there was a problem and could I look at it. So I wasn't really prepared for it. Fortunately we have a coffee machine at the office with Starbucks coffee. I put on a brew. I ended up drinking most of it through the night - yuck!
I'm glad things turned out pretty well. People seemed appreciative of it. The next morning one of the product managers said he'd go to McDonald's and get me whatever I wanted for breakfast. I got a sausage McMuffin and coffee. McDonald's coffee is pretty good. That was a nice gesture by him. The grease hit the spot.
Hopefully this will be the last all nighter due to that troublesome code base. Am I confident we've found and fixed all of the bugs? Hardly! In the next product release most of that problematic code is now rewritten. Going forward I expect things will work much more smoothly. Also I can actually really understand what the code is doing now. So if there is an issue with either my code, or the external systems that interact with my code, it will be significantly faster to isolate problems and fix.
Generally I prefer to avoid rewriting existing code. It is generally difficult to justify the effort to spent developer time revisiting code that seems to work. In this case we wanted to improve product performance, so we had to revisit the inherited code. Plus we will save maintenance headaches going forward by avoiding situations like the one described above.
I don't have an equation for when to rewrite. It's a decision you make based on your experience, judgement and instincts. I'm generally skeptical of the value of rewriting code that seems to work and whether you'll truly be better off for doing it.
Sometimes there can be political pressure against rewrite. There may be a large sunk cost in the existing code base. Also a rewrite could be seen as a knock against the reputation of the original developers, so that may not be popular.
Still, when you know that rewrite is the best solution then you need to push ahead and do it.
A problem was found in some code that was to be used for an imminent customer demo. It turned out to be a newly discovered bug in the same troublesome code from the project last year. Fortunately I was able to find and fix the problem, and the demo went more smoothly.
It was a long night. I was finished up some other stuff and putting on my jacket to leave at around 8 PM when my director comes running out of his office to tell me there was a problem and could I look at it. So I wasn't really prepared for it. Fortunately we have a coffee machine at the office with Starbucks coffee. I put on a brew. I ended up drinking most of it through the night - yuck!
I'm glad things turned out pretty well. People seemed appreciative of it. The next morning one of the product managers said he'd go to McDonald's and get me whatever I wanted for breakfast. I got a sausage McMuffin and coffee. McDonald's coffee is pretty good. That was a nice gesture by him. The grease hit the spot.
Hopefully this will be the last all nighter due to that troublesome code base. Am I confident we've found and fixed all of the bugs? Hardly! In the next product release most of that problematic code is now rewritten. Going forward I expect things will work much more smoothly. Also I can actually really understand what the code is doing now. So if there is an issue with either my code, or the external systems that interact with my code, it will be significantly faster to isolate problems and fix.
Generally I prefer to avoid rewriting existing code. It is generally difficult to justify the effort to spent developer time revisiting code that seems to work. In this case we wanted to improve product performance, so we had to revisit the inherited code. Plus we will save maintenance headaches going forward by avoiding situations like the one described above.
I don't have an equation for when to rewrite. It's a decision you make based on your experience, judgement and instincts. I'm generally skeptical of the value of rewriting code that seems to work and whether you'll truly be better off for doing it.
Sometimes there can be political pressure against rewrite. There may be a large sunk cost in the existing code base. Also a rewrite could be seen as a knock against the reputation of the original developers, so that may not be popular.
Still, when you know that rewrite is the best solution then you need to push ahead and do it.
Tuesday, January 03, 2006
Welcome RIM
Recenty Research in Motion has announced they are coming to Nova Scotia, with 1200 tech support jobs. This is great news for the high tech industry here in Nova Scotia.
I notice RIM has posted some Halifax jobs on Workopolis. I subscribe to Monster and Workopolis alerts, even though I'm not looking to switch jobs. I just like to know what's going on. People in tech seem to be pretty gossipy about what companies are doing well or poorly, and what the hot skills are. If you just listen to the chatter around your cubicle you can pick up a lot.
The tech scene in Halifax has been very weak the last few years. The period of 2001-2003 was very tough, with hardly any jobs posted. I think there were more New Brunswick tech jobs posted in the Saturday Chronicle Herald than Halifax jobs. A lot of people who had jobs in high tech had to move on to other industries. A lot of new grads weren't able to break into tech during this time and had to find work elsewhere. I was fortunate myself to be able to stay employed the whole time.
Things stabilized through 2004-2005. Hopefully it will continue to improve through 2006 and beyond. It's strange why it was so tough in high tech in Halifax the last few years. Like everywhere, we grew in the late 90s. However we didn't have a huge Internet startup scene so the bust itself didn't really cause any spectacular job losses.
It's interesting that RIM will be locating in Burnside park. In the early 2000s there was a move to establish Bayers Lake park as a tech "cluster". Although xwave and Core Networks moved there, few others did and the cluster didn't get off the ground. The RIM decision pretty much kills any hopes for a cluster in Bayers Lake.
There is a huge cluster of furniture stores in Bayers Lake though. I understand a top big ticket item salesman can pull down very good compensation. That's not quite the cluster the city planners hoped for, but still a good living for a fair number of people.
The thing about the other clusters in Canada like Waterloo, Ottawa and Vancouver is they have a strong hardware presence as well as a big software scene. For whatever reason you need a big hardware presence to have a tech cluster in Canada. Software alone just won't do it.
I notice RIM has posted some Halifax jobs on Workopolis. I subscribe to Monster and Workopolis alerts, even though I'm not looking to switch jobs. I just like to know what's going on. People in tech seem to be pretty gossipy about what companies are doing well or poorly, and what the hot skills are. If you just listen to the chatter around your cubicle you can pick up a lot.
The tech scene in Halifax has been very weak the last few years. The period of 2001-2003 was very tough, with hardly any jobs posted. I think there were more New Brunswick tech jobs posted in the Saturday Chronicle Herald than Halifax jobs. A lot of people who had jobs in high tech had to move on to other industries. A lot of new grads weren't able to break into tech during this time and had to find work elsewhere. I was fortunate myself to be able to stay employed the whole time.
Things stabilized through 2004-2005. Hopefully it will continue to improve through 2006 and beyond. It's strange why it was so tough in high tech in Halifax the last few years. Like everywhere, we grew in the late 90s. However we didn't have a huge Internet startup scene so the bust itself didn't really cause any spectacular job losses.
It's interesting that RIM will be locating in Burnside park. In the early 2000s there was a move to establish Bayers Lake park as a tech "cluster". Although xwave and Core Networks moved there, few others did and the cluster didn't get off the ground. The RIM decision pretty much kills any hopes for a cluster in Bayers Lake.
There is a huge cluster of furniture stores in Bayers Lake though. I understand a top big ticket item salesman can pull down very good compensation. That's not quite the cluster the city planners hoped for, but still a good living for a fair number of people.
The thing about the other clusters in Canada like Waterloo, Ottawa and Vancouver is they have a strong hardware presence as well as a big software scene. For whatever reason you need a big hardware presence to have a tech cluster in Canada. Software alone just won't do it.
Subscribe to:
Posts (Atom)