The Importance of Morning Routine (Morning Routine 2.0)

Posted by on . No comments.

Note: This is very much a work in progress. Comments welcome!

So you’ve decided to strike out on your own, by freelancing or start a company. The first day you get up, you realize you’re free. No office, no working hours, no one staring over your shoulder, no constant pressure to have your butt in a chair doing nothing. Great, right?

Well, kind of. The first month works great: you’re super productive and everything gets done in two hours, and then you go  home and watch TV the rest of the day. Then your subconscious realizes that if you stay home, you can do nothing but watch TV and surf the web all day, right away.

So you go to coffee shops and libraries. For free, or the price of a latte, you can get wireless, and work with fewer distractions. [1]

There’s only one other big problem: the alarm clock.

[1] If that’s too much angling for seats for you, you can also find a good coworking space for a few hundred bucks a month.

The alarm clock

This one is pretty fancy

Credit

 

The alarm clock is, biologically speaking, the enemy. Studies almost universally seem to show that having less sleep is the equivalent of taking the stupid knob on your brain and turning it up, all day. Any machine that interrupts your natural sleep cycles can’t be good; in nature, it’s essentially the equivalent of having a (mostly) friendly bear wander by your hut at 6 am every morning; you wake up groggy, stressed out, forced into action. An entire company was started and funded around avoiding it.

So, naturally, the first thing you do, once you’re free, is turn it off. The only problem: You’re a night owl. So now you have random hours. Every day you wake up, and you’re not sure what time it’ll be.
Do you just head to the same cafe, whether it’s open for 12 hours or 4?

Cognitive Load

One of the hidden advantages of regular office hours in a regular office is reduced cognitive load. If you have to work every day, but you’re not sure where or when, you spend time thinking and processing: “Is this place open? Is it worth it to commute 30 minutes if they’re going to close at 5? Maybe I should just stay home today. I wonder what’s on my email.”

Continued for too long, this thinking drains your reserve of mental energy, before you’ve gotten to work.

With a rigid, defined procedure, none of this thinking takes place: You roll out of bed, put on your clothes, do whatever and in 30 minutes you’re in the office. And you haven’t had to make any decisions yet. Your mental energy is saved for when you get in and tackle the first work-related problem.

That’s the benefit of reduced cognitive load.

Morning Routine 2.0

Does this mean that you, the freewheeling self-employed freelancer, need to don a suit every single day, set your alarm clock for 4 in the morning, and go for a run of 1.8 miles before coming in for a coffee and commute to the office?

Fortunately, it doesn’t.

The most important thing that you need to have in the morning is not super rigid rules, but a set of algorithms that reduce cognitive load.

Most likely, in the morning, you’re making the same set of decisions, over and over again:

  • What should I wear?
  • Where should I work?
  • What am I working on today?
  • How long should I work?

For a full-time employee, these sets of questions have the same answer, every single day. Regardless of whether you’re feeling great or tired, regardless of what you have to do that day or what appointments you have, you have to answer these questions with the same location and the same time.

Using the same answer every day may be easy, but it doesn’t always fit. Sometimes you’re taking calls and networking all day; sometimes there’s a tropical hurricane heading past your state and it’s pouring buckets for the next week.

So, instead of a morning routine, have a morning algorithm. Here’s one I’m starting to use:

  1. Pick out clothes the day before, based on weather and schedule.
  2. If I have to take calls that day: pull out the laptop and work from home (It’s hard to take calls in a public space).
  3. If there’s a meeting/event to go to: find a place to work near the meeting place
  4. If it’s before X o’clock: Work at the faraway office (most productive for long blocks of time)
  5. If it’s after X o’clock: Work at a nearby coffee shop.

With whatever algorithm you use, the instructions should be so simple, straightforward and brain dead that you can apply them in 5 seconds without questioning them. And once you’ve polished your algorithm over a few weeks of use, you should always follow it to the letter. Amend it with the greatest caution, because once you start changing it every morning, the benefits of reduced cognitive load disappear.

By doing all your thinking beforehand, you can save your brain cells for when your routine is over and your real work begins.

If I don’t do it, won’t someone else do it eventually?

Posted by on . No comments.

Note: This is very much a work in progress. Comments welcome!

Ever hear the phrase “write your congressman?” Those sorts of actions I like to call “participating in the tide.” Combined, perhaps the millions of people who write with you will together make a difference, but not you specifically.

I would argue that, even for great inventions, most of the time we are participating in the tide, not shaping it. Look at, for example, Alexander Graham Bell. You might argue, “Of course he changed the world! Dude invented the telephone,” and by some definition, you’d be right. But when it comes down to it, the telephone was bound to be invented; there was even someone else inventing it at around the same time, and people argue over who was first.

Ferdinand Verbiest, inventor of perhaps the earliest self-propelled vehicle


William Murdoch, built a working steam carriage in 1784

Oliver Evans, first to get a US patent of a working steam carriage


If actions are individually insignificant, why should we as individuals care what we do?

1. Don’t give up on the tide: History is often changed by movements. The fact that our one contribution is small doesn’t change the fact that if all of our small contributions stopped, so would the world. Whether or not we want to do something more deliberate, being a part of the greater trend is important.

2. Point: This should make us feel better: We needn’t worry about changing the world or making a huge difference. Even if we don’t build a successful social networking service, someone will do it. Even if we don’t make solar power, someone else is still probably working on it.
And many of the more obscure, unique inventions that wouldn’t have flowed naturally out of a lab somewhere have become less important, their impact smoothed over by time and trend.

3. Counterpoint: What if it doesn’t: Perhaps we still have an urge to make a unique, individual difference? If so, then what?

1) Stop wanting: There are arguments not to try and shape society in such a non-inevitable manner. Stalin changed Russia, Kim Il Sung changed Korea, and certainly one way to change (short term, though likely not long term) history is to exert power. But history has not conclusively demonstrated that individuals who held this kind of world-shaping, not-likely-to-happen-on-its-own power have really made the world better, despite their best intentions. Perhaps it’s better just to participate in the tide and make sure we’re moving the world in the best way we can.

2) Work on ideas: A more powerful way to influence the world is through thought. Someone may have invented the press and changed the world if Gutenburg didn’t, but would someone have come up with Marxism, capitalism, or freedom of that press? I suspect for certain ideas, someone would have invented the term. But not all. Would we definitely have open source if no one coined it? An interesting question.

3) ???

Taking too long to deal with emails? Separate writing and sending.

Posted by on . No comments.

Has this ever happened to you?

You’re looking through your inbox, and you see one of those messages. You know, those messages where you know you need to respond, but you can’t just dash off a quick email – you’ll need to sit down and think about it. Or you want to be extra sure that what you’re writing is the right response. Every time you check your mail the email keeps bugging you, and you think, “I know I should deal with that, but not right now; I’ll get back to it later.”

 

One quick way to get the ball rolling: Write a quick two minute response as a draft, right away. Save it, don’t send it.

Gmail Save as Draft Button

 

When you separate writing and sending:

  • You enable yourself to write something without it having to be perfect right away.
  • If you’re writing an email with strong emotional content, you get to put some distance between the emotion and the email.
  • You don’t get stuck looking at the same messages as often. You can archive the message and save the draft as a reminder.
  • You get a head start on writing the full response. Writing a very quick first draft will help get your thoughts flowing and make writing the actual email easier.

Extra tip: If you’re using gmail, you may already know you can stop an email you send by accident with Undo Send, but if you want extra security, try adding the day you want to send it as a recipient. Gmail won’t send the email since the name you type in isn’t a real email address. (Try it!)

Gmail Decoy Recipients

How to use dbgsrv, the Process Server

Posted by on . No comments.

If you’ve ever used Debugging Tools for Windows, you’ve probably used remote debugging. Users of windbg/ntsd are usually familiar with the “.server” command and connecting to remote debugging sessions using “Connect to Remote Session” in windbg. Knowing this, what good is the dbgsrv utility that comes with the Debugging Tools for Windows? How is it different from a normal remote debugging session?

For anyone familiar with dbgsrv, it is similar in purpose and function to msvsmon, the visual studio remote debugging monitor. Both applications are “process servers” for their respective debugging environment. Running dbgsrv on a remote machine allows developers to attach to any process on that machine, or launch processes under the debugger.

Using dbgsrv is slightly mysterious, as the UI for using it is a bit cryptic in WinDbg. I’m going to run through a few examples to show how useful dbgsrv can be.

To start, we need to get dbgsrv running on the machine you want to debug. Usually, this will be a test computer that you want to debug from your development computer. If you want to follow along the examples, you can use a single machine, although this scenario isn’t very useful for real world debugging. To start dbgsrv, run it from the command line giving it parameters to pick a transport to use. Usually, tcp is the easiest when not working with domain-joined machines:

dbgsrv -t tcp:port=31337

If there are no errors, dbgsrv will start silently and start listening for connections. (You may see a firewall dialog at this point). To use the process server from windbg, use the “Connect to Remote Stub…” menu item from the File menu:

Screenshot of Connect to Remote Stub in Windbg

The connection string should match what you’ve started dbgsrv with. For instance, if dbgsrv is running on my computer named “timtst”, I would connect to “tcp:port=31337,server=timtst”. After accepting the connection string in this dialog, there will be no indication of failure or success until you actually try to use it. Once the connection string is entered, you can try to attach to a process using File->Attach to Process, or using F6. If the connection was successful, you will see a list of processes on your test computer, or an error if the connection was not successful.

To use the same functionality in cdb/ntsd, you can use the “premote” command line argument. For instance, to use the same dbgsrv instance as in the previous example to attach to process ID 4000, you can use the following command with ntsd:

ntsd -premote tcp:port=31337,server=timtst -p 4000

Using ntsd also lets you start a process under the debugger through a process server:

ntsd -premote tcp:port=31337,server=timtst C:\MyTestApp.exe

Note that the path given refers to a path on the remote machine running dbgsrv, not the machine running ntsd. This functionality is not available in windbg.

There is an excellent write-up with more information about dbgsrv at nynaeve.net

If you’ve found this interesting, I highly recommend the book Advanced Windows Debugging
by Daniel Pravat. As one of the most informative books about the Windows Debugging toolset, it has a host of information about dbgsrv and the rest of the tools.