David Tate

Mastering the Art (and Science) of Remote Work

Category: consulting Page 1 of 2

A New Definition of Work Ethic

When I was in college I was proud of how hard I worked.

I started at 6 AM just as the coffeeshop opened, spending most of the day studying, then attending class before working a part-time job until late at night. People told me I had a great “work ethic” when I got into the workforce, which I took as a compliment. In hindsight, what they meant was “that new person is here a lot and looks busy as hell”. In school when I was told I had a good work ethic it simply meant that I studied for long hours in the library and took a long time making my papers just so.

Now I am a professional “knowledge worker” in software development, a field in which you can work hard for 10 hours and then figure out a better solution ten minutes after waking up from a nap. Working as a manager is similar: not doing something smart now can cause months of work later. The rules have changed: how I work matters more now than how much I work. What matters is getting the right answers, not the total of questions answered.

Working long hours is not always a bad sign, earlier in your career it can be a great boost to spend extra time learning and building professional experiences. And when you are starting something you have to work harder to build momentum.

But I don’t want to work with people that will burn themselves out or paint themselves into corner after corner by just grinding away without changing tactics. Not everybody feels this way. I used to work with someone who asked this question near the end of every job interview:

If you were asked to estimate some work and you concluded that it would take between a week and two weeks, and were then told it needed to be done three days from now or the world would end, what would you do?

The first time I heard it I remember thinking that it probably created the impression that they were interviewing at a company that required long hours. The tone of the question, to me, sounded like “how many punches to the face can you take?”. But once I started hearing the answers I realized that you can learn a lot by how people respond to this question. It is an unexpected maturity reading.

I’ve heard the standard not great answers:

I would brew some coffee and just work until it was done. I once worked for 26 hours in a row.

I would get it done no matter what or who stood in my way, including you.

No matter what, I would get the job done – you can count on me.

I would bring my sleeping bag to work, it is always in my car for this reason.

Here are some better answers:

I would ask what was three days away – what is the driver of the deadline?

I would see if we could hire people – my brother in law might be able to help, he is a good man.

I would ask why I was asked to estimate the work if there was a hard deadline that had to be met.

I would sit down with the requestor and brainstorm ideas for how to speed up the effort by cutting out inessential work.

I would sit down with the customer and make sure I understood the problem they were trying to solve – maybe I had estimated a solution to the wrong problem.

I’d let them get away with that once, and then avoid that manager if possible, especially late in the week.

I’d probably ragequit.

If we couldn’t solve it, and it was a real do-or-die situation, I would try my best to get it done within reason, and then in the post-mortem discuss how we got into this situation. If the pattern continued I’d keep pushing for the team to improve, but if I found it was just a cultural issue in which every deadline had extra false pressure I’d have to reassess whether this company was the best place for me.

My version of this question is basically: Do you default to thinking first then working or working first then thinking? Do you understand the downsides of just working a lot of hours under pressure?

When I hear the term work ethic now it means something completely different:

  • When they show up to work, they will show up as a professional ready to work:
    • Well fed
    • Caught up on sleep
    • Excited about their work
  • They will take the right amount of time to figure out what needs to be done; they will ask a lot of questions to understand the proper context where the work exists so they can make smart micro-decisions.
  • Once their path is agreed upon, they will work quickly and efficiently to complete the work, communicating clearly and honestly along the way about how it is progressing
  • After the work is done, they will seek feedback and provide honest and tough feedback on the process itself with the aim of making everything easier the next time.

Work ethic is much more results-focused in my mind now, and means working smart and not just working hard. It speaks to long-term efficiency and effectiveness and not to anything else like how-much-you-want-it and how-much-you-will-give-up. You care enough about the work to give some of your best energy to it, want to get better at it, care about waste during it, work hard when required, and think-then-work smart by default.

I’m writing a book about successfully working from home; click here if you want to know when it is complete.

Reflection Frameworks

The week between Christmas and New Year’s Day is typically a change of pace for most people – even if they don’t go on vacation – and a socially acceptable time to reflect and make large changes in your life. I am intentional about goal-setting and have found that having a framework – a simple set of questions – to guide the reflections helps.

Here are a few ways to help you reflect on 2016 and plan for the new year.

Reflection Frameworks

#1 Todd Henry’s “Questions for 2017″

  • What do I want to experience?
  • Where do I want to go?
  • What do I want to learn?
  • How do I want to change?

#2 Agile Development Process Improvement Questions

  • What should we start doing?
  • What’s something new we should add?
  • What should we stop doing?
  • What’s something we’re doing that we don’t need to do anymore?
  • What should we continue doing?
  • What are we already doing that’s going well?

#3 “If I took it seriously” exercise

This is one I made up and use in my yearly retreats; for each role in your life (father, husband, employee, etc.) ask yourself:

What would it look like if I took this completely seriously?

This provides a good list of actions you can take to get a little better at each role, and it helps you focus and prioritize certain roles over others.

#5 Morning Journal Questions, but for the entire year.

Ask yourself the daily questions, but apply them to the entire year:

  • I am grateful for ____ [3 things].
  • What would make 2017 great? [3 things]
  • Three Amazing Things that happened in 2016. [3 things]
  • How could I have made 2016 better?

Finally, some extra inspiration and some humor about resolutions. Good luck!


Play to your Strengths – Well, Sometimes.

You hear, and most act upon, the advice to “learn all you can and improve your weaknesses.” Traditional education focuses on being well-rounded and not having any major knowledge gaps, so we get used to pushing through learning things we don’t pick up quickly.

But there is another idea, most commonly learned by taking an assessment like StrengthFinder, to instead figure out what you are good at and then focus on it intensely. The thrust of this idea is that effort multiplies in your areas of power – a week of work improving your public speaking when you are naturally good at it pays off more than a month of working on a weakness.

Combining these, most of us just shore up the very important weaknesses but play to our strengths. Seems simple, well maybe not.

All strengths have blindspots

For example, I am good at solving problems, and I am (relatively) calm in a (work) crisis. Because of this, I’m not afraid of a small crisis. This is a blindspot.

I’m not going to prevent these things from happening as aggressively as someone who freaks out and jumps out of a window when a bug is found in production. This means that my strength is also a weakness – if I “play” to this strength then I, without knowing it, might make it more likely to happen so that someone like me is needed.

I used to work for an executive that had a similar strength: he was very good at convincing employees and clients to not resign or walk away from the contract. He excelled in last-ditch efforts and high-pressure situations. Being good at talking people back into the building is a good tool to have, but he seemed to use it an awful lot. Without meaning to do so, he did a number of other things that seemed to cause situations in which his particular set of skills would always be needed.

Maybe if it happens three times it is partially on you, brother.

I can manage more projects at a time than the average person. I read 3-5 books at a time and can keep track of where I am on each one. I have seen old friends years later and will continue conversations with them that we had two years ago and they will not remember them. I can mentally bookmark things and then return to them.

This means that I might say “yes” to too many things at a time and create situations in which I over-allocate myself, thus making it a weakness. It also means that I might multi-task, a common way to not be productive, more often than someone than can’t do this easily. It is a weakness and a strength.

You have to be careful to not play towards your strength, but instead, recognize when they are truly needed and then use them.

I’m writing a book about successfully working from home; click here if you want to know when it is complete.

Personal Pre-Mortems

If you are like me you can get into a mindset of negative thinking where you can poke holes in any potential project idea or action. After all, thinking of doomsday scenarios is a marketable skill when you actually take action to prevent them, but in our personal lives having this negative view is very bad for us. It makes us hesitate or not get started on an important project with an uncertain future. It makes us not surprised by failure or neutrality. If you expect the worst you will probably get it.

This same method of thinking can be a powerful ally, however, when used as a weapon.

Defensive Weapon

Think of an important project, relationship, or trajectory in your life. Now imagine the worst that can happen. I call this technique “pre-mortems” and it is not the most fun you will have today. Think of the following scenarios:

  • You are divorced
  • You are bankrupt
  • You have a terrible, but preventable, health issue
  • You have lost your job, and are suddenly unable to get another one in the same industry, geographic area, or market due to a damaged reputation.
  • All of your shoes have been replaced with pink crocs.

Now ask yourself this question: “How did this happen?” and list the reasons.

Well if I’m divorced it was probably because my wife and I stopped communicating, or stopped making sure that we spent time together and just focused too much on the kids, or maybe I got a wondering eye because of some unresolved problem, or because I stopped trying.

Well if I’ve got diabetes or cancer it might be because I order fried chicken from a car more times than I exercise most weeks. I guess that wouldn’t be a surprise.

If I’m bankrupt it is because I have become disabled and don’t have good coverage in that area. Since I’m the primary breadwinner and we have kids, my wife’s salary wouldn’t cover everything so we would have to lose the house.

If I can’t work in my field this is probably because some really bad scandal was slowly slipped into by a group of people encouraging or ignoring the warning signs.

If I only have pink crocs it is probably because I lost a bet of some form and am being forced to wear them as some sort of shame spectacle.

Now go and avoid those things, establish guardrails against those results, make contingency plans for those things:

  • I need to make sure I’m focusing and working on my marriage more.
  • I need to get better disability insurance.
  • I need to exercise, eat real food, and focus on my health.
  • I need to continue to avoid any financial or relational gray areas.
  • I should not bet on the New York Jets.

Now take a deep breath – none of these has happened; you still have time. During the life of a project you can apply this same mode of thinking – 60% into a software development project I can sit down and say: “OK this project is late – why?” and list three actions I could take to avoid the most common failure scenarios.

Offensive Weapon

For new projects, you can use the same method without depressing yourself. Let’s imagine something that you want to do but you keep putting it off or convincing yourself that you can’t do it. We all hear a voice that tells us “it won’t work out”, “you will fail and people will see”, “you aren’t good enough”, “your pink crocs are so dumb”, etc.

Maybe you want to write a book, try a new career path, take some time off of work to drive across the country, or audition for American Idol. Pick something you really want to do that you have talked yourself out of a few times.

Let’s listen to the inner voice, really listen for a minute. Give the little hater its chance to make a speech.

OK if you start this project and it fails, then you will have wasted $30,000, which means you would need to sell your crappy car and maybe live with your parents for awhile. As a twenty-eight-year-old man. If you are living with your parents it wouldn’t exactly be a secret, so that would be really embarrassing. Everybody that thought that you had it together would realize that you didn’t, so it would actually erode my reputation in a way that would be hard to crawl out of. From there – living in a basement – it would be really hard to recover emotionally. But I guess since you are not that special it would be what you deserve for trying to be.

Now filter out the emotions, insults, and judgments and just think of the real consequences of failure for your project. Split out how they would make you feel for a moment and just think logistically:

  • I would lose a lot of money
  • I would be spending time on something that didn’t work out, when I could have been doing other things
  • I would trade some of my reputation

Now make some plans to guard against these things being as bad – ways that you can hedge or counter these things – and list them.

  • I would lose some money, but I won’t touch a one-month emergency fund. If I got to the point that I touched this I would get a job at Starbucks. I look great in green.
  • Yes, there is an opportunity cost, but once I get started I would ignore this thought and really commit. Besides, anything else that I worked on would run into the same obstacles – I’ll be smart with the projects I pick to focus in on.
  • My reputation might get hurt, but I might also draw attention and respect for trying something bold – and perhaps I care about those people’s opinions more anyway. Besides, learning from failure means you have to actually fail sometimes.
  • Living with my parents would stink, but I wouldn’t have to do my own laundry. Plus my mom will not make fun of my pink crocs.

Now answer the inner critic with a detailed version of “So, what are you going to do about it?”:

I might fail and lose money, time, and face, but I would have really tried, and probably learned something. I would then be able to rebuild my life by taking a regular job and working to save like I have done so far in my life. Since I would have been following what I really wanted to do I wouldn’t regret it and wouldn’t feel “behind” in the years when I was re-establishing my financial stability. I would have failed doing what I want to do, rather than half-failing over the long-term doing something I didn’t care about.

Read some more about this technique at Business Insider and watch some other practical benefits to Pessimism.

I’m writing a book about successfully working from home; click here if you want to know when it is complete.

Bring Your Own Team

Now here is an interesting idea: front-loading an aquihire by hiring a functioning team rather that a single person. As many of us know developers travel in packs anyway (I have worked with many former colleagues at new places) so bringing on a pre-existing team is an interesting idea.

Some immediate thoughts:

  • Developers might travel in packs, but it is usually over time and not all at once.  If you imagine an entire team leaving a company this seems very disruptive; the entire idea makes more sense for people that have shifted to consulting but tend to still work with a core group.
  • Navigating the waters of interviewing people individually vs. as a group: do you do traditional “tell me about your resume” interviews (ugh) or have them do a pilot project as a team?
  • What do you do when you like half of the team? Once it is time to make the hire / no-hire you might find that one person doesn’t fit your expectations but is crucial to the overall team’s output.
  • On that subject the post mentions engineering being the main focus, but what non-code-writing roles will they end up hiring for?  Would the person to lead the team be a pre-existing Stripe team member?
  • Hiring an entire team means you could need work carved out for them already (this is hard apart from greenfield projects)
  • Maintaining your culture would be harder as they would have a stronger pull towards whatever team culture they have already built.

Interesting idea; and some interesting feedback on the Hacker New comments.

A System for Analyzing Systems [Part 2]

This is the second part of an (awesomely epic) series on how to analyze a software system quickly, click here to view Part 1.

So now you (having the right attitude and documenting everything) have viewed the main nouns (data) and verbs (use cases, workflows).  What do you do next? Profit?

#3 Find integration points and environmental concerns

It is important to understand the system within its software ecosystem – find the system edges:

  • Make a list of the technologies used (again – avoid judgment)
  • Make a list of the integration points (other systems, off the shelf products, web service apis, manual steps in overall process)
  • Look at dll references, build files, web references, configuration files, database connection strings, etc.
  • Draw a simple sketch of the application within its context with others

#4 Read some code

This is normally where developers start – reading semi-colons.  But maintain some discipline:

  • Make a simple outline of the project structure and main namespaces and entry points. Input, processing, output.
  • Try to not go down every rabbit hole too quickly – add to your WTH list liberally and then circle back.
  • Guided by what you know already dive in based on what makes sense – read the billing module, the calculation piece, the ranking algorithm, or the integration with Facebook.
  • Document system conventions, code conventions, and architecture. The build order can be useful and painfully revealing here – on larger projects I break out ndepend to see the overall structure.

#5 Read some documentation

If the project has some artifacts now is a good time to read them. Most people will read them earlier in the process but since documentation is a record of what was the truth during a time in which the truth was still being figured out when people had time to do such things I’ve grown untrusting of it until I know what is what in the application. Project documents are fascinating in that they provide historical clues to design decisions, project status, pressure, and onetime events like data conversions and client meetings that affect the system in the future. Read up and take notes. Be aware that some pieces of documentation are position papers and do not represent the current reality.

#6 Talk to some people

Armed with nouns, verbs, and a basic understanding of the code go get your questions answered by someone on the project (if they will return your calls). A few tips for this process if a developer is handing off to you:

Realize that when a developer hands off they will do two things:

  • Blow off steam (I really didn’t want to do this but that freakshow client forced us to)
  • Play defense / apologize (I was under pressure so just hacked this up)

Let this happen, avoid judgment and be friendly and helpful.

#8 Identify the Win Condition

By this stage in the game you should know the “win condition” of the system – when it works how it provides value to a customer.  Examples would be:

  • “Allows users to find out about flight delays before other airlines, saving them time and allowing them an advantage against other travelers in a cancellation scenario” (FlightCaster)
  • “Provide an easy to use way to update online ads across multiple platforms based on your inventory” (Tentail)
  • “Allows users to find out about current events much faster, trade cat pictures, and waste half of their life” (Twitter)

#8 Wrapping up

So now you have your document with just Facts and Questions having hopefully whittled down your WTH list. Polish up your facts and add a summary statement and the application “win condition” to the top and you are done:

EasyTrack is a web-based accounting system used by small businesses that is built on ASP.NET Web forms with a SQL Server 2005 database. It integrates with Quickbooks, exports transactions as csv, and has a web service api for 3rd party integration. It syncs nightly with a client customization of an older version that uses the same database but has a non-web frontend. It works in Internet Explorer. Its niche is being an easy to use tracking system for a discrete set of common accounting tasks that are harder to do with larger systems.

I’m writing a book about successfully working from home; click here if you want to know when it is complete.

A System for Analyzing Systems [Part 1]

We seek definition to understand the system so that we can discern
the rules so that we know what to do next so that we win.

— Michael Lopp, Being Geek: The Software Developer’s Career Handbook

How do you approach learning a new system that is dumped on your lap like a spilled plate of nachos? Let’s say somebody walks up to you and says:

Hey nerd- we need you to look at the EasyTrack system tomorrow – we have a buglist that we need you to churn through before the end of the week. Ralph was working on it but after his nervous breakdown he won’t return our calls.

As developers we are asked to jump into complex software systems all the time and a big part of our value is simply understanding systems (not just changing them or making new ones). This is a skill that we need to be intentional about. We need a system for learning systems. Here is mine.

First steps: Attitude

Avoid judgement of the people who have worked on the system, the client’s goals, the choice of typeface on the one page of system documentation, the developer’s skills and experience, the organization of the code, the choice of technology, the choice of coffee used during the project, the organization of the altar built to the stored procedure that does everything, et al.

You have no idea the in-the-womb conditions on the project and don’t know the real trade-offs that were in play. Like many negative emotions judgement will close you down and cloud your thought so keep a clear mind when reviewing a system. Starting with a good attitude will also help you in talking to people on the project later on.

First steps: Document

As you work through the steps document what you are finding. When I do this my goals are:

  • To make me feel like I’m doing something as just staring at a new system can be brutal.
  • To make a deliverable that I can publish at the end of the system analysis if needed.
  • To allow me to have a place to store questions that I can’t find out from just reading code.

On that last point – I normally have Facts, Questions, and WTH sections in the document that I use as I work through a system. Facts are things that I have learned definitively about the system, Questions are open questions that I have researched and can’t find an answer to without asking someone or gaining access to something else, and WTH are bogeys – items that I see that I don’t understand that I’m deferring until later.

An example – as I’m reviewing the database I see an oddly-named stored procedure: spSyncOrderNoTransactionWithRollback? Hmm… So we add this to the WTH list until we can go back and read through it, where it is called, etc.  So we might end up with:


  • In spSyncChangeOrderNoTransactionWithRollback – how can you have a rollback without a transaction – is this nested?

Which leads later to the following:

  • Some of the stored procedures exist in the database but aren’t used by the application and are part of an export / sync process.  They start with spSync*
  • Some, but not all, of the stored procedures use nested transactions with checkpoint.


  • What is the export/sync process called by job execSync4_Bak that runs every night and calls the spSync* sprocs? [No access across linked server to the tables it is writing to]

As I work through the system I’m simply turning WTHs into Facts or Questions. The temptation once you have a basic understanding of the system is to stop typing – don’t do this.

If you maintain the facts list and polish it up you’ll have a nice system overview document. The easiest time to document a system is when it doesn’t feel like you are having to write-up up a bunch of things you already know.  So by writing while learning the system you can trick yourself into producing nice documentation that is much easier to keep updated later.

#1 Start with the data, don’t start anywhere else

I didn’t say start with the project plan, system documentation, email threads, interviews, test plans, or insulting notes about the system on the bathroom wall. The live data is the only thing that you can be sure is actually real in the beginning.

Show me your flowcharts and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won’t usually need your flowcharts; they’ll be obvious.

— Fred Brooks, The Mythical Man-Month: Essays on Software Engineering

I’ve found this quote to be true – your code follows your data and you will get further faster if you understand the basic nouns in the application first. Seeing an Order table with a StatusId field gets you along the road faster than trying to read a 2,000 line method:

void placeOrder(int? productId, int priceStructureId, decimal price, int priceSigDigits, int userKey, string userNameInternational, bool isA, object? requiredBlob, out long intRetVal1, out long intRetVal3, out bool multi)

So go ahead:

  • Create database diagrams to identify relationships
  • Begin drinking if there are no enforced relationships
  • Look at table sizes to identify transactional vs. configuration tables
  • Look at meta and programmable database constructs – sprocs, functions, jobs, indexes, linked servers, etc.
  • Begin thinking through the possible workflows – an Order table with OrderDetail which points to Product and PriceStructure implies that in the application someone is purchasing something and that prices vary.

#2 Use the application

If at all possible get a login to the application to view it as a customer does. You can’t always do this safely but you should try. Developers are always saying that the UI is the tip of the iceberg and that all the logic is in the back-end, but knowing the data model and having poked around the application will teach you the vocabulary of the system very quickly.

  • What are the main uses cases [verbs] in the application?
  • What nouns/entities that we saw in the data model are actually shown to the user?
  • Is there data shown to the user that wasn’t in the data model? [hint for the next step]
  • What doesn’t appear to be working or isn’t intuitive? Enjoy this perspective as once you learn the rest of the system you’ll lose it forever.

Tune in for the exciting – no electrifying – conclusion to how to analyze a system for fun and profit.

I’m writing a book about successfully working from home; click here if you want to know when it is complete.

The Three Laws of Robotics (for tech recruiters)

The tech market is so hot right now that if you are a developer and can tell the difference between O(n) and your own butthole you might be getting calls from aggressive recruiters. Recently I’ve had two recruiters that I’ve never met contact friends saying that I had recommended them for a position and I’ve heard stories of continued home phone calls, at-work phone calls, and all sorts of odd LinkedIn abuse.

I’ve heard many people say that recruiters don’t have much value, but I strongly disagree – we just need some agreed-upon moral boundaries. Let’s use Asimov’s Three Laws of Robotics [If you haven’t heard of these I’ll just hold on to your geek card while you go read that…]:

Law 1: A recruiter may not injure a human being or, through inaction, allow a human being to come to harm.

Harm means:

  • wasting my time
  • affecting my reputation
  • affecting my friend’s reputation

A recruiter shouldn’t hurt me, they should only help me and themselves in that order. Long-term it can work out for both of us; don’t affect my reputation negatively and I won’t affect yours either.  Some more specific ways they can harm me:

  • Submitting my resume to anybody without talking to me
  • Saying that you know me when you don’t
  • Talking to a 3rd party about me without us knowing each other
  • Being dishonest about the positions that you have in order to have a conversation with me

Law 2: A recruiter must obey the orders given to it by human beings, except where such orders would conflict with the First Law.

If I say I am not available at this time, don’t want you to do anything on my behalf, or would like you to stop calling me and crying into the phone – I mean all these things [But if I’m honest the crying does help me sleep].

Law 3: A recruiter must protect its own existence as long as such protection does not conflict with the First or Second Laws.

Of course there is a place in this world for recruiters and they should be allowed to make a living.  There is a lot of tech-recruiter-bashing but they are valuable for a hiring manager in that:

  • they can maintain a healthy pipeline of competent people [still up to you to find the people out of this pipeline]
  • they can filter people by personality [still up to you to detect people you don’t like]
  • they at times have a very good sense of the competency of tech managers (as they see loyalty from movement)
  • they can tell you who *won’t* work [they will filter out some incompetent people and some jerks]

They are also valuable for people looking to get hired:

  • they can tell you a good deal about the internals of particular companies
  • they can provide serendipitous events like connecting you with people that you end up working with later
  • they can help you get back out there after staying with one company for an extended time by giving you a feel for the market

We can even apply the later-added-4th law to recruiters:

Law 4: A recruiter must establish its identity as a recruiter in all cases.

Recruiters go to user meetings, tech conferences, social meetups, etc. I’m not sure if recruiters have gang signs (throw up a P for placement) but you should identify yourself as a recruiter to everyone other than the tollbooth operator that you talk to while you are working.

Following these laws will go far in re-establishing the reputation of recruiters within the technology industry.  Also: free pie mailed to my house.  Contact me for more details.

How to work from home without going insane (purple monkey dishwasher)

I’m writing a book about successfully working from home; click here if you want to know when it is complete.

So you’ve decided to work from home. As a rookie-veteran of working without a traditional office for one year I’m here to tell you that it is the greatest and worst thing that can happen to your work life – much like being transferred to a glitter-packing facility. What follows is a quick two minute guide of what you need to know before you take your pants off and turn up those old Hootie and the Blowfish albums.


Working from home completely changes your interrupt cycle. At a typical desk job you are interrupted constantly due to meetings, cake feasts, fire drills, people coming over to tell you about what the lake was like on Saturday, daydreaming about tripping said individuals, etc.

When you work at a location of your choice you can control what distracts you. If you want to work for 4 hours and not use the bathroom you can do it; if you want to work with 2 lbs of nachos taped to your face like a beard while wearing a sombrero filled with nacho cheese for snacking you can do this. Most people think they will be far more productive due to being able to control large blocks of time, but I found that the experience was quite jarring.

What you will realize is that outside of your normal distractions your body has learned to not focus for very long on anything. In my case after years of working in an environment where I was constantly interrupted I couldn’t focus on anything for more than 20-30 minutes (about the longest free period I had on average). I would internally interrupt myself constantly: twitter, facebook, doodling, trying to clean nachos that fell onto the keyboard from my nacho beard, calling the manufacturer of said keyboard after the ‘s’ key stopped working, writing a strongly-worded letter calling the manufacturer a bunch of “lazy jackae”, picketing outside their headquarters, etc. Typical stuff.

When you work in an office you don’t allow yourself to constantly be interrupted internally – you simply can’t watch every video that looks funny, you can’t read each article on The Morning News everyday, you can’t keep up with Hacker News like you think karma points are worth money.

The way to get over this is pretty simple – practice. I for one spent about a month making love to The Pomodoro Technique (meta: learning to make love using this technique is experimental and not recommended by most doctors) but it worked quite well for me in training my brain to recognize interruption events and stop them. Now I can go over an hour without eating a nacho.


When you have a ‘bad’ day at a normal job you still feel a sense of accomplishment – you drove to work, you drank some coffee, you attended a few meetings, you chatted with some co-workers about how little progress you were making – you did some concrete tasks.

Working from home alone you have days that you feel like you get *nothing* done. As soon as you get going you are interrupted, you spend a few hours working on something that you later scrap and start over, you can’t figure something out. These days happen in an office but when you are alone with them they create extreme emotions. The thing you need to remember is that one day like this can be followed by a sugar-rush Work-From-Home monster day: a day in which you get as much done in a day as you remember getting done in a week at BigCorp. An entire feature imagined, mocked up, coded, then just plain mocked, debugged, re-tooled, polished, stabilized, and then shipped.

Crippling Depression – ride it like a wave

If you work at home for long enough away from other real people you will be surprised how much you will miss the interaction. The annoying “did you see the game?” water cooler talk and “OMG Its Friday!!” chit-chat that used to make you want to hide in a conference room is actually a pretty effective social convention to avoid The Question: “Why am I working right now when I could be doing XYZ?”.

While working you will have many moments when you will think things like:

  • I work from home now, I could go take a walk – right now!
  • I work from home now, I could go eat some yogurt – right now!
  • I work from home now, I could ride a bike – right now!
  • I work from home now, I could watch The Wire – right now!

In the spring these thoughts are tough and you will stare out the window and cry a single slowly descending tear before turning back to your semi-colon delimited job and push through. In a normal office you don’t think about the difference between working and playing hooky because the threat of getting fired for playing Grand Theft Auto III at your desk is very real.

In addition you will need to take steps to keep in touch with others in your field less you become a Work-From-Home monster like many that I have met. Signs you are becoming cripplingly depressed without realizing it from working from home:

  • You see a former co-worker and talk for 20 more minutes than would be normal. Even after they have gotten up and left the stall you continue.
  • You are way too active on twitter, facebook, g+, etc. and constantly send videos to your friends like you work at Tosh.0.
  • You watch TV instead of listening to music and you talk back to the characters.  You think you hear Ferb talk back to you.
  • You drink Diet Pepsi just to let the pain make sure you can still feel something.

If any of these things happen put some pants on and go to a coffeeshop.

The greatest thing about working from home is your kids. They are also the worst thing.

This might be a personal problem as:

  • I work on the same floor of the house as my kids typically play.
  • My wife currently stays at home with the kids.
  • Before I worked from home I never listened to music while working (due to a deep-seated and irrational fear of being caught singing out loud a Jon Secada song)

I was very stressed with the noise of my kids and the general stress that kids cause when you do concentration-based work. I felt like a bad Dad because I would have to tell them 8 times that I wasn’t “done yet” but was just coming out to go to the bathroom, refill nachos, etc.

Once I realized that working at home meant more time with my kids I just mentally substituted the time spent in the car with time on the floor with them, and my stress melted away awkwardly like reheated queso.

Less informal communication means more organization

I’m an organic and an improviser. I’m not naturally organized. But working from home in the absence of informal methods of communication means that you need to have prepared the following:

  • a to-do list that you can share (workflowy, RTM, etc.) in less than one minute
  • a general daily plan that you can recite at beginning, middle, end of day.
  • a weekly plan of what you want to get done and what you did last week
  • a plan for when you will meet with the client, boss, parole officer next

Enjoy it

I know that at some point my work from home life will be put on hold or go away. And I decided when I started that I wanted to do a good job and to enjoy it enough that when I looked back I wouldn’t say that I regretted much. To remind myself of this I wrote “San Diego means a whale’s vagina” on my whiteboard (since this kinda isn’t the sort of thing you can do in a normal office).

So go – enjoy it. And please just go take a shower.

I’m writing a book about successfully working from home; click here if you want to know when it is complete.

Great discussion, as always, on Hacker News.

Republished on Lifehacker.

Fixing problems Part 1: Introduction and Attitude Adjustment

As DBAs, software developers, Homo Sapiens, and lovers we have to solve problems.  There is a common misconception that support is for the more junior folks on a team and thus being good at it is a sign of “being a little baby”.  While support is a great way to learn a software ecosystem and organization and thus “grow” a junior person into a senior one a lot of problem-solving falls to the rock star programmers or wizard DBAs in most organizations.

Yet some of these people aren’t any good at it.  In fact, they are awful.  I’ve seen people that are very good at doing very hard technical things – creating something from nothing, thinking of all the things that could go wrong, refactoring and integrating a large subsystem, etc. – fail at simply fixing a problem with an existing system. You can take your rock star and send them off to fix a support issue and they will return with a confused look, eight hours of wasted effort, a missing finger, and an STD.  Working with some truly gifted problem solvers I think that there are some differences in Attitude, Practices, and Skills that separate the junior and senior problem solvers.  Let’s start with Attitude.

First, there IS a problem

Never deny that there is a problem.  If someone is at your desk, on the phone, flooding your email with red exclamation points, or outside your house knocking on the window there is clearly a problem.  The problem might be that they don’t understand something and the problem might not be your fault, but the issue should be treated with respect as a real problem if they took the time to contact you.  Don’t deny it or argue.  Why would you deny it anyway, because you see support as negative.

Don’t see support as a negative shameful thing or a junior task

As long as things keep changing, there will always be problems.  (This next part is hard to put down in writing) If you aren’t writing bugs you aren’t writing software.  If you aren’t changing systems you aren’t working.  A support issue is not an insult, a bug is not a breakup.  Yes, you should make sure that you don’t write infinite loops, and yes you should make sure that you test the latest SQL Server upgrade before you install it in production at 10 am on the last day of the month.  But in most organizations there is a constant to and fro of creating new things and then fixing issues that crop up with them, so don’t pretend as if a problem is an anomaly.  True root cause and issue prevention are topics for another post, but don’t act surprised that software systems don’t always work as expected.


In my home office I have a fortune cookie taped to one of my monitors that says: “You have the ability to analyze and solve any problem”, and over time I have started to believe it (by looking at it 27 times a minute).  The fact is that most people that are good at support are good because they believe that given enough time they could fix any issue.  ANY issue.  Given 20 years and enough coffee they could learn C/C++, reverse engineer SQL Server, learn about cross-platform multi-threading, and fix that bug.

The ability to not freak out and lose it

Something is broken but don’t be scared (its just moving electrons for the highest bidder).  The fact that someone is at your desk and not someone else’s is a good thing, don’t panic and freak out and yell things that you’ll regret later (Aside: yelling is always regretted – only thing I’ve not regretted yelling “OMG ITs MILEY”). Don’t blame people or come off as condescending; assume that they are your desk because they know you can fix it, not because they think you caused it.  Figuring out root cause and a long-term solution are separate things; as are fixing and blaming.  You are in charge of fixing for now, so just focus on that.  Besides, over time a calm person is going to be relied upon more while those freakout will only end up on reality shows.

Next post – Practices that improve your ability to fix complex technical issues.

Page 1 of 2

Powered by WordPress & Theme by Anders Norén