I’ve noticed that I can get through my email in half the time if I use my BlackBerry rather than my computer. Email using my computer takes about 3 to 4 hours of my day, so using my BlackBerry is a huge time saver.
So why is it faster to do email on my BlackBerry than a computer?
For one, firing up my Windows Vista laptop sure ain’t quick. Even coming out of sleep mode, this can take a few minutes. My BlackBerry is always on, ready to go as fast as I can reach in my pocket.
Two, I’ve got about 1.5 GB of email, and I receive about 150 emails a day, so opening Outlook can take a while. Other actions, like deleting messages, switching to the next message, etc… also take a second or two and seem to get worse as my mailbox grows over time (I know I can archive things, but I tend to use past mails every so often). Flipping to email on my BlackBerry takes about a second. Deleting multiple messages is fast and easy to do by selecting multiple messages. Opening messages is instant. Even viewing attachments is quick on my Verizon BlackBerry Curve.
Thirdly, typing on a BlackBerry is almost as fast as a computer for me. But because its a BlackBerry, I somehow feel it’s ok to much more brief in my responses… like its a text message. I make use of common acronyms like TY or IMHO (or WTF) that I wouldn’t normally do in an email I’d type out from my computer. Maybe it’s just me, but I feel like its ok to use text speak in email from a BlackBerry but not from a email created on a computer. Saves alot of typing and time!
If a particular email message requires extra attention, or a very long response, I will mark the message as not opened and take care of it from my computer later.
So maybe this approach can work for you? If you have a BlackBerry, or any smart phone with a real physical keyboard (I don’t think a touch screen keyboard will be fast enough), consider using this as your primary email device.
Until recently, most development shops I’ve been a part of have performed software releases to production after hours, typically late at night. The conventional thinking is that releasing off hours minimizes the risk of disrupting users if there are bugs in the release that were not found in QA or if the web site must go down during the release process.
Over the past few months, we’ve tried something different. We release once every 3 weeks or so. The day before the release, the dev team works long and hard to ensure that QA is completed, all bugs are fixed and verified in QA environments. Then we all go home, get a good nights sleep, then start the release first thing in the morning when everyone is back at work. Our releases usually take about 45 minutes, but some can last several hours if we are pushing a lot of configuration changes. We rarely need to bring production completely down for a release, as we can shift load and take clusters out of service using a load balancer.
Reasons why I’ve come to really like this approach:
- If you release at the end of the day, often times not all your development staff is around. I’ve seen this many times where developers don’t stick around because they don’t have any code going in the release. But, that doesn’t mean you might not need that particular developer if something goes wrong, especially if you have to rollback.
- First thing in the morning, your development staff is fresh and ready to go. If you release at then end of a long day, and something bad happens in production, it can be brutal to try to figure it out. It’s like working 12 hours, then someone handing you a calculus problem. Good luck. The developer is much more likely to fix the issue quickly and correctly early in the day.
- Releasing in the morning also makes it easier to observe the production environment for a time after the release. A production issue might not be apparant right after the release, it may take an hour or two (ahem, a queue backing up). Releasing in the morning allows development to keep an eye on production during the day and make sure everything is running smoothly.
Releasing in the morning might will not work for everyone. If your production environment has so much load that it can’t afford part of the cluster going down, then this isn’t possible for you. But if you can technically do it, I suggest you give it a try. I’d love to hear back from others about their experiences with this.
The one position I continue to have trouble hiring for is QA. I manage a development team of 8 others. 5 Ruby on Rails developers, 2 Java and C# developers, and a system administrator. My team is quite sharp. Finding a QA person that can fit in to a Internet Startup Agile Development team has been quite a challenge. And if you are a small company, like mine, you only get one person for this role. The person you hire needs to be a rockstar. No budget to have multiple people.
So what makes a great QA person? Well I believe you should look for the following qualifications:
- QA Vocabulary. Nothing is more annoying than a QA candidate who can’t tell me the difference between white box and black box testing. There is a good set of software QA terms here http://geekswithblogs.net/srkprasad/archive/2004/06/02/5795.aspx and here http://www.aptest.com/glossary.html
- QA testing skills. I usually take a story that is ready for testing and have the candidate take a shot during the interview. I find it useful to leave the candidate alone while they do this.
- Resumes that have grammer/spelling errors… trash ‘em.
- Extension of the product manager. I don’t get to review every story that is developed and release, but the QA engineer does. So your QA person is an extension of your product people/person. It is critical the QA person get a feeling for what your product manager likes and dislikes.
- Hard Ass. You need to make sure that your QA candidate can stand up to manipulative developers that try to convince the QA person to “it’s not a bug, it’s a feature”. The QA person needs to not roll over everytime they are steamrolled.
- Flexible schedule. That’s right, the QA candidate needs to be comfortable with working long days and nights, especially just prior to a release.
- Relevant experience. Hiring a QA person for web testing that only has tested windows clients is not a good idea. You are a startup, you need results fast. Your not in training mode.
And of course, finding this person sure isn’t easy… so good luck!