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.
Monday, March 06, 2006
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.
Wednesday, December 28, 2005
F7 your way to a better career
I find typos in e-mail annoying. It’s a distraction that makes it hard to concentrate on the content of the message.
Some people don’t care about e-mail typos. They either don’t notice them or don’t mind them. Perhaps the majority are this way. It wouldn’t surprise me if that’s the case.
Should you care about typos in your e-mail? Perhaps you should, for a few reasons. While you may not mind typos in e-mail, some of the people reading your message might. If that person is your boss or someone else important then you’re making yourself look bad. Typos in my opinion just make you look sloppy and less smart. People who are perceived as sloppy and less bright tend to not do as well in terms of career and salary advancement and job security.
Also, e-mail has a way of being read by people other than the original recipients. So your message may end up being posted on a department Wiki, or forwarded to people you didn’t expect to see it. e-mails can be distributed much further than originally intended. If your e-mail ends up “broadcast” out then I’d think you would want your writing to look crisp and polished.
There is an easy solution. You can make yourself look good with virtually zero effort. Before you send that e-mail, just click F7 in Outlook to run a spell check. It’s fast, and Outlook does all the work. The image you project at work is important. This is a very modest investment in your time that could pay off well for your career.
Some people don’t care about e-mail typos. They either don’t notice them or don’t mind them. Perhaps the majority are this way. It wouldn’t surprise me if that’s the case.
Should you care about typos in your e-mail? Perhaps you should, for a few reasons. While you may not mind typos in e-mail, some of the people reading your message might. If that person is your boss or someone else important then you’re making yourself look bad. Typos in my opinion just make you look sloppy and less smart. People who are perceived as sloppy and less bright tend to not do as well in terms of career and salary advancement and job security.
Also, e-mail has a way of being read by people other than the original recipients. So your message may end up being posted on a department Wiki, or forwarded to people you didn’t expect to see it. e-mails can be distributed much further than originally intended. If your e-mail ends up “broadcast” out then I’d think you would want your writing to look crisp and polished.
There is an easy solution. You can make yourself look good with virtually zero effort. Before you send that e-mail, just click F7 in Outlook to run a spell check. It’s fast, and Outlook does all the work. The image you project at work is important. This is a very modest investment in your time that could pay off well for your career.
Friday, December 23, 2005
Eclipse tips and tricks
I've been working in Java for around a year and a half now. One of the best things about Java is working with Eclipse. It is a very good product.
When I started out, I found the product to be complex and intimidating. That's no surprise. While it has a good user interface, it's a powerful product with a number of concepts to grasp. Some people like to jump right in with new technology. For myself, I don't like starting without knowing anything.
Before starting Java development, I wanted something to read for an overview of how to use Eclipse effectively. It turns out that Eclipse has such a document. Under Help, click Tips and Tricks. This will bring up the tips and tricks switchboard.
From the switchboard I selected the Java development option, then the platform option. Each option brought up an extensive overview of useful things a developer could use. I printed off both and read them over.
It took around 2+ hours to read both tips and tricks right through. It was time well spent. I gained a much better understanding of what was going on in Eclipse and how to use it effectively. Especially useful were some of the time saving features and shortcuts.
I'd say that the 2-3 hours I spent reading the tips and tricks that first morning paid off in time saved within around the first two weeks. After that it's been all gravy. The Ctrl+Shift+R trick alone that I didn't know about before has saved me more than the amount of time I spent reading the tips and tricks. There are a number of things I use all the time in there that I wouldn't have known about otherwise.
When a new version of Eclipse comes out I reread the tips and tricks. They are updated to cover the features of the new releases. Also I sometimes absorb stuff that I might have overlooked previous times I read it.
So if you're starting out in Elipse, or even of you've been using it for a while, I recommend you read the tips and tricks.
When I started out, I found the product to be complex and intimidating. That's no surprise. While it has a good user interface, it's a powerful product with a number of concepts to grasp. Some people like to jump right in with new technology. For myself, I don't like starting without knowing anything.
Before starting Java development, I wanted something to read for an overview of how to use Eclipse effectively. It turns out that Eclipse has such a document. Under Help, click Tips and Tricks. This will bring up the tips and tricks switchboard.
From the switchboard I selected the Java development option, then the platform option. Each option brought up an extensive overview of useful things a developer could use. I printed off both and read them over.
It took around 2+ hours to read both tips and tricks right through. It was time well spent. I gained a much better understanding of what was going on in Eclipse and how to use it effectively. Especially useful were some of the time saving features and shortcuts.
I'd say that the 2-3 hours I spent reading the tips and tricks that first morning paid off in time saved within around the first two weeks. After that it's been all gravy. The Ctrl+Shift+R trick alone that I didn't know about before has saved me more than the amount of time I spent reading the tips and tricks. There are a number of things I use all the time in there that I wouldn't have known about otherwise.
When a new version of Eclipse comes out I reread the tips and tricks. They are updated to cover the features of the new releases. Also I sometimes absorb stuff that I might have overlooked previous times I read it.
So if you're starting out in Elipse, or even of you've been using it for a while, I recommend you read the tips and tricks.
Subscribe to:
Posts (Atom)