For me, the hardest part of that transition was not thinking about a single problem as much in a single day. Like other programmers, I want to just keep hacking on the same thing all day, and that next little bit is just 15 minutes away and then the next little bit is just 15 minutes away and then I've missed lunch, dinner, and the sun is coming up.

Now, I have to spend time on a lot of things during the business day, so I schedule time for each of those things. If I don't get all the way through it, I stop at a good point and move onto the next thing. There is a little time spent changing contexts, but I can mitigate that by also taking a break between tasks to get a drink, get up to walk around a bit, make a couple of phone calls, and so on.

It sure feels like I don't get to program much anymore, and that I accomplish a lot less, but as a really good manager told me "if you finish one thing in a (business) day, you've done a lot". Most of the time I just keep other things moving.

The other trick is to solve non-programming things as fast as you can. Instead of going back and forth on a lot of discussion, try to make decisions earlier, or get the people you work with to make decisions earlier. Avoid digressions in meetings, stay on message, and get to an "action item". Keep meetings short and keep people focussed. Tell them at the start why you're talking and what you need to accomplish. I don't mean that you should cut out all small talk and banter, but as one of my co-workers has said "you're talking time is cutting into my fixing it time". People will talk as long as you let them and repeat things as many times as you let them.

Along with that, try to solve problems yourself so you don't have to hold a meeting about it. For instance, one contractor asked me "There's a bug in this module. Should I contact the author?". If he had just done that and gotten the fix (which the author sent right away), he could have kept moving on his work and wouldn't need to bother me about it. You can probably come up with a lot of other examples like that, and you need to take the initiative to get to the solution without bugging other people, if possible. Don't be a loose cannon, but don't let things involve more people than they need to. Given options, people will discuss them and you're back to the endless meetings from the previous paragraph.

Lastly (for this post), put off things you don't need to deal with right away. Some people are interrupt driven, so they deal with problems as they come up. The problem is that problems keep coming up, so their day is dealing with new things. Shove some things into the future: "Let's talk about this (tomorrow|next week)" or "Let's give it a day to see what happens". This isn't procrastination, it's two other things: triage (can this wait?) and distance (maybe this won't be such a big deal in a day). A lot of things seem like a big deal at the moment, but then turn out to be unimportant later on. Having a little patience and not panicing can often weed out those things. Not everything is software where you can just patch the source and commit the fix, so don't hold yourself to solving every problem immediately. For instance, in a recent contract negotiation, we were worried about a particular clause that might show up. Our contracts guy got in a big panic, but I told him to leave it to after the weekend. Over the weekend, the other side changed their mind and it wasn't a big deal. The extra time to think let the other side relax and think over their offer, and things weren't a problem. If we had pushed to solve it right then, they probably would have kept the problemed clause in that contract.

So, I've told you to spend time on everything you need to do, but also solve problems the first time, except when you should give things time. It's not a perscription for change, but it's something to think about. The only way to figure it all out is to get the wisdon that only the pain and sufffering of expereince brings.

Good luck, godspeed, and don't lose too much sleep. Small business sucks for everyone. :)

--
brian d foy <bdfoy@cpan.org>

In reply to Re: Time management, multitasking, and programming, oh my! by brian_d_foy
in thread Time management, multitasking, and programming, oh my! by Whitehawke

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.