The More Sleep Experiment

A year or two ago I experimented with quitting caffeine later in the afternoon to improve the quality of my sleep. This experiment was largely successful and now I rarely drink soda and I stop my coffee intake by early afternoon. Usually when I drink coffee I limit myself to two regular cups, if I have a third then it is decaf. This has greatly cut into my podcast consumption as I now typically fall asleep within 15 minutes of hitting the bed.

The next phase of this experiment is to inch my way from seven to eight hours of sleep. This was largely triggered by reading an article I found that suggested that seven hours might not be sufficient, but also it increases the margin of error for hitting my seven hour goal. The National Sleep Foundation recommends seven to nine hours for adults. If I aim for eight but hit seven or seven and a half then I am in a much better place than if I aim for seven and hit six. So far it is day two of this experiment and I feel better than usual.

Finding the Root Cause

Since September I have been battling with my cable Internet. About once a week the Internet dies. There is no warning, no error, no malfunction of the lights of the modem, it simply halts. Its death apparent by my modem’s inaccessible status page. A simple reboot brings it back alive.

Diagnosing a technical problem involves considering all possibilities from the possible to the probable. A good technician gathers facts, assesses the situation, and starts with the most probable thing and works from there. Unfortunately that is not how tech support worked with Motorola and Arris. They wanted me to exhaust all the possibilities. While the chances are not zero percent that my router was not working, it did not seem to be the likely possibility. Yet they insisted I direct connect my modem to my computer for a week or two to see if the issue presented itself. I had to stand my ground that this was not a reasonable solution given the need of my roommates to also use the Internet for a week. After months of technical support calls with them and Comcast I finally have a path forward. They agreed to ship me a replacement modem.

One thing I have learned from this is to keep better records. While Motorola Arris had a record of my previous calls, they had logged them into the model number of a different modem that I did not own. Secondly tech support can make or break the trust you have in a company. I will never purchase a product from them again. The process for them to intake my information for a replacement was arduous and their system went down during my call. If they are messing so many things up in technical support, should I be surprised that their product may be the thing that broke?

How Google Implemented Automated Testing

I have been spending a lot of time thinking about the hows and whys of implementing automated testing in our workflows, and thought this Mike Bland video was great:

Time is a Constraint

From coding to organizing one of the most frequent ideas I see raised when attempting to solve a vexing challenge is “what if we throw more time at it?” It usually is phrased something more like “what if we do more of X” or “what if we do more of Y” where X or Y is some idea that on its own merits is a good idea. Sadly ideas do not exist in a vacuum and we only have twenty-four hours in a day. So either we find ideas that do not require tons of time or we eliminate them.

In software one of the key decisions a team has to make is where they are going to spend their time. In many cases the decision usually rests with the front or back end of the website. There exist pluggable modules that largely abstract away the complexity of the front or back ends. In the case of the back end it involves using something like Airtable. In the case of the front-end it involves using Bootstrap. In many cases a hosted Content Management System like Wordpress or Squarespace abstracts the entire thing away. We can choose where to use off-the-rack components and where we want to custom tailor the things we build. In order to decide this we should ask where we add our special sauce, and what the cost is of going custom over off-the-rack.

The magic of off the rack components is they can be used to easily create a protosketch:

For many ideas there is a shorter version of the idea that can be built. It may not comport with the product owner’s exact idea of what their thing should look like. However it will at least be close and often functional. In software, like everywhere else, the Pareto principle applies. The last 20% of functionality will require 80% of the effort. If a product owner is willing to accept a simpler version of it to start then they can get more value for the time and money developers spend.

Single Process People

What is the most efficient and productive way to get work done? People are inherently single process. The research is clear. Finding focus for the single thing is the subject of many software hacks. Pair programming holds you accountable to focus only on software development. Apps like iA Writer used in full screen mode cause you to tune out the rest of background noise. Now Apple has added do not disturb and notification management features to iOS because they worry the notifications are addictive and negatively impacting their brains. Collectively we recognize this problem and have found solutions for it. Yet we still have so far to go.

One place that remains a challenge is dealing with asynchronous communication. While the telephone is coming out of fashion and folks are using tools like email and Slack, there still is not always a culture that allows it to work and occur. Recently when dealing with a credit card dispute I filed the dispute online, they responded that I should fax them the evidence of my dispute, I would receive information on it via snail mail, and I should call them with questions and to learn about the status. The surface area of communication mechanisms here is very large and inconsistent. The mental work required to manage this task is large and having to call them means that during my Sunday evening review of my inbox I cannot simply email them for a status update. I now have to engage them on their own terms and be interrupted.

When it comes to focus at work one tool that is a sharp knife is the meeting. I have written in the past that meetings are effective attention capture and focus mechanisms. They force people to be accountable. However too many meetings or ill timed meetings can be a denial of service attack against a single persons productivity.1 Some software companies will declare a specific day to be meeting free. However given the deep concentration software development requires, for them, it should be a red flag if a specific day needs to be without meetings. The better tactic would be to declare one or two days to be meeting allowed. Or to have a time block at the beginning or end of the day where meetings can be scheduled once development work is over.

  1. The exception to this is of course for folks whose job is primarily attending meetings. Folks in sales or management probably need to be in a lot of meetings. However given that meetings do not scale well, figuring out how to move work from a meeting to a non-meeting paradigm can be a big win for anyone. 

Follow Zagaja.com posts: RSS Feed
This work by Matt Zagaja is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License.