10 Great Resources For Remote Work

I’ve been keeping a small list of resources for people that are trying to work remotely even if just temporarily during this current pandemic. Below are a few links to things that are potentially helpful even if you’ve been working remotely for a while:

  1. Treehouse has made their tutorial “How To Work Remotely” free for everyone.
  2. If your office and desk are less than inspiring, Dwell has a beautiful set of 25 home office designs that are fun to peruse.
  3. LinkedIn has a great set of online courses for learning to work remotely. Their “Executive Presence” video is particularly good advice for anyone when preparing for conference calls.
  4. Remote: Office Not Required is a great, short read by the creators of Basecamp. It provides some good backstory and explanations about the values of remote work.
  5. Atlassian, one of the largest and most famous 100% remote companies,  has a great introduction to remote work.
  6. Greg Storey at InVision has an amazing curated list of remote work articles and resources. He is constantly updating the list so make sure to check back frequently.
  7. The authors of Thinking Remote have an email series that you can sign up for. It’s a fairly thought-provoking series and is limited in length so you won’t get tired of it.
  8. They also have a great podcast series titled 21st Century Work Life and leading remote teamsI’ve only recently started listening to this, but I really enjoy it.
  9. Collaboration Superpowers has a fantastic newsletter about working and managing remotely. (Also, don’t miss their really great guide for meeting facilitation!)
  10. Inc. has compiled a list of companies that are making their remote work tools free temporarily. If you’ve been curious about some of the paid teleconferencing tools, now is a great time to try them out without any cost.



Slack Tricks for Novices

The past few weeks have been insane with Corona Virus/Covid-19 outbreaks causing havoc around the world. In particular, there has been a sharp uptick in companies asking their employees to work from home (WFH) even though the practice is new or untested for many of them. With so many companies suddenly thrust into this new WFH reality, I have to imagine that there’s also been a huge jump in Slack users. As I’ve previously mentioned, Slack has been one of our core tools at Silverpine for quite a while and as such, we’ve become fairly adept at using it.

For anyone that is new to Slack and wants to jump start their productivity with it, here are a few tips and tricks that I’ve used to help me be more productive and have a little fun while at it:

1. Quickly give someone kudos or feedback by adding a reaction to their message which adds a little emoji under their message.

Screen Shot 2020-03-09 at 4.01.47 PM.png

If someone has already added an emoji and you like the emoji they used, click on it and the count of that emoji will increment similar to “likes” on Facebook.

2. Quickly reply to a message with a ¯\_(ツ)_/¯ shrug by replying with /shrug

3. When you need to focus on something, go into Do Not Disturb mode by clicking on the bell icon and disabling notifications for the amount of time you specify

Screen Shot 2020-03-10 at 9.52.14 AM.png

4. If you’re part of a channel that you can’t leave but is just too chatty, you can mute it. You will still be able to see activity, but you won’t receive notifications and you won’t see the little dot indicating new messages. (I’m a member of quite a few Slack groups and those dots drive my OCD crazy!)

5. To add some spice, try adding a few custom emoji. For example, the Silverpine Slack will insert :blazers: whenever someone types :blazers: into a reply.

6. Don’t be afraid to leave channels that aren’t helpful to you. I promise, they’ll get by without you.

7. Star (aka favorite) both people and channels that are important to you so they appear at the top of your list.

8. Pin items that are important or might be important so you can easily find them. (Pinned items remain on the free plans even if they are too far back in the history to show up in a search!)

9. Try using /giphy in a reply if you want to find a fun/snarky response to someone. Don’t overdo it though or your admin will likely disable it.

10. Use /collapse in a channel to hide the annoying GIFs that your teammates post.

11. Add @here anywhere in your message to notify everyone whose status is Online and is a member of the channel. This won’t send notifications to offline users or anyone that has set their status to Do Not Disturb.

12. Add @channel anywhere in your message to notify everyone who is a member of the channel. This will send notifications to the members that aren’t online as well. Try hard not to overuse this and consider using @here instead.

13. If you are in a channel with many people, consider taking a topic out of the channel and into a direct channel with the person you want to chat with.

14. Take a trip over to the Slack App directory and see if there are any third party integrations that could help or would be fun. In particular, make sure to check out the bots directory. I’m particularly fond of the survey app integrations like SurveyMonkey.

Slack is full of all kinds of tricks and tools to help people communicate better. If you have a tip or trick that I didn’t include, definitely drop a note in the comments and I’ll publish an updated list.

Building Community with Slack

Whenever I talk to people about being a remote company, they will often ask how we replicate the “water cooler conversations” that happen organically in a standard office setting. (Sidenote: I’ve only ever worked at one company that had an actual water cooler.) The conversations they are referring to are the ones where employees talk about their families and their hobbies and many of their non-work interests. They also might talk about things that are happening both inside the company and outside the company that are tangentially related to their jobs. Sprinkled into those conversations are often times some of the “outside the box” brainstorming and problem solving that usually aren’t factored explicitly into employees’ schedules.

I believe that when people ask about replicating “water cooler conversations”, what they are really asking about is how to build a sense of community and trust among employees who are rarely in the same physical location. How do they create an environment where people feel like they know each other well enough to share a crazy, hair-brained idea? How do they trust each other well enough to talk about a potential pitfall that nobody else has noticed yet?

I don’t purport to have all the answers, but I can tell you that at Silverpine, we lean heavily on Slack to help build trust and community on a day-to-day basis. If you don’t know what Slack is, it is a software communication tool that feels a little like group instant messaging, but has a few differences that increase its utility immensely for people and groups who aren’t co-located. (I’ve also listed out a number of our regular tools that we use for remote work here.)

To help build a sense of community, there are a few specific approaches that we employ in our Slack instance:

  1. Create channels that serve an explicit, well communicated purpose
  2. Have a well defined strategy for populating channels
  3. Archive unused, unneeded channels to limit confusion
  4. Model the behavior you want to see

Because we are a technology company with heavy dose of design, some of the ways that we utilize Slack won’t be applicable to everyone, but I believe that in general, these 4 strategies can be applied to any organization that uses Slack.

So how exactly do we use these strategies?

Create Channels With Purpose

Our strategy for Slack channels is heavily influenced by our staffing model. We employ a decent number of sub-contractors in addition to our employees so we have a few categories of different channels.

General Purpose Channels

We have two general purpose channels that are work related: “#general” and “#internal”. In the #general channel (which is a default Slack channel that every user gets added to), content that is posted is generally restricted to work-related things that apply to everyone whether they are an employee, a contractor, an engineer a designer or whatever role they might have. An example of that might be an announcement about a project launch that both employees and contractors worked on. The second general purpose channel is our “internal” channel which is only for employees. This is sort of the inner circle where we talk about things like health insurance policy changes or company strategy. If you want to know more, you’ll have to apply and join us!

Project Specific Channels

This is a very common strategy and somewhat obvious, but for every project that is active within our company, there is a corresponding Slack channel populated with all the relevant project members. This ensures that the majority of the conversations about a particular project can all be found in one place. It also makes it clear where someone needs to go if they need to talk about their work. Again, this is a common strategy, but it’s definitely a good one.

Topic Specific Work Channels

We also create channels created for conversations about tangential related work topics, but that aren’t necessarily for a specific project. For example, since we build iOS and Android apps, we have a channel dedicated to iOS development and a channel dedicated to Android development. What is discussed in these channels isn’t specific to any particular Silverpine effort, but it’s a place where we can cross-pollinate ideas and have conversations about some of the building-blocks of our business. It’s very common for our developers to both ask for suggestions on solving a problem but also to post interesting solutions to things they have learned.

Non Sequitur Channels

Finally, we have a few channels for topics that aren’t related to projects and aren’t really related to work at all that I refer to as “non sequitur” channels. For example, we have the default #random channel, but we also have a #basketball channel where a few of us who enjoy the sports-balls discuss matters of the day. I am part of other Slack communities that have a number of non-work channels, like #photography and # travel. My only caution when making hobby and non-work channels is that it’s very easy to overdo it and end up with a list so large that it paralyzes would-be communicators. It should always be clear what channel someone should use if they feel like talking and having too many channels can erode that feeling of comfort.

Archive Unused Channels

Some administrators treat Slack as immutable and that channels, once created, should exist indefinitely. I strongly disagree with that for the same reasons why I feel it’s important to have a limited number non-work channels.

When a project wraps up, we keep the project Slack channel around for a couple months and then archive it. We will generally send a last message to the @channel to make sure everyone is ok with archiving it, but usually, if nobody has posted for a few months, it’s a good indicator that it’s time to wrap it up. (If you have a paid plan, you can always unarchive it if needed, but in practice, I’ve never had to do this.)

Second, if you have created non-work channels that aren’t being used, that’s ok! Just admit that people might not care about whatever the topic of that channel is, and archive it. As I mentioned before, having too many choices can lead to paralysis and erode the very trust you’re trying to build.

Be Smart Populating Channels

In Slack, there are a number of ways that people can become a member of a channel. But the most important time to think about adding people to a new channel is at the time of creation. When you invite someone to a channel when it is first created you are communicating to them that you feel their voice is valuable, that they belong. If you wait for people go search the channel list and join on their own, not only do they miss out on some of the earlier conversations, but they can sometimes feel like they are outsiders trying to break into a clique.

Also make sure to take a few extra seconds when you are creating the channel to decide if the channel should be public or private. This can make a big difference in terms of both information overload (if users have too many channels available to them to join) as well as that sense of belonging. If you stumble on a channel that you weren’t explicitly invited to, it’s hard to not feel somewhat left out.

Model Behavior

Finally, perhaps the most critical element in building community via Slack is to model the behavior you want to see. If you want people to engage and communicate regularly, show them how you do that. If you want people to talk 1:1 as well as in group channels, make sure you’re talking to your team in the direct channels.

Also, be smart about using channel @mentions. Don’t be afraid to use @here and @channel mentions, but be aware of the dangers of overuse. They are powerful in that they notify large groups of people with a few keystrokes, but if you used too often, it can lead to people ignoring channel notifications altogether.

Similarly, try to get in a habit of using someone’s @handle rather than just their name to make sure they know they are being talked about. For example, don’t type

“I’m not sure about that, but we should probably ask Jon what he thinks”

but instead write

“I’m not sure about that, but we should probably ask @jon what he thinks.” 

And whatever you do, don’t underestimate how much other people on your team look at how you are using Slack, yourself. If you are frequently joking, you will find that much of your channel content will be filled with joking. If you frequently write simple, terse comments, the rest of your team will consciously or unconsciously mimic your behavior. And most importantly of all, if you don’t communicate often, your team will reciprocate.




An App Budget for America

If you’ve been paying any attention to the news this week, you will of course know about the major snafu in the Iowa Democratic Caucus. It is now largely being blamed on what appears to be a bug in the app developed by a for-profit third party company. I’ve been reading the news around this with quite a bit of interest both because I’m interested in our democratic process, but also because I have a small bit of idea what the app developer is going through. I’ve been an engineer on apps since the early days of the Palm Pilot, way back in 1999. (They weren’t even called apps back then!) As such, I’ve been on hundreds of 1.0 product launches, many of which have been amazingly successful, but I’ve also had my share of painful and embarrassing failures so I certainly cannot throw too many stones from within my glass house.

However, the thing that really caught my attention was the reported development cost of the app. It has been widely reported that the Iowa Democratic Party paid the app developer $63,000 for this product. In particular, I noticed more than a few news outlets reporting that it was a large sum of money. To an individual, $63,000 is certainly a lot of money but in the context of an app development project, it is a very meager, thin budget.

As app developers, we don’t often talk about all the costs that go into a platform like this, but given the gravity of this app, I consider this to be far too small of a budget. If you’ve ever wondered what goes into developing an app and how much it might cost, I think this is a great opportunity to break it down. If we are following any sort of sane development model, we will do the following:

  1. Gather the user and technical requirements of the platform
  2. Design the user interface and user experience so that precinct captains who are going to have to use the app can do so with very little assistance
  3. Develop the backend server and database that the apps will talk to
  4. Develop some sort of dashboard or web interface for retrieving the data that has been uploaded by the apps
  5. Develop an iOS app
  6. Develop an Android app
  7. Test the apps and server in a controlled quality assurance environment
  8. Deploy the apps and server to a production environment
  9. Have a beta test period to validate the system is operating correctly and that users can download and utilize the product
  10. Launch the product!

Given the above list of items needed to create the platform, we can reasonably estimate that, at a minimum, the team working on this should have consisted of an iOS app developer, an Android app developer, a server developer, a designer, a project manager and a quality assurance engineer. For an app like this, it’s still a pretty bare bones team of six people.

Now that we have the staffing established, let’s figure out how much time these folks are going to be working on the project. First, we need to establish a rough timeline. For an app like this, I would roughly estimate that it would consist of a month of up front work defining the requirements and interface followed by 2-3 months of active development, followed by at least 1 month of quality assurance. At that point, the app is hopefully well written and tested and ready to move to a beta test period which should, at a minimum, take 2-4 weeks. In the end we should have a project timeline that is going to run at least 5-6 months.  Now we need to figure out how much time each person on this team is going to spend working on this product.

Let’s start with the project manager. In general, the project manager is going to be the source of continuity through the entire project. They are going to work heavily up front with the client (in this case the Iowa Democratic Party) and the designer defining the requirements and translating those requirements into a user interface that will meet the needs of the diverse population that will use this app. The users of this app are going to have an incredibly broad range of technical sophistication so it will be important that the UI/UX be done well. The project manager will then transition to part time during the development phase as they coordinate the many moving parts of the project. As the development phase wraps up, they will then re-engage as the product goes into the testing, deployment and beta testing phases. Given our assumptions above, they would likely spend about 1 month working with the client and the designer up front to define the product, then transition to approximately 1/4 time during the development phase and then transition to 1/2 time during the testing phase, followed by a full time engagement during beta testing. Roughly speaking, the project manager would need to be budgeted for about 3.25 months over the course of the project.

While the project manager’s involvement is a bit dynamic, the designer is a little easier to estimate. They will likely spend the majority of their time at the beginning of the project creating the user interface and user experience for the app, and then they will spend a little time during the quality assurance phase ensuring that their initial designs were successfully translated to the product. Generally speaking, the designer should be budgeted for about 1 month during the project.

Next up is the server/database developer. This one is a little more difficult to estimate since it is unclear where the caucus data needs to go once it’s uploaded, but at the very least we know that it needs to provide login and authentication functionality as well as data storage and reporting. In general, the server developer will need to define the interfaces that the apps talk to as well as provide development, test and production environments for the different phases of the project. As a conservative estimate, let’s assume that the server developer works for approximately 2 months during the course of the project.

The app developers on the project will obviously need to be fully active during the primary development phase, but even more importantly, they need to be fully engaged during the testing phase and at least partially available during the beta testing phase. As a conservative estimate, we can budget them for approximately 3.5 months of the project. Since we need an iOS and an Android app, we need to budget a combined 7 months for the project.

Finally, we need to consider the QA engineer’s contribution. In a perfect world, the quality person is a team of people and they are at least partially engaged from day 1 of the project. However, we will employ a conservative estimate and budget only a single person for just the testing phase of the project, which is 1 month.

So with all of that out of the way, we can come up with the following time estimate:

  1. Project manager – 3.25 months
  2. Designer – 1 month
  3. Server developer – 2 months
  4. iOS developer – 3.5 months
  5. Android developer – 3.5 months
  6. Quality assurance engineer – 1 month

That’s a total of 14.25 person months of effort. If you consider a 40 hour work-week, that equates to approximately 2280 hours of effort. To calculate a total project cost you would simply multiply the number of hours times whatever your company’s hourly rate is. For this exercise, I will admit that I’m making some assumptions because I haven’t seen the app in action. However, I’ve been doing this a long time and given the descriptions of the functionality I’ve heard reported in the news, I’m comfortable with my estimates. 

I cannot say exactly what development plan this company followed and I cannot say how they staffed it, (although some details are starting to emerge). I also cannot say if the app developer had a longer play in mind when developing the app in terms of a profit model. For example, it is likely they could have charged the Iowa Democratic Party less than the actual cost of development with the intention of reusing the platform for other states and recouping more of their initial costs. (The Nevada Democratic Party apparently paid them for an app as well, so this is a likely possibility.) The one thing I can definitively say, however, is that for an app of this level of importance, $63,000 is not a very large budget. Given the vast amounts of money that campaigns raise, it seems like this would almost end up equivalent to a rounding error.

Seven Secret Benefits of Remote Work Revealed!

Companies that embrace remote teams can reap numerous benefits: employee engagement drastically improves, employee retention increases, and the available talent pool grows immensely when not tied to a single geographical location.

There are many benefits to remote employees as well. Some are obvious, but some are not so obvious. Below are seven benefits to remote employees that you may not know!

  1. Your compost and garbage bins will be emptier. When your home refrigerator is your work refrigerator, leftovers don’t spoil nearly as often which means less going into your waste bins.
  2. Streaming movies will load more quickly and stutter less. The high-speed Internet you need for your video conferencing just so happens to also help your Netflix streaming in the evenings.
  3. You will help fight piracy. There is a special place in hell for porch pirates (people that steal holiday gifts from people’s doorsteps.) During the holidays you will feel so much better knowing that you will definitely be home when UPS knocks on the door to deliver packages.
  4. You will be prepared when fashion styles from the previous decade come back in vogue. Because you don’t have to keep re-investing in clothing for meetings or to impress co-workers, your wardrobe will last quite a bit longer. Eventually, that neon shirt that you wear on days when you don’t have a video conference call will suddenly be chic.
  5. You will save immense amounts of money on personal hygiene products. Getting low on razors? You can push that stubble a little longer. Running out of foundation? No video calls today so no problem. Did you forget to get deodorant the last time you were at the store? Nobody can smell you on a conference call!
  6. If you have children, their grades will go up. Because you are consistently available to chaperone events at school, you will develop a rapport with your children’s teachers which will inevitably lead to more lenient grading and better engagement at school
  7. You will improve national security. If you don’t have a commute, you’re not burning fossil fuels trying to get to work which means your country will be less reliant on foreign oil reserves.


Time, Relativity and Distributed Companies

“The only reason for time is so that everything doesn’t happen at once.”
-Albert Einstein

One of the most difficult parts of communication within a fully distributed company is dealing with timezones. I can’t count the number of times that someone has emailed me asking “Can we have a meeting at 10 a.m.?” The obvious question here is which 10 a.m. are you asking about? Are you asking about your 10 a.m. or my 10 a.m.?  Unfortunately, it feels pedantic to ask the person to clarify what they mean, but it matters if you want everyone to show up at the same moment in time!

As I’ve mentioned before, we use Slack in place of meetings for a lot of internal communication, but we do still need to jump on phone calls from time to time. One of the skills that I’ve had to learn when trying to setup meetings is to be very explicit about the time that you mean. Think it’s easy? Try this quick little quiz. Figure out what time it is right now in the following U.S. cities, without using a map:

  1. Las Vegas
  2. Nashville
  3. New Orleans
  4. Phoenix
  5. Detroit
  6. Cleveland
  7. Louisville
  8. Pittsburgh
  9. Milwaukee
  10. Boise

I’m betting that while you might have fairly reasonable guesses, you’re not 100% positive on all of them. A few of them (like Phoenix) are particularly tricky! My recommendation is that when working with people in different timezones, it’s best if you declare the time and timezone not only for yourself but for the person you’re trying to invite. For example, let’s say that you are located in Austin, Texas and I am located in Portland, Oregon, and I want us to have a meeting at 11 in the morning. (Portland is in the Pacific Time Zone and Austin is in the Central Time Zone). I would probably ask you something like this:

     “Are you available for a call at 11:00 a.m. Pacific (1:00 p.m. Central)?”

By communicating it this way, I’m communicating to you that:

  1. We are not both in the same timezone
  2. I would like to talk to you at 1:00 in the afternoon
  3. It will still be 11:00 in the morning for me

This might seem like an obvious thing, but by being explicit, it helps remove any ambiguity and improves the overall quality of the communication. It also removes any assumption that the person you’re communicating with understands what timezones different cities are located in. The most important skill that you can develop in a distributed organization is your ability to communicate, and one of the easiest ways to improve is to become better at communicating time and timezones when talking to people.

Distributed Companies Are Real

When we first set out to build Silverpine, we didn’t really have much of a plan. All we knew was that the fates had aligned, and that it was our time to set out on our own. From our very first day, we have managed to bootstrap the business which was ultimately very beneficial, however, bootstrapping is hard. Very hard. While we grappled with unknown cashflows and even more unknown project pipelines, we knew we had to scrimp and save and keep our costs as low as we possibly could. One major way we were able to do that was by making Silverpine a “virtual” business in that we had no physical office space. It also didn’t hurt that neither my partner Ryan nor I wanted a commute, so it definitely felt like a win/win situation.

For the first few years of our existence, our staff consisted of only Ryan and myself and an occasional subcontractor or two. Working remote became an unstated, simple to implement company policy that we grew to appreciate implicitly, and the freedom that it lent to us quickly became a de facto benefit. As we grew as a company, however, the true value began to emerge.

When we finally hired our first full time employee, working remotely was still an implied benefit. At the same time, we started noticing a trend that many of the best engineers and developers that we knew were explicitly looking for new positions with significant remote work opportunities. However, when our first employee notified us that she was going to move to a rural area, it truly started to dawn on us what it meant for recruiting and retainment. Suddenly, this quirky company policy, that had just organically happened, had become an important pillar of our company culture.

At that point, Ryan and I decided that we were going to commit to Silverpine being a fully distributed organization. We abandoned any intention of developing a physical footprint and started viewing our evolving company through that lens. As we continued to grow and hire, I had to unlearn some of the things that had been ingrained in me from my time in the corporate world and from my MBA classes. I had to really dig in to understanding the tradeoffs of being distributed, partially because we needed to adopt tools and policies that would work well for remote employees, but also because we needed to be able to speak to our clients about how we were different from similar agencies and ultimately, why our distributed nature would benefit them.

For a long time, whenever a prospective client would ask us where we were located, I would make some sort of joke that we were following the “IBM model” even though it wasn’t really an accurate comparison. I would then do some general hand waving about what that meant, but more often than not, I was left with the distinct feeling that we were sometimes viewed as not being a legitimate company. Because of my approach to communicating our structure, I’m certain that we lost more than a couple bids on projects because of this.

Fortunately, as time progressed, many other companies started to legitimize remote work. Companies like Automattic, Basecamp, InVision and Zapier have literally written the book on how to have a remote team, and they have shown that it can work at scale. People have started to notice how these companies operate and thrive, and maybe most importantly, many of the best engineers and developers have started to view remote opportunities as a non-negotiable job requirement. I have run into people time and again at conferences and other work-related events where they explain that having a remote position is often times more important than a salary bump. That means that there is an actual, tangible economic value to a company that embraces remote work.

For Silverpine, we have become better at articulating the legitimacy of our remote nature in a way that better portrays it as a competitive advantage. We talk about the engagement and happiness levels of our employees. We talk about the quality of communication that our team practices on a daily basis. And, we talk about lower base costs which translates to lower project costs. We also occasionally talk about the tools and the processes and the intentionality of it that helps craft our company culture. All of this is important in explaining our story and our organization because there are still plenty of people with an incorrect understanding of remote companies.

I am convinced that the model we stumbled upon (but ultimately embraced) is a blueprint for long term success. It allows us a flexibility and nimbleness that other corporations simply can’t match, and in the ever-changing world that we live in, flexibility is a survival trait. As the Japanese proverb states: “The Bamboo that bends is stronger than the Oak that resists.”

We are definitely still learning and adapting how we function and operate, but I no longer act sheepish or apologize for being a remote company. I am proud of what we are building and what Silverpine has become. (It also doesn’t hurt that our track record is pretty great!) So, if you are thinking about working at a remote company or thinking about adopting remote-friendly policies, don’t approach it as some odd-ball thing. Take some time and read about what/how other companies that are doing it, and recognize that distributed companies are real.

Tools for a Distributed Software Agency

One of the things that I am most proud of is that Silverpine is a 100% distributed company. Often when people find out that we are fully remote, they will ask curiously about what tools we use to work together. This is completely understandable because the importance of having the right tool set is magnified for remote companies. We understand this innately and as such we are constantly evaluating our software stack. The following list represents the software that powers our business. (I have intentionally omitted some of the lower level development tools like Xcode and Android Studio.) The list is broken into four primary classifications: communication, development, project execution, and finance.



Before Slack, we used a hodge lodge of messaging tools like AIM, Google Chat and even old school SMS. It was horrible. Slack is the single most important tool that we use to communicate with each other and with our clients. All of our employees and contractors use it extensively every day, and even though I think that there should be some middle ground in their pricing between the paid and the pro plans, I can’t imagine trying to work remotely without it.


Let me just preface this by clarifying that I think that every single conference calling platform is terrible. I have used them all. From Zoom.io to Google Hangouts to AT&T Connect, they are just barely workable. Besides the all too common call drops they also all seem to suffer from ridiculous installation processes and byzantine user interfaces (Does this yellow button state mean my microphone is on mute or can they hear me?)

That being said, we have been using Webex for a very long time; not because it is good, but because it is better than the alternatives. And for our enterprise clients, it is somewhat of a known entity so we seem to spend less time per call doing the “can you hear me” dance. I wouldn’t say that I recommend Webex. It’s just what we use.

Dropbox Pro

We have been using Dropbox on personal plans for quite a while, but we recently decided to standardize on Dropbox Pro for file sharing. All of our projects have quite a bit of documentation, graphical assets and other large files that aren’t well suited for source control tools. Dropbox allows us to create per project file drops that we can easily access as well as share with other people when appropriate. We almost switched to Box.com because their pro plans have unlimited storage but ultimately decided it would be less transitional headache to just upgrade our existing Dropbox plans.

G Suite

We have been using Google for our email and calendar services for so long that our silverpinesoftware.com domain is still functioning under the original beta operating agreement. If G Suite disappeared I honestly wouldn’t even know where to start looking for a replacement. File this one under “it just works.”



One of Silverpine’s guiding design principles is that every user interface needs to have a beautiful “feel” to it, and that you simply can’t judge the feel of an app until you can hold it in your hand and interact with it. Because of this philosophy,  we have refined our development process over time to rely heavily on InVision to prototype the UI and UX of our apps before we ever even start writing code. The amount of time and pain it saves both us and our clients cannot be overstated. If you design for mobile, you really should be using InVision or something like it.


If you write software, you should be using a source control platform. If you need a source control platform you should be using GitHub. If you’re using something else, I’m sure you have a reason for it, but it’s probably not a very good reason. (All of our projects use GitHub repositories so when they changed their pricing model to be per user rather than per repository, it made our lives a lot easer.)

Azure DevOps

This one might surprise some people, but a couple years ago we transitioned to what is now known as Microsoft Azure DevOps for our automated build system and have been using it ever since. Prior to Azure DevOps we had used a variety of tools including TestFlight (bought by Apple), Fabric (bought by Twitter, then bought by Google), and BuddyBuild (ran out of money). Due to intense consolidation in that particular sector, we were frequently having to retroactively change our toolset which was both time consuming and costly. A friend of mine who works on the Microsoft tools team encouraged us to give Azure DevOps a try, and we have been extremely happy with that decision. Azure DevOps supports both iOS and Android, is massively configurable, has 24/7 support and most importantly, is backed by one of the largest companies in the world so it won’t be disappearing any time soon. If you need an automated build system and haven’t taken a look at Azure, I highly recommend at least kicking its tires.

Project Execution


For many years, we wandered in the desert of project management, largely piggybacking on whatever project management tools our clients happened to be using at the time. As such, we have used everything from Jira to Asana to Microsoft Excel to track projects and tasks. However, in the past year we have implemented Basecamp as our standard internal project tracking tool. One of the things I like best about Basecamp is that it has clearly been thoughtfully designed. Not only is it powerful, but its design somehow works to ensure that it doesn’t become overly burdensome in the same way that other similarly complex tools do.


If there was one piece of web software that I would invest internal Silverpine resources on, it would be a lightweight bug tracking tool. There just aren’t many platforms out there that can strike a balance of utility and ease of use that errs on the side of ease of use. For now, Lighthouse foots the bill for us in that regard, however, I’m not sure how much longer it will be around. There hasn’t been any significant development done on it in the 6+ years that we’ve been using it, so I’m not sure I would necessarily recommend it. That being said, it does what we need bug tracking software to do, and it does it well, and I haven’t found a replacement. If you have any personal favorites, please let me know.



Silverpine is a services business and sending invoices to our customers is literally how we are able to make money. Blinksale is the tool we use to send those invoices and look like we are professionals in the process. While it isn’t a complex tool, it expertly does what we need it to do: send and track professional looking invoices. If you send invoices to clients, you really should be using a tool like Blinksale because people can tell when you don’t.


Nobody really loves Intuit. They have created not one, but two near monopolies with TurboTax and Quickbooks. However, if you run a business, you need to track your finances in a way that your CPA can help you with your taxes at the end of the year, and if you tell your CPA that you use anything other than Quickbooks, they will not be happy with you and they will very likely take longer to do your taxes which means you will end up with a higher bill from them. That is the reality of Quickbooks and that is why we use it.


If you have employees or sub-contractors that you need to pay, you really should be using Gusto. The folks at Gusto are wizards when it comes to dealing with payroll taxes and W-9’s and a great deal more things that I simply don’t have to worry about because we use their service. Not only is the Gusto platform super easy to use, but their customer service team is actually pro-active in notifying us of upcoming tax law changes that might affect us. I am continually in awe of how great Gusto is and cannot say enough good things about them.


Unintended Consequences

This post comes from my old blog back in 2004. I’m reposting it here so that I don’t lose the content. The source was hand-written HTML so the formatting probably appears a bit off.

About seven years ago I wrote some code to do Mu-Law and A-Law compression. About six years ago, I decided to publish an article along with the source code for it. You can find it here. Anyway, the other day I received an email from someone who had taken it and modified it for what he was doing. In doing so, he found a piece of misinformation that has been in my article since I originally published it. Not a big deal, and I intend to rectify the issue. However, as we chatted over email, I asked him what he was using Mu-Law/A-Law compression for. Here is a clip from our email:

> So if you don’t mind me asking, what are you working on that has 13 bit

> unsigned audio input?

Sure. I am designing a system that monitors lots of radio stations to capture and

detect Emergency Alert System activations – those ugly tones and occasional

voice messages you hear on the radio. The system has some rather incredible

shortcomings for a critical system in 2005. When the emergency management

office triggers an alert they have no way of knowing whether or not radio stations

actually broadcast the alert. Sometimes the system fails – too often. So our

system listens to the stations and sends a report back to Emergency HQ. In

most cases an exception report that shows which stations did not properly

send out the alert. So if the dam is breaking or the nuke is going critical they

can try again, use the phone, send a helicopter or something.


Whoa. Code that I originally wrote to compress audio in children’s games is now being used to help monitor Emergency situations. Talk about your unintended consequences!


Translating Hardware Exceptions to C++ Exceptions

This post comes from my old blog back in 2004. I’m reposting it here so that I don’t lose the content. The source was hand-written HTML so the formatting probably appears a bit off.

No matter how careful of a programmer you are, there will always be times when a hardware
exception will occur in your code. Perhaps it was a third party component that was the
culprit. Perhaps, it was a fellow co-worker that broke something. Or maybe it was
Microsoft itself not playing fair with its documentation and/or implementations.
Whatever the case, it is often very useful to be able to capture a run-time exception
that was generated by the CPU. Sure, you can use a catch(…) to be your fail-safe, but
wouldn’t it be great to be able to convert that exception that was generated by the hardware
into a C++ exception? I created this class in order to do that very thing. In fact,
this class was the basis for my super assert that I created, because I found that I could
cause a hardware exception any time I wanted, and by using this C++ hardware exception container,
I could access each thread’s stack frame at run-time. This would eventually enable me to
perform a stack trace inside of an assert, but I will explain that more in a different

Anyway, I hope that this is useful to someone. I spent a while digging around in the
mire that is Microsoft’s documentation before I put this together. Perhaps this will save
someone else time in the future.




enum HWExceptionType
	eUnexpectedBreakpoint 	= EXCEPTION_BREAKPOINT,
	eSingleStepInstruction 	= EXCEPTION_SINGLE_STEP,
	eFloatStackCorrupted 	= EXCEPTION_FLT_STACK_CHECK,
	ePrivelegedInstruction 	= EXCEPTION_PRIV_INSTRUCTION,

class HWException
          HWException(HWExceptionType aType,
                      EXCEPTION_POINTERS* pExp):

	  HWExceptionType     GetCategory()  const {return itsCategory;}
	  DWORD		      GetLocation()  const {return itsLocation;}
	  EXCEPTION_POINTERS* GetSysPointer()const {return itsPointers;}

          HWExceptionType	itsCategory;
	  DWORD			itsLocation;

static void HWTranslateException(unsigned int u, 
                                 EXCEPTION_POINTERS* pExp)
	throw HWException((HWExceptionType)u,pExp);


Example usage:

#include "windows.h"
#include "HWException.h"

int main()
	//Note, setting the exception translator must be done 
	//on a per thread basis.

	try {
		//This will cause an access violation
		char* ptr = NULL;
		*ptr = 5; 	
	catch (HWException& e)
		//We can now know both the type and the
		//memory location of the instruction that
		//caused the exception.  Cool!

		HWExceptionType exceptionType = e.GetCategory();
		DWORD address = e.GetLocation();
	catch (...)
		//If we got here, then it was some other kind
		//of C++ exception...

	return 0;