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.
Wednesday, December 28, 2005
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.
Tuesday, December 20, 2005
Eclipse Javadoc tips
Lately at work we've been emphasizing Javadoc more. I here's a couple of things that I noticed Eclipse will do to make it easier to create Javadoc.
- if you type /** above a function then press Enter, then Eclipse will generate a Javadoc skeleton for that function
- Eclipse will also auto format your Javadoc content after you type it in. Type in the content from the Javadoc skeleton. Then select the Javadoc comment block and press Ctrl+Shift+F and Eclipse will do a pretty good job formatting it. So you don't have to manually edit your Javadoc for indents, column width, and line wraps. Just type in the content and get Eclipse to format it.
--
I sent the above around to the developers at the office. Like my note before about Google desktop search, a few people appreciated it. I find it's good when you discover some tips about your work environment to send them around to your co-workers. You'd be surprised what people don't know and aren't using.
- if you type /** above a function then press Enter, then Eclipse will generate a Javadoc skeleton for that function
- Eclipse will also auto format your Javadoc content after you type it in. Type in the content from the Javadoc skeleton. Then select the Javadoc comment block and press Ctrl+Shift+F and Eclipse will do a pretty good job formatting it. So you don't have to manually edit your Javadoc for indents, column width, and line wraps. Just type in the content and get Eclipse to format it.
--
I sent the above around to the developers at the office. Like my note before about Google desktop search, a few people appreciated it. I find it's good when you discover some tips about your work environment to send them around to your co-workers. You'd be surprised what people don't know and aren't using.
Friday, November 18, 2005
Split the team for code and test
My previous post about JUnit got me thinking some more about the subject.
Traditionally in projects I've worked on the developers write both the code and the JUnit tests. The developer will write some code, then write tests for the code he just wrote. This means that a developer will spend a portion of a project schedule writing the code, and a part of the schedule writing the JUnit tests.
I wonder if that approach can be improved. I'll use an example. Consider a software development project with six developers. One of the developers is also the team leader. The team leader both develops code himself and manages the other developers on the project. This example is somewhat based on a project earlier this year where I was the team leader with around six developers. Although this example refers to Java and JUnit, it applies to the general issue of code and formal code testing.
In the traditional model described above, all six of the developers would both write code and write JUnit tests for that code. I can immediately see drawbacks to that approach.
Well I think there may be a better approach than that described above. Instead of having everyone do both code and test, split the development team into two. Have a code team and a test team. The code team does all the code. They should do informal scratch and feature testing as they go, but not formal JUnit testing. The testing team does the formal JUnit tests on the code the code team writes.
Using the example above, the team of six would be a three person code team and a three person test team. The original team leader is the subteam leader code team and remains the overall team leader. One of the JUnit test team developers is appointed subteam leader of the JUnit team.
I can immediately see benefits to this.
Sounds good to me so far. Of course there are some hazards to this type of plan. I can see some political type problems from this. Some people are suspicious of change in general so a departure from established ways may meet resistance just because it is a bit different.
The other issue may be in the assignment of developers between the code and JUnit teams. Some people might not like the idea of developers being on a software project but being "relegated" to unit testing and not writing production code. One way to deal with this is to mix it up over different projects and have developers be code team on some projects and JUnit team on others. Or just deal with it and use it as an incentive to the mediocre developers to improve themselves to get on the code teams.
I think it's worth trying.
Traditionally in projects I've worked on the developers write both the code and the JUnit tests. The developer will write some code, then write tests for the code he just wrote. This means that a developer will spend a portion of a project schedule writing the code, and a part of the schedule writing the JUnit tests.
I wonder if that approach can be improved. I'll use an example. Consider a software development project with six developers. One of the developers is also the team leader. The team leader both develops code himself and manages the other developers on the project. This example is somewhat based on a project earlier this year where I was the team leader with around six developers. Although this example refers to Java and JUnit, it applies to the general issue of code and formal code testing.
In the traditional model described above, all six of the developers would both write code and write JUnit tests for that code. I can immediately see drawbacks to that approach.
- Many developers at the code. That means more communication links, more coordination, more management to do. With more developers the team leader has to spend a lot of time keeping track of who is working on what, and managing the dependencies, and making sure people who depend on one another understand what the other person is expecting.
- When the team leader spends a lot of time managing, then he has little time for writing code. This is generally a bad thing. Typically a developer is made a team leader because he has shown technical ability in the past. If the better developers spend their time not programming and the lesser developers write most or all of the code that's not good. There's probably an antipattern around this. You want the most capable developers to write as much of the code as possible. It's hard to write code when you're managing people.
- With split responsibility of both code and JUnit, the JUnit necessarily cuts into the time a developer can spend writing code and informal scratch testing. The code is the most important product of a development project. I'm suspicious of activities that compete with and distract from writing code.
- Lack of visibility. If a developer writes some code, then writes some JUnit, and the code builds and the JUnit runs through successfully, well he's done right? I guess so, things seem to be done. However the developer has worked in isolation. You don't really know until you pull the pieces together if he did a good job with the code and the JUnit. After all if someone writes bad code, then the JUnit will likely also be low quality and fail to detect the problems in the bad code.
Well I think there may be a better approach than that described above. Instead of having everyone do both code and test, split the development team into two. Have a code team and a test team. The code team does all the code. They should do informal scratch and feature testing as they go, but not formal JUnit testing. The testing team does the formal JUnit tests on the code the code team writes.
Using the example above, the team of six would be a three person code team and a three person test team. The original team leader is the subteam leader code team and remains the overall team leader. One of the JUnit test team developers is appointed subteam leader of the JUnit team.
I can immediately see benefits to this.
- There are now only three people at the code instead of six before. This is good because there is less communication and dependencies between developers. There will be less misunderstandings and disconnects. There is less communication and synchronization overhead. The code development should go more smoothly.
- With less code developers, the team leader will spend less time managing and coordinating individuals. Thus he can spend more time writing code himself. This is good because typically the team leader is also one of the better programmers. You want your good programmers to spend as much time as possible programming.
- With a separate JUnit team, the management burden can be partly offloaded from the overall team leader to the JUnit subteam leader. This frees up the team leader's time to focus on writing code himself and managing the more important code project.
- There is more focus. The code people are not distracted with JUnit and are able to spend more time on the code development. The JUnit people are able to focus on doing a good job testing instead of just having it cut into more important code activity.
- Most software development sites aren't like Google. Instead of programming superstars everywhere there's more of a mix of strong developers, reliable middle class type developers, and people who tend to require more supervision (you need to keep this third group to a minimum, max 10% of developer head count, or you're in big trouble). By splitting the team up you can put the most capable people on the code team. Thus assuring a higher quality of delivered code. The rest can do the JUnit. If they do a mediocre job it doesn't really matter since the code will be solid anyway.
- Do you still need six people? With less synchronization and coordination among individuals, and the team leader able to spend more time programming, I don't think you do any more. You can now get the same job done with higher quality and the same schedule using only five people instead of six. Two JUnit people will be enough to do a good job. So that's a financial benefit to the company, being able to get the project done with five people instead of six in the original schedule.
- Finally, this way actually forces a real budget to be allocated for the JUnit. I've been on projects where the schedule was overambitious, and we were just told to "fit in" the JUnit on top of doing the code, even though the schedule didn't really even have enough time to do a proper job of the code. You can guess how much JUnit got done on those projects and the quality of it. By allocating a proper budget and resources for JUnit, it is much more likely to actually be done and a better job will be done with it.
Sounds good to me so far. Of course there are some hazards to this type of plan. I can see some political type problems from this. Some people are suspicious of change in general so a departure from established ways may meet resistance just because it is a bit different.
The other issue may be in the assignment of developers between the code and JUnit teams. Some people might not like the idea of developers being on a software project but being "relegated" to unit testing and not writing production code. One way to deal with this is to mix it up over different projects and have developers be code team on some projects and JUnit team on others. Or just deal with it and use it as an incentive to the mediocre developers to improve themselves to get on the code teams.
I think it's worth trying.
Thursday, October 27, 2005
Cutdown day
Update August 2006, survived another one.
---
After a tough quarter, the expected layoff happened at the office. I'm glad that I was fortunate to survive this downsizing.
I've never actually been downsized in high tech. That is something of a rarity in this business. I've managed to survive quite a few though. Here they are that I can remember.
I've been pretty fortunate to survive that many. For some reason I've wondered what it's like to be fired. What does the manager actually say to you. Then what happens? Still, I don't really want to find out first hand.
In my career when it happens it's been kind of like with Syme in 1984. People just kind of disappear during the day and are never seen again. They are generally spoken of little afterward, however they don't become full unpersons.
It was expected that this action was going to happen. We've preannounced twice in the last year, so something had to give.
When a layoff is imminent or has just happened, it makes me think of a story I heard about a guy who was a programmer for Corel. I lived in Ottawa around 1994, and at that time Corel was high flying. It seemed they could do wrong.
Well fortunes can change quickly in high tech. Corel made some strange forays into WordPerfect and Linux. Add in an aging main product line and tough competition from Microsoft. By the early 2000s Corel was struggling.
After another tough quarter, it was known that there was going to be a big layoff in the Spring for the company to survive. Now "Bill" was a programmer at Corel. He'd been there through the high flying times and was still around as the company struggled. For Bill, he'd had just about enough of life at Corel. The struggling, the abrupt changes in direction, the increasingly dysfunctional environment took their toll.
So with the big layoff coming Bill realized that he wanted to be fired. He figured he'd be better off after it happened.
Yup, Bill was looking forward to getting laid off. Severance, followed by a UI summer. Plus he wouldn't have to work at Corel any more. He was going to relax, hit the beach, not even think about going back to work until the NFL kicked off in September.
In the last three weeks Bill cut back from his regular 45-50 hours a week to a straight 40 hours a week. That was Bill's signal to managment that he wasn't going to fight to save his job and they should let him go.
Finally the expected cutdown day arrived. But then something unexpected happened. Bill survived the layoff. Well that was disappointing. Instead of severance and UI like many of his co-workers, Bill got left doing extra work to cover for those who were now gone. Plus the company was now struggling to survive so he had to work under all that uncertainty. The environment at Corel was even more unenjoyable after the layoff.
So that's where I came up with the term Corel'ed. That's when the big layoff is known to be coming. You're looking forward to getting fired because you think you'll be personally better off after you're gone, and you won't have to work at the crummy old company any more. But when the layoff does happen, you unexpectedly survive it. Then you're unhappy to survive it because you still have to work there and you miss out on the severance and other stuff you were looking forward to.
I don't know what happened to Bill after he got Corel'ed. Perhaps he's still working there.
---
After a tough quarter, the expected layoff happened at the office. I'm glad that I was fortunate to survive this downsizing.
I've never actually been downsized in high tech. That is something of a rarity in this business. I've managed to survive quite a few though. Here they are that I can remember.
Date Company
======== =======
Jul 2000 xwave
Jul 2001 xwave
Oct 2001 Core Networks
Mar 2002 Core Networks - huge one
Sep 2002 Core Networks
Apr 2003 Core Networks
Aug 2004 Core Networks
Oct 2005 present job
Aug 2006 present job
Oct 2007 present job
I've been pretty fortunate to survive that many. For some reason I've wondered what it's like to be fired. What does the manager actually say to you. Then what happens? Still, I don't really want to find out first hand.
In my career when it happens it's been kind of like with Syme in 1984. People just kind of disappear during the day and are never seen again. They are generally spoken of little afterward, however they don't become full unpersons.
It was expected that this action was going to happen. We've preannounced twice in the last year, so something had to give.
When a layoff is imminent or has just happened, it makes me think of a story I heard about a guy who was a programmer for Corel. I lived in Ottawa around 1994, and at that time Corel was high flying. It seemed they could do wrong.
Well fortunes can change quickly in high tech. Corel made some strange forays into WordPerfect and Linux. Add in an aging main product line and tough competition from Microsoft. By the early 2000s Corel was struggling.
After another tough quarter, it was known that there was going to be a big layoff in the Spring for the company to survive. Now "Bill" was a programmer at Corel. He'd been there through the high flying times and was still around as the company struggled. For Bill, he'd had just about enough of life at Corel. The struggling, the abrupt changes in direction, the increasingly dysfunctional environment took their toll.
So with the big layoff coming Bill realized that he wanted to be fired. He figured he'd be better off after it happened.
- If he was sacked he'd get severance. Severance cash in hand today was better to him than underwater stock options which might never get into the black in the future.
- It was Springtime in Ottawa. Ottawa is nice in the Spring. After he got laid off, Bill could go on unemployment insurance (called UI in Canada) . That meant Bill would get to have a "UI Summer". In Canada the UI summer is an unusual and coveted thing. Most people get to do this never, or at most just once.
- Bill picked up A list tech skills working at Corel. Plus he was a good worker and would have good references. He knew some people at other companies who would be willing to help him out. He wasn't concerned about being able to find another job after Corel.
Yup, Bill was looking forward to getting laid off. Severance, followed by a UI summer. Plus he wouldn't have to work at Corel any more. He was going to relax, hit the beach, not even think about going back to work until the NFL kicked off in September.
In the last three weeks Bill cut back from his regular 45-50 hours a week to a straight 40 hours a week. That was Bill's signal to managment that he wasn't going to fight to save his job and they should let him go.
Finally the expected cutdown day arrived. But then something unexpected happened. Bill survived the layoff. Well that was disappointing. Instead of severance and UI like many of his co-workers, Bill got left doing extra work to cover for those who were now gone. Plus the company was now struggling to survive so he had to work under all that uncertainty. The environment at Corel was even more unenjoyable after the layoff.
So that's where I came up with the term Corel'ed. That's when the big layoff is known to be coming. You're looking forward to getting fired because you think you'll be personally better off after you're gone, and you won't have to work at the crummy old company any more. But when the layoff does happen, you unexpectedly survive it. Then you're unhappy to survive it because you still have to work there and you miss out on the severance and other stuff you were looking forward to.
I don't know what happened to Bill after he got Corel'ed. Perhaps he's still working there.
Thursday, September 22, 2005
Google desktop search
If you don't have this then get it. It's great. No more wasting time on interminable Outlook "advanced" searches or Windows explorer file searches. Although in win explorer I was able to turn off the stupid dog, I couldn't fix the rest of that horrid user interface, nor make it any faster. I was surprised this week at work to learn that quite a few people aren't using this.
You can get it at http://desktop.google.com.
Also on Google, I've got a stack of Gmail invites if anyone is interested in getting Gmail. Go to my profile and click on the e-mail link and I'll give you a Gmail invite.
You can get it at http://desktop.google.com.
Also on Google, I've got a stack of Gmail invites if anyone is interested in getting Gmail. Go to my profile and click on the e-mail link and I'll give you a Gmail invite.
Subscribe to:
Posts (Atom)