// Internet Duct Tape

Getting to Deadline – Programmer Productivity Tips At Work (Getting to Done)

Workhacks

I am my own worst enemy when it comes to achieving my deadline goals. These are tips / reminders I’ve found useful through work experience.

Most of the tips are general, but some are specifically suited to programmers/engineers in situations with long compile/simulation phases (compiling is the act of building an executable, simulation is the act of running it to completion).

Do I follow these? Of course not. But I should.


General Office Productivity Tips:

Procrastination.

It comes down to inertia and momentum.

  • Understand the problem. It is very easy to avoid work you do not understand well enough to solve.
  • Break it down. Break the larger problem into smaller problems that conceptually you understand and can tackle.
  • Review milestones. They are closer than you might think, and it can be a good kick in the pants to think “I have to get this feature done by Thursday” instead of “I have to get this all done in three months”.
  • Prioritization. Do not starve a high priority feature for lack of understanding to feed a low priority feature you know like the back of your hand.
  • Just do it. Attack the problem, no matter how feeble the attempt. Even if you throw out the work, it increases your understanding. It is better try fail than to waste time on something unrelated. Like writing a blog post or checking the InterWeb. LIKE YOU ARE DOING RIGHT NOW.
  • Go for a walk. Can’t focus? Get away from your desk and stimulate the blood flow to your brain. A change of scenery can unplug a mental block.

Interruptions.

What is of concern isn’t the time lost servicing the interrupt, it is the time spent context switching back to the original problem. Interrupting someone in flow can take 15 minutes for them to get back to the point they were at before the interruption occurred.

  • Net connectivity. Close email, web browser and any messenger programs.
  • Answering machine. Forward phone to voice mail.
  • Office hours. If you are in a partial support role, set up “office hours” during the day where you will answer questions.
  • Meetings. Reduce the number of weekly meetings wherever possible.
  • Maximize use of time. Know what time of day you are most effective and schedule the interruptions/meetings to the time when you are not.

Environment.

The key is to create a work environment that is free of distractions so that when you’ve achieved flow you can maintain your focus on the problem at hand.

  • Noise. Noise cancellation headsets or headphones with music can cut down on the distracting nature of open concept cube farm hell. Be kind to your co-workers and never use a portable radio or your computer speakers unless you are working late alone. If you’re going to have an extended discussion with someone move to a break room or an empty conference room.
  • Temperature. Have a portable fan to cool down and a portable heater/sweaters to warm up if your cube doesn’t have ideal temperature conditions.
  • Snacks. Have food around so that hunger can be satisfied without leaving the building. Don’t let your belly be a source of distraction. Nothing that will rot should be left out of sight. Some good low-fat choices: apples, cans of tuna, microwave popcorn, turkey sandwiches (if you have access to a fridge).
  • Hydration. Have a bottle/cup of water on your desk that you can sip from throughout the day. The short term gains made from drinking coffee isn’t worth the long term loses on memory, dehydration, and the productivity lose from caffeine crashes. Non-caffeinated herbal teas such as peppermint can be useful for weaning yourself from coffee.
  • Clutter. I am not hypocritically recommending clean desks, but file away any papers that aren’t germane to the problem at hand. When it comes time to search the mountain of looseleaf, at least you will be looking at stuff related to what you are working on.

Manage Expectations.

The biggest secret to getting more work done is having less work to do.

  • Give feedback. Do not tell management what they want to hear, tell them what you think will happen.
  • Accurate Estimations. Develop your estimation skills so that when you say ‘task X will take Y to do’ they believe you.
  • Under commit and over deliver. Realistic schedules give room to do a better job instead of fighting to keep your head above water.

Avoid Burnout.

This is the most important tip. Meet the deadline in a sane manner. Ever waste half an hour because you were looking at the wrong results? Ever make a minor two character typo that drastically changed results and was very insidious to find because it ‘looked right”? If you were more alert that would not have happened.

  • Relax. Find the balance between enough stress to motivate but not so much stress that you lose the ability to see the simplest solutions and recognize time sinks before you fall into them.
  • Minimum overtime. An hour of overtime is less than a regular hour of work because you’re reducing your overall ability to produce when you don’t get proper rest. Find a balance between working hard and working smart.
  • Sleep. Don’t let thinking about work impact your sleeping. Sleep debt has to be paid off eventually. You don’t want to be useless during the eight hours a day you have to be in front of the keyboard.
  • Balance. Find a balance between work, health, activity, friends, family and hobbies. It will increase your overall work performance. You lose the ability to bounce back with age.
  • Don’t force alertness. Much like a sleep debt, forcing alertness with caffeine or other stimulates will eventually develop a dependency on them to achieve a baseline state.

Programming Specific Tips:

Complexity.

Don’t create more work for yourself than is needed.

  • Only code what is needed. If a feature ‘might be useful’ then code it later when it is necessary.
  • Simplest solution is the best solution. K.I.S.S. Every line coded is a line that potentially has to be debugged. Focus your debugging effort on solving the problem, not on debugging bells and whistles that don’t contribute to the deadline. More time is lost in debugging an unnecessarily complex feature then in designing it.
  • Notes to yourself. Put comments in your code with standard identifiers such as “TODO” and “FIXME” that you can come back to later to add the improvements you didn’t add the first time. Putting the date you added that comment is optional, but can help during a code cleanup (sorry, I mean “refactoring”) five years later.

Multiple build / project directories.

“Hey, can you check out the latest version of this file to see if my changes work?” Except it’s never just one file, and the changes never work the first time. Checking code out into your working copy is not just an interruption, but can lose an entire afternoon trying to re-achieve the state you were at before updating that “one file”. Having multiple directory trees (hard drive space is cheap) can remove this problem.

  • Working. What you currently have checked out any are working on. Only checkout code when you’ve already verified it works using the Stable/Branch directories.
  • Stable. The latest valid snapshot/tag of code that is known to work.
  • Branch/Current. The absolute latest checked in version of all code.

Decompose.

Problems seem more daunting when you can’t see the trees for the forest. Breaking it up into smaller tasks not only reduces procrastination, but it also can increase performance time.

  • Design assumptions. Create small unit proofs of any design assumption upfront so that you know the design will work before investing time and energy.
  • Strawman Integration. When rapidly prototyping a smaller subset of the design you are pushing the integration issues until the end. It is best to do an upfront integration of a strawman of your design to make sure there aren’t any major gotchas and then continue with the prototyping.

  • Reduce dependencies. Debugging a rapid prototype can be much faster because you don’t have as many sources of errors to look at.
  • Smallest solution space. Reduce the unit testbench to only what is necessary to run your prototype. The goal is to reduce the time between starting a simulation run and getting results during development. Keep the inherent downtime in your job from interrupting your flow. You shouldn’t have time to think about something other than the problem at hand (ie: Checking Slashdot. Checking this blog is okay).
  • Symbolic links. Set up the file structure such that you can run your small unit testbench in parallel with the main design, ie: symbolically link to where any files will exist in the real design. It may still be useful down the road when you want to isolate a problem.
  • Metrics. It is much easier to grab profiling/coverage metrics from a smaller testbench that you can iterate many, many times more often then the main design. The statistics might not be “real world”, but they can still be helpful.
  • Design for debug. Litter your code with error assertions when they receive unexpected values or hit unexpected states. If necessary add a debugging define so that these assertions can be turned off in the production code but turned on again when you encounter a problem. Assertions to test inputs and outputs for illegal values and raise a big red flag will save you a lot of time when integrating.

Parallelism.

If you have access to multiple CPUs or a server farm then use them!

  • Pipeline. If the compile/simulate/debug flow has dead cycles where you are “waiting for results”, then you can make use of those cycles by breaking the work down into distinct units that can be pipelined in parallel. This keeps you actively solving the problem instead of getting caught up in procrastination and servicing interrupts.
  • Tracking. Keep a piece of paper (or use your engineering lab book) beside your desk to write down reminders of where you left off in the parallel problems.
  • Don’t fire and forget. When you switch to working on the next task in the pipeline, periodically check the status on the first task to make sure that it is running properly.
  • Always run something. The goal is to always have something running in the background while you develop during the cycles where you would instead be waiting for results. It could be as simple as seeing if what you are working on compiles properly while you’re working on something else.
  • Organize. Use tools to keep the multiple tasks organized such as different workspaces for different tasks, tabbed terminal windows with different title bars, saved session views, etc.

Any other advice / similiar lists? Leave a comment.


Related Posts:

37 Responses

Subscribe to comments with RSS.

  1. Random Words said, on July 14, 2006 at 12:03 pm

    Tips on improving your productivity…

    Nice article on improving productivity,
    Read it  your self and pass it on to your collegues too…

    ……

  2. [...] Similar to my comments on the Pragmatic Programmer book earlier today, nothing particularly new in here, but everything is a useful reminder if you know it already and a good collection of tips if you’ve not seen them before. [...]

  3. rockwatching said, on July 14, 2006 at 8:24 pm

    First principle of war (according to some philosopher that I cant remember – maybe Liddell Hart) “Selection and maintenance of aim”. That will get you to where you want to be – cut out anything that does not contribute to your goal – the “deadline” in this case.

  4. Supermike said, on July 15, 2006 at 2:40 am

    This has been an issue that I’ve had to deal with personally as I am hoarding an open source startup software company project all to myself until my idea comes out. It’s been tough, and it’s taken 4 years. I’m on my third and final rewrite of the app, trying to make it better before its first release. I have a family as well and this occupies a tremendous amount of time too.

    I found that the best way for me to get through a project is to think of it only in features, not the big picture, and set goals to achieve those features. I sort features in a chrono order for how one would normally use the app, such as login, then main page, then click on something, then follow through with it.

    Unfortunately the problem with chrono use case order is that you may get depressed because you may be holding back 80% of the other features while you’re mired down in that one feature that got you stuck and made you think out things that were not clear in the functional specification. Once I realized that, I had to back away and switch gears to resort my goals by which features would make the most significant contribution to the project and work from largest feature to smallest feature. I can come back to that one feature that hung me, another time. I will feel more motivated when 80% of the app is written and won’t be so depressed about it.

    Key point for me was to start the project in chrono use case order up until about 20% of the features were complete. Then, switch gears and resort the goals by feature contribution level, starting with the most significant contribution to least significant contribution.

    I think this can work well in an office too because managers often come through, about the second week into the project, and ask, “Can we add a ton more features and get it done by the deadline?” or, “Looks like we’re going to have to shave off the project deadline by one month. Can you come in nights and weekends to pull that deadline off?” If you can deliver the largest feature set and still have some sort of presentation you can begin to walk through (thanks to the work on the chrono order use case), then it’s just the small details after that.

    If you’re stuck on a project, try my technique. Remember:

    - Divide the project up into features.
    - Draw a typical use case that uses a large set of features, great for a customer walkthrough.
    - Spend 20% of your time trying to build all the features that support that walkthrough. If stuck on a particular feature for more than 2 days, then skip it and move on if you can and still yet save face with an early customer walkthrough.
    - Spend the next 50% of your time acheiving features by largest contribution to smallest contribution.
    - Spend the next 20% of your time acheiving any feature you missed.
    - Spend the last 10% of your time working out any other kinks and bugs that you missed during the time you were debugging the project as you worked.

    And if you’re not using a project schedule, even something simple in a spreadsheet, do so and try to stick with it. It will improve your performance and your motivation as well.

    Last, I found that when you are behind on a milestone, that’s not the time to think of “I’ll complete one goal per day”. No, it needs to be at least “two goals per day”, even if you don’t eat, sleep, or bathe! Gotta meet those milestones you set or you might as well change that project timeline again.

  5. engtech said, on July 15, 2006 at 3:00 am

    Thanks for the comment, Supermike.

    And if you’re not using a project schedule, even something simple in a spreadsheet, do so and try to stick with it. It will improve your performance and your motivation as well.

    I previously blogged about some good free estimation tools at Painless Estimation Evaluated.

  6. [...] //engtech » Getting to Deadline – Programmer Productivity Tips At Work (Getting to Done) (tags: gtd productivity programming work tips) [...]

  7. greenlightsabers said, on July 15, 2006 at 6:12 am

    This is a good post… even though I’m not a programmer of any sort, I could apply this to my school study periods. Procrastination is my biggest enemy. :twisted:

  8. Happy-Coding said, on July 20, 2006 at 12:19 am

    Productivity

    Some nice tips for increasing the productivity of programmers.

  9. [...] (such as Getting to Deadline – Programmer Productivity Tips At Work). [...]

  10. engtech said, on July 28, 2006 at 10:08 am

    Found a good essay on the importance of reducing the development cycle at: http://raschontech.blogspot.com/2006/07/key-to-programmer-productivity-that.html

  11. Luis said, on July 30, 2006 at 8:52 pm

    As a manager of application development I am struggling with the issue of not knowing exactly what to do when programmers reporting to me miss deadlines. What do you do with the employee ? because of him missing a deadline clearly and stressed in the project plan the whole team looked bad by not been able to commit to the delivery of the new module version to our internal clients. Where can i find information on how to apporach this problem ? take disciplinary action ? if so what type of action ?

    thanks all

  12. engtech said, on July 30, 2006 at 10:11 pm

    That’s a tough one. It is always best to give positive and negative feedback as soon as possible to the event that warrants it, but hitting him with it right at that moment could be a demotivator when he’s still on the critical path.

    When I was a first out of university the same situation happened with me where I didn’t get something done on time. My manager took me aside after I finally completed and told me how he was disappointed in me, how I hadn’t given proper feedback that I was overloaded before I missed the deadline, etc. A shot across the bows like this can stay with them, especially if you incorporate into their performance objectives a component where they have to do some kind of skill training on estimation.

    One thing to remember is the next couple of times he does get things done on time is to take him aside and thank him. Managers sometimes make the mistake of only giving negative feedback and never positive feedback. Being in an environment with only negative feedback will make the employees work just hard enough not to get ragged on.

  13. [...] Getting to Deadline – Programmer Productivity Tips At Work (Getting to Done) [...]

  14. [...] Old most views in a day: 2006/07/14 with ~1220 views from Programmer Productivity [...]

  15. [...] Getting to Deadline – Programmer Productivity Tips At Work (Getting to Done) [...]

  16. [...] >> Getting to Deadline – Programmer Productivity Tips at Work [...]

  17. [...] 2006/07/14 – Getting to Deadline – Programmer Productivity Tips At Work (Getting to Done) [...]

  18. [...] I sure took my time writing part four of this series. It’s bad when you need to apply “Getting to Done” on your hobbies. In this part of the series I’ll be covering freeware applications, battery life and updating the firmware on your phone. [...]

  19. [...] Rands In Repose has a wonderful new article called “Trickle Theory“. He talks about having a mountain of bugs right before a ship date (I think we work for the same start-up) and how to tackle the impossible task. I’ve covered that a lot of what he talks about in Getting to Deadline, but I wanted to mention a couple of points his article raises about bugs. [...]

  20. [...] This is the evil twin of Getting to Deadline – Programmer Productivity Tips [...]

  21. [...] Programmer productivity tips [...]

  22. Motivating Developers « //engtech said, on November 04, 2006 at 3:08 am

    [...] SoftwareByRob’s Criteria for Keeping Your Developers Happy. Goes hand-in-hand with my Programmer Productivity Tips. [...]

  23. Darren said, on November 09, 2006 at 2:40 am

    Nice article, other than the ill-informed prejudice against caffeine.

  24. Heidi said, on December 10, 2006 at 3:50 am

    I realized I was distracted every time I got a new mail notification–just seeing the envelope was a distraction even if I didn’t stop to check the email. I tried not opening my email program at all, but that didn’t work since my to-do list often includes responding to emails. So I just turned off the “automatically check for new messages” part so I could respond to existing mail and use email for reference without being bothered with the random appearance of new mail. Now when I really need to focus on a project I only hit the “check for messages” button once or maybe twice a day, and only when I am at a stopping point.

  25. engtech said, on December 10, 2006 at 4:08 am

    @heidi: that’s the way to do it. It’s amazing how much we can get done if we turn off the web browser / email client. Directing all calls to voice mail for a 2 hr period is great as well.

    It’s all about avoiding the interruption.

    @darren: As I have a major caffiene-withdrawl headache at the moment, I’m going to have to stick to my guns on it. :)

  26. [...] Getting to Deadline [...]

  27. [...] writing project. This isn’t my first take on productivity tips, around a year ago I wrote a damned good list of tips for programmers and engineers. The tips I’m listing here are much more general and are useful to anyone who has a job with [...]

  28. einar said, on April 28, 2007 at 1:02 am

    Overall a good checklist. I do disagree somewhat with your Design for debug statement. Especially, “Litter your code with error assertions when they receive unexpected values or hit unexpected states.”

    I prefer unit test suites whenever possible, since they give you the same effect (assertions on values etc.) without messing up the code. If the code is littered in debug assertions it becomes less readable and thus makes it harder to understand and maintain.

    I’m not sure what your background is, but if you are not used to unit tests, and perhaps unsure of their benefits, I really recommend Pragmatic Unit Testing (I read the Java (JUnit) version). The content is short and to-to-the-point and although the examples are shown for JUnit, it deals more with when and how to test (regardless of which framework you use).

  29. semanticpool. » Productivity said, on April 29, 2007 at 10:39 am

    [...] nice tips for increasing the productivity of [...]

  30. [...] Motivating Developers SoftwareByRob’s Criteria for Keeping Your Developers Happy. Goes hand-in-hand with my Programmer Productivity Tips. [...]

  31. [...] Getting to Deadline – programmer productivity [...]

  32. [...] Getting to Deadline – programmer productivity [...]

  33. [...] Getting to Deadline – Programmer Productivity Tips [...]

  34. [...] Getting to Deadline – Programmer Productivity Tips At Work [...]

  35. 01 april 2014 said, on April 01, 2008 at 5:34 am

    [...] (bron: ‘Getting to Deadline’) [...]

  36. [...] from Internet Duct Tape: “Hey, can you check out the latest version of this file to see if my changes work?” Except [...]

  37. [...] Click here to start reading [...]


Comments are closed.

Follow

Get every new post delivered to your Inbox.

Join 281 other followers

%d bloggers like this: