Category Archives: Uncategorized

Thank you, Robert Voit, creator of JASC Paint Shop Pro

Robert —

In the early to mid-90s my hobby was making video games of various sorts with my friend Jesse. Our tools were Recreational Software Designs Game-Maker 2.0 and your creation JASC Paint Shop Pro (PSP). I discovered both in a software mail order catalog and purchased them with my lawn mowing cash. We used PSP to design our title screens mostly.

I had purchased the shareware version of PSP, which came with a 30-day trial period. I discovered that if I simply uninstalled and reinstalled PSP, we would get another 30-days of free use. But, my conscience didn’t feel good about my discovery. It was stealing–plain and simple. I sent JASC a brief letter explaining how we were using PSP and asking for permission to continue using it. I figured, the worst that could happen is that you could say “no” and I would have to save up to buy the full version. The best that could happen is that you would say “yes” and we would be back in business.

To my shock and surprise, you sent me the following reply:

Robert Voit JASC Paint Shop Pro

You included a boxed version of PSP with your letter. I couldn’t have been more surprised or excited. It’s still one of my favorite childhood memories to this day.

Only a year or two later, Jesse and I stopped making our games. The limitations of Game-Maker were quite real, and something bigger had arrived: The World Wide Web.

I quickly taught myself HTML and continued to use PSP as my image editor–even later paying for upgraded versions. (Version 6 was my favorite!) I made websites on top of lawn mowing to earn cash throughout high school and college, which helped pay for school. The experience set me up to be a career website and web app builder (see PC World, September 2006, page 37). I couldn’t have done it without PSP. And I always liked it better than Adobe Photoshop, which I got to use during a few summer jobs.

Your kindness taught me three things: honesty and hard work are rewarding–both spiritually and materially–and that it’s fun to surprise and delight and help those whom you can. It was no surprise to me years later to learn that JASC was acquired by Corel. Your life’s hard work, honesty, and kindness rewarded you, and I couldn’t have been happier for you.

Thank you for teaching me some valuable lessons and your gift that summer. I’m grateful.

Although Jesse and I never officially shipped a game to market, I dug up one of them for old time’s sake and to finally follow through on my end of the deal. Here’s a video of Xylon.

Thanks again,


P.S. For folks interested in the Paint Shop Pro story, read this great Motherboard article.

My Personal Process

Over the years I’ve blogged about personal productivity–it’s one of the dimensions I enjoy optimizing to get more done at work, and people think I’m good at. This post is what I wish I had at my disposal when I starting my journey down productivity.

A real challenge with reading advice from literature can be how to put things into practice in the real world. I always appreciate it when experts describe or show examples, especially of tools and techniques. This my attempt at doing just that.

In addition to following tried and true advice, like inbox zero, saying no, unsubscribing from worthless email lists, the two-minute rule, trash whatever you can, and the like, here are the tools and techniques I use today:

Individual Tasks

First, I must point out that these are for tracking my own items–not items that should be visible to a broader group. I put those in formal systems like Asana, Clubhouse, etc. That disclaimer aside, here is how I track my personal tasks:

  • Urgent tasks I schedule on Google Calendar as a time-bound event. Stephen Covey would be proud.
  • Future-urgent or top-of-list important items I put in my Google Calendar Tasks because I can place them on specific dates I suspect I will complete them on. Yes, when I’m busy there’s some drag-and-drop from day to day or week to week.
  • I manage private text files for “_Me”, other people (e.g. “Jim”), or departments (e.g. “QA”) to track open action items, whether committed to or future, possible work. I use indentation or bullets to nest subtasks. I find the relative lack of structure much easier to manage than something like Asana or other task managers. Depending on my connectivity needs, these have been text files on my computer, Google Docs, or Evernote notes. I only ever use one tool during a season of life. I never try to use multiple text editing platforms for tasks.


  • I BCC whenever sending an email I need a timely response to and yet don’t trust the recipients to reply by a specific date.
  • I immediately star sent emails that require a reply but that are not time-sensitive. If someone responds later and the thread is effectively closed, I un-star it before archiving. I sift through these starred messages periodically to unstar items that are no longer relevant, were in-fact resolved. If it is still unresolved, I re-email people nudging them to respond.
  • If I receive an email I don’t want to deal with at the moment, but may be interested in reading several weeks or months later, I will forward it to and archive it immediately.
  • I set up GMail filters to label and skip the inbox for any system-generated messages from apps like GitHub, Clubhouse, or Slack. I then view them at particular points in the day in batch. I additionally have GMail automatically archive and mark as read emails that do not necessitate an action but may be a helpful reference in the future, like receipts from vendors.
  • I schedule a 60-minutes recurring calendar event to get to inbox and Slack zero at a time that makes sense for my schedule (9-10 am). Others can’t schedule meetings during this time. This recurring event ensures I have space to get to inbox zero or as close as I can.

Slack/Group Chat

  • I keep up with it as much as I can, and I ensure others are following Slack etiquette so that we’re not suffocating our own company. Sometimes it’s more appropriate to send an email or hop on a voice or video call.
  • Because I keep up with Slack, I can disable most of its notification settings to focus on the work at hand.
  • I ensure my channel list only shows ones with unread messages for easier catch-up and use my keyboard to jump between channels.
  • I leave any channels I am not deriving value from or contributing value to. I trust someone will @ mention me if I need to rejoin. I left and rejoined some channels a few times in a single day this year. The mute feature is too aggressive; it doesn’t notify me if someone mentions me again in the channel.
  • When I need to get deep work done, I ignore or quit the app. (I can ignore it since I turned off notifications.)

I hope this is helpful for others! Please comment if you need clarification on any of these tactics or have your own to share.

How Well Do You Treat Your Sysadmin/DevOps/Ops Engineer?

Let’s be honest, systems administration, whether working with bare metal or in the cloud, is often worse than a thankless job. If the site is up and running, you’ll get no thanks. If it goes down, you better get it back up quickly…and then explain what just broke. If you need to schedule downtime, well, you have to schedule that for 4 AM on a Saturday and still show up chipper on Monday.

I’ve seen too many ops engineers work themselves to the bone fire-fighting, scaling, and migrating the foundation on which entire businesses stand as if in a full-on marathon…sprinting. They get no chance to breath, normalcy, or arrive at the autonomy or purpose we all seek to earn our work.

Not on my watch. Here are the practices we employ at LearnZillion to make sure our environment is a livable, enjoyable, and rewarding place to be an ops engineer.

We maintain a sane software engineer to ops engineer ratio. I recently talked with an ops engineer who was responsible for the systems behind the company’s 60-person software engineering team. I wish this was an extreme situation or at the least sustainable, but it’s not. This isn’t the first time I’ve heard it either. Whether the software engineers are great or sucky, you’re in for a rough ride when the ratio is stacked against you. Don’t let this happen. Systems take serious work to build and maintain. Don’t ever let an employee drown in work.

We deploy during working hours whenever possible. Our engineering team practices no-downtime, continuous delivery within a time window that allows for issues to shake out before staff go home for the day or weekend. We typically ship Monday through Thursday 8 AM to 3 PM. If a completely shippable deliverable misses that window, we often wait until the next reasonable workday to deploy. We don’t want anyone, in software or in ops, paged while out of the office. It’s a terrible way to live. Strive to keep work at work.

We have reasonable maintenance windows. It took a bit of Google Analytics investigation and some convincing inside the company, but our maintenance window starts at 8 PM EST when we need one. Will this affect users? Yes. Is this the ideal time for users? No. Do we want to save our ops engineers from burnout, sleep deprivation, and insanity, and allow them to live life? Yes! Since we practice continuous delivery, maintenance that requires our site to be offline is rare, so it’s a reasonable trade-off.

We assume it’s a software issue until ops is proven guilty. Too many people outside an engineering department or even insufficiently experienced software engineers assume the computers are to blame when things go down (guilty!). Operations issues happen, but software change or software engineering flubs are usually at fault. We make sure our issue escalation process assumes this reality. Our ops engineer is our last line of defense, not our first.

We make space for proactive ops engineering. Imagine you’re in a sinking ship and you’re told to keep bailing water, even though there’s a plug and hammer at your feet that will stop a source of the leaking. That’s what it’s like to be deprived of space to make your work life better. Nowadays, software engineers are given space to pay-off tech debt. Not only does this make it easier for them to ship features in the long run, it also makes their working environment less toxic. Help your ops engineers make time for proactive work. Tell your software engineers to endure that less important but painful pain they’re complaining about just a little longer so that ops gets the space it needs to address the top issues on its list too.

We check-in regularly. Ops engineers are a part of our standard kick-off meetings and stand-ups. They have an equal voice at the table. They serve the needs of the business like the rest of us, but they are not subservient. We connect out-of-band to see how things are going too.

We pay them competitively. We send them to meetups, conferences, and training just like software engineers. We let them go to the dentist when they need to. We praise them for their work. We treat them well. Do you?