Earlier this year I started a new near-weekly ritual. I used a tool that I found useful in college for busy weeks. The fold calendar is a way of quickly visualizing a week and using it effectively. Here’s what the daily entries might look like:

Basically, it lists the events of the day in chronological order, with times if I have them. It lists the main project that I want to advance this week and a couple of smaller tasks that I’d like to get done. For context, I list the big things that are happening next week as well.

Why is this useful?

This tool is useful because it:

• helps visualize and use chunks of time
• helps with being spontaneous
• helps with being organized
• helps budget time and energy

Skip down to the last section to learn how to build your own calendar, or keep reading for more context.

Be productive (or not!)

The key to the fold calendar is identifying blocks of time that are prime for doing things, and listing the important things that I want to do.

I then look at the week and see how many blocks I have, what I need to get done, and what I want to get done. I estimate how long things will take and tentatively schedule some of the “must” items. For example, if I know that I have a small milestone due on Thursday, I will need to use one of the blocks before then to complete the milestone.

Sometimes I only have a few blocks during the week after scheduling everything else. When I realize this, I make better use of these blocks. “I won’t have another chance to work on this until next week, so let’s try to focus for the next hour and see what I can do.” It’s really motivating to me to know how many hours I have in the week to really devote to side projects. Typically there are fewer hours than I would have thought. If I’m not aware of how little time I actually have, I tend to squander this time or become despondent because I feel that I should be achieving more with my life. If something is going to get done this week, it probably needs to fit in the buckets I identified by making and using the calendar. I know how much time each bucket has, and so will start something that I think I can finish in the time and energy I have. This technique respects the spirit of GTD and could be useful with a personal kanban as well.

Balance

On the flip side, when I am aware the things that really matter this week, I can leave blocks unscheduled and then am free to relax without worrying about getting things done. It’s definitely important to have recreation, and having a large block of guilt-free, uninterrupted relaxation is great. It’s purposeful recreation—re-creation. Being aware of the time and using it to restore balance and energy.

Also, I think that this is useful in consciously deciding how to spend time. If I see a free concert go to, I need to decide whether it will be worth my time and energy to go. Having the fold calendar might allow me to see that I should do it because the second half of the week is pretty full and I will need to rest. It could instead indicate that the concert cuts up a huge six hour block that I could instead use productively.

It might be one of the most important tools for me to advance side projects. Most of the time, side projects don’t have a deadline. There will always be other things to fill up the time. If you don’t believe this, read the big rocks story. Zen Habits also has an article that is along these lines. So the fold calendar helps prevent the seemingly-urgent from nibbling away at the core time. The “week-as-an-integrated-whole” mindset is what separates the fold calendar from normal calendars. Daily planning is useful, but it’s easy to find excuses. If I don’t get something done today, there’s always “someday soon”. But if I commit to doing something this week and it still does not get done, there is probably a more systemic problem that I need to address.

Clearly the calendar is useful for remembering meetings and engagements. The “next week” field gives a little more context and frees the mind from worrying about things that are coming up.

Your turn

Ready to create your own flip-fold calendar? It’s easy and inexpensive to make with things you already have on hand. Here are some things to consider.

• Take a piece of letter-sized paper and fold it into eight sections.
• Label the first seven sections with the day of the week and date of Monday through Sunday
• In the eighth pane, list ‘Key Project’, ‘Smaller Items’, and ‘Next Week’ as sections
• Go through your calendars (work, personal, shared, etc.) and write down scheduled events as they happen throughout the day
• Schedule exercise, grocery shopping, laundry, significant other engagements, and weekly planning time
• Identify energy-sapping periods, try to minimize them, and budget pre- and post-recovery time
• Identify blocks of time that you can devote to projects, cutting smaller things

It doesn’t need to be perfect, it’s just a tool. Hope you find it as useful as I have!

Have you used a system or tool like this? What were your results?

Original article: A Tool for Your Toolbox: Fold Calendar

I have a large backlog of post ideas and musings that I write about, but there’s really no priority to the backlog. Any suggestions? Please leave them in the comments section of this post. I will reciprocate this offer if you wish.

Thanks for your time, I appreciate it.

Original article: Help Me Figure Out What I Should Write About

Journaling could include writing down a technique or rule of thumb used, a page of a book that was helpful in a certain area, or who to contact in a different department in case of questions in a specific area. Sometimes it could be something that went particularly well so that he can look back when times are tough and remember a time when he persevered. Other times it is something that didn’t go as well as he hoped. He also does this to clarify his own knowledge so that when he needs information he has a place to look, and for potentially transferring that knowledge to other people.

I recently tried experimenting with this technique. I suppose that I like writing, so this came somewhat naturally. I liked separating this from other writing that I do because it seems useful to have it all in one place. I am just capturing knowledge that I have gained from working on a project. Writing this down regularly is really helpful in writing documentation later because you explicitly state what you have recently learned. This prevents me from being blinded to what I learned and taking it for granted. It might be obvious to me at the end of a project why the build works the way that it does, but along the way I needed to learn a lot of things and make various decisions. So this seems to be a good way of documenting decisions for later understanding and analysis of results.

Here’s an example of something I wrote (sanitized):

20100203 - 1531

While a PDF is printing to file (which is an excellent way
to save paper), let me recount how I added a new
HelpPDFBuilder to the application.  I modified the
HelpApplication.exe.config file pursuant to the rest of the
file.  I added references in the code to the new class.
Then, I expected everything to work.  However, the changes
in the HelpApplication.exe.config file did not get picked up
by the application.  The problem was two-fold.  First, I had
commented out the post-build steps, which meant that the
config file did not get reexamined.  I uncommented these,
and it still didn't work.  The next problem was that I did
not then copy the newly touched config file to the bin
directory.  This process is clumsy, and it would be nice if
it was improved somehow.

I would say that this document should probably contain things that I would be fine with anyone reading. If I have a beef with a coworker, I should probably talk with them about it or write it somewhere more private. This just ensures that I am writing things down that are actually useful and won’t bite me in the rear some time later.

Documenting things moderately well also helps me because the next person knows more and has fewer questions. The insurance company mentioned actually has a process for transferring responsibilities on projects. Also, at the end of someone’s career there, they have a process for sitting the person down and doing a knowledge transfer exercise by having different people interview them. This seems quite interesting. It seems like a really good way to not lose information and has the side effect of validating the person’s career there and allowing them to tell stories that will live on for some time to come.

The key here seems to be writing things down that seem obvious in retrospect but are difficult to acquire. It doesn’t need to be in a complicated format (mine’s a text file) or take a long time. Maybe five or ten minutes a day of the most important things you learned would be of immense value when you or someone else comes back to a project in a year’s time.

Does anyone else use something like this? What did I miss?

Original article: How to Write a Work Journal

Experience

I’ll admit that I got a mulligan. It was a Ruby on Rails project for an internal tool. I hadn’t worked with that technology stack much before. I kind of hacked something together based on the requirements, and it worked fine. There were few tests, and the design definitely did not use best practices. But it worked.

Next, I worked on a six-month-long Rails project using mostly TDD. After that, an opportunity arose to clean up the internal tool and add some features.

It felt really good. I felt like I knew the environment so much better, and could see where problems in the code could be easily solved using better Rails or Ruby techniques. It was quite exciting. At times, I was surprised that the code actually worked at all. I think that most developers rarely get this type of opportunity unless they are on a maintenance project, and I do think it was a valuable experience to see the aftermath of my own coding.

Synthesis

But afterwards I came to the realization that developers shouldn’t feel guilty about producing software. There are always going to be new technologies and practices to learn, tradeoffs to be made, and hindsight clearer than the present view. Should I refactor this class now or later? Should I make this easily extensible, or are we truly not going to need it? What should we work on first to reduce the technical risk on this project?

After every book I read on a subject, I learn new techniques and ways of thinking about problems. But this shouldn’t stop activity in the present. I will never have one hundred percent of the knowledge I need, and the solutions that I come up will only satisfice the problem.

I’m assuming that developers are really putting their best effort forth. This doesn’t absolve the developer from learning from their mistakes or preemptively learning.

I’m just trying to say that developers shouldn’t feel bad because they didn’t know enough to prevent every problem or solve every dilemma in the best way possible. Seeing mistakes in the past for what they are just indicates growth. Getting it right every time implies skill stagnation or perfection. Which one is more likely?

Have you had an experience where you wish you could go back and change something on a software project? A time when you read your own code and cringed? Where’s the balance between getting things right and getting things done? Consider leaving a comment!

Original article: Guilty Developer Syndrome

// TODO: implement the foo module here
...
// HACK here be dragons
...
// XXX
...
/* FIXME:  late at night, I need some sleep */
...

One advantage of using these tags is that they are easy to search for and give an understanding of where the code can be improved. Most IDEs even have a special view to look for these kinds of things.

My personal view is that writing a comment like these basically says that I should do something. If it gets checked into source control then it’s a problem. I should either address this right now or create a task to address the problem in the future. In the rare case that something is urgently broken, it’s best to fix it and then immediately figure out the root cause and any ramifications, when the problem is freshest. Delaying just adds a time cost to whoever tries to fix this in the future. Maintainers need to ask, “Is this still relevant or important, and how do I fix it if it is?” The second option is to put TODOs into a standard tracking system for later analysis instead. What seems urgent to fix at this time might not matter much in the greater scheme of things, so this work should be prioritized like everything else.

TODOs are definitely not acceptable for commenting out large swaths of code that break the build. The build exists for a reason–use it as a tool for creating higher quality integrated code. If your code doesn’t integrate, it’s your problem to fix it immediately. Commented-out tests are worse than useless because they add to the codebase and are not kept in sync with the main development line.

As a tangent, I usually write a date and author in comments. Even though people can use repository annotations (svn/git blame/praise), it’s much easier to see how relevant this comment is.

// AJP20021116 - I'm not sure that this works for all values of N.

Hence, if you were working on a project and saw this comment, it’s clear that it immediately is probably out of date or just not that important if it hasn’t been fixed in the past eight years. If I’m still around, future developers can ask me to recall what I was thinking.

What are your thoughts? Do you use TODOs in your code? What do you use them for? Do they make maintaining a project easier or harder?

Original article: TODO: FIXME, HACK, and XXX

The staging environment provided by Git means that I have a local version control system that no one else can see. This allows me to take continually check things in without worrying about mucking up the general repository. I like this because I can make changes quickly and check in whenever I make progress and things mostly run correctly. This is great because I hate it when things are improving and then I make some boneheaded change to a bunch of files and can’t figure out how to get back to a working state.

When I’m ready to check into the shared repository (in SVN), I can do this as a separate operation. What’s nice is that I can squash, modify, and reorder local commits so that my development history is clean of the rabbit trails that inevitably pop up. Theoretically, the staging environment allows me to not need to run full test suites before locally committing to ensure that I don’t break the build. This was not really a gain that I utilized though.

The second advantage was quick local branching capability. This allowed me to have several streams of development going that were mostly independent of each other. This was invaluable for quick bug fixes, and helped when work was blocked due to a client member being unreachable. Another great advantage was the ability to have my master branch be clean and always be ready for a demo. Git branches differ significantly from SVN branches, in that they are much faster to work with, require less space, and, perhaps most importantly, Git offers better merging capabilities.

Everyone else on your team can still use SVN normally, and you will see their changes if you use the correct workflow. There are numerous sites that describe this workflow and variations of it, so I won’t detail this. Just Google ‘git svn workflow’.

Issues

Attention conservation notice: heavy Git nomenclature to follow, probably not useful for the casual reader.

I ran into a couple of problems that I’d like to discuss, and my final solution. One issue was that I developed for quite awhile in Git and then needed to put this into the client’s SVN repository. There are numerous risks that I should have mitigated by doing this as I was going along with the project. I did not commit against my better judgment because I thought that my code structure might change significantly. However, it never really did. In the future I won’t hesitate to do this now, as the pain of messing around with version control is not really all that high.

I initially was interested in keeping my development history around, but this turned out to be pretty hard based on some specific things that I did. I think that the main reason for this is that I wanted my commit messages to have the correct name and email. I’m pretty sure I changed this setting in ./.git/config, but something must have gone awry. Hence, I ran a one-liner at the command line similar to the following:

git filter-branch --env-filter "export GIT_AUTHOR_NAME='<my name>';
                                export GIT_AUTHOR_EMAIL='<my email>';
                                export GIT_COMMITTER_NAME='<my name>';
                                export GIT_COMMITTER_EMAIL='<my email>'" HEAD

However, when then subsequently running git-svn commands, I received this error: Can’t call method “full_url” on an undefined value at /usr/lib/git-core/git-svn line 425.

My understanding of what this error means is that git-svn can’t find a join point between local development and your remote branch. Running the git-svn init or clone commands sets this up correctly, but what I was doing messed it up. I think I lost quite a bit of time by not understanding that rewriting the history at the end (which I typically did) would cause git-svn to get out of sync. I also messed around with grafts for awhile, which probably didn’t help matters any. I think in retrospect I probably should have only rewritten commit history for commits that I did locally, and not mess around with grafts at all. This would have probably allowed me to just `git svn rebase` to keep my history and have a flurry of checkins with the right information. But at this point, I was alright with losing my development history since I had already spent a bit of time working on it.

Once I was ready to import my changes, I found the following process to be helpful. Basically I add SVN directories, sync with these directories, copy over the files in master from my local directory, then commit the changes and dcommit to SVN. First, let’s add the standard SVN layout to the SVN repo. If you’re worried about messing something up, doing this process locally first is helpful, and then doing it to a sandbox directory might be advisable. See this page for an example of the former.

> svn co <repo/folder>
> cd <folder>
> mkdir trunk tags branches
> svn add trunk tags branches
   A         trunk
   A         tags
   A         branches
> svn commit -m "Base directory structure."
   Adding         trunk
   Adding         tags
   Adding         branches
   Committed revision 1.

Then in a clean directory, you can execute:

# the --prefix=svn/ gives you remote branches prefixed with svn/
# which helps to namespace them
> git svn clone <repo/folder> -s --prefix=svn/
   Initialized empty Git repository in <folder>/.git/
   Using higher level of URL: <repo/folder> => <repo>
   W: Ignoring error from SVN, path probably does not exist: (160013): Filesystem has no item: File not found: revision 100, path '<folder>'
   W: Do not be alarmed at the above message git-svn is just searching aggressively for old history.
   This may take a while on large repositories
   r1 = <treeish> (svn/trunk)
   Checked out HEAD:
     <repo/folder> r1
> cd <folder>
> git branch -a
   * master
   svn/trunk

I’d modify your .git/config file to have the correct username / email if necessary at this point.

Then you can copy all of the files from your original working directory (the one where you did all of the development) except for the .git directory. If you copy this over, you’ll have to start all over again. At this point:

> git status
   # all of your files
> git add .
> git commit -m "Changes from my local repository."
   Created commit <treeish>: Changes from my local repository.
   ...

And finally:

# in case someone updated the SVN directory that you're working with (unlikely)
> git svn fetch
> git svn dcommit --dry-run
   Should see something about pushing to <repo/folder/trunk>
> git svn dcommit
   A file1
   # etc....

This should add your files in the trunk folder in the SVN repo. Hope this helps!

Original article: git svn

Stallings – Operating Systems – Fourth Edition
Friedman, Wang, Haynes – Essentials of Programming Languages – Second Edition
Cooper, Torczon – Engineering a Compiler
Elmasri, Navathe – Database Systems – Fourth Edition
Angel – Interactive Computer Graphics – Fourth Edition
Bishop – Computer Security
Ghahramani – Fundamentals of Probability with Stochastic Processes – Third Edition
Strang – Introduction to Linear Algebra – Third Edition
Gittleman – Advanced Java: Internet Applications – Second Edition
Russell, Norvig – Artificial Intelligence: A Modern Approach – Second Edition
Grimaldi – Discrete and Combinatorial Mathematics: An Applied Introduction – Fifth Edition
Weiss – Problem Solving using Java – Second Edition
Varian – Intermediate Microeconomics – Seventh Edition
Sipser – Introduction to the Theory of Computation – Second Edition
Gardner – Games for Business and Economics
Kingston – Algorithms and Data Structures – Second Edition

Original article: Textbooks For Sale

You can swap it with a different function that you use all of the time. I recommend switching it to the escape key. You can also change it to function as a control key. But why would you want to do this?

Benefits

First, the caps lock key is modal, which means that much mayhem can result from misplaced keystrokes with the caps on, especially when working with complex text editors. There is little visual and no tactile feedback on the state of the caps lock. This inevitably leads to annoyances when the lock is on. There’s a reason that login dialogs always warn you when the caps lock is on.

Regardless of your text editor preferences, you stand to gain quite a bit from making this change if you use the keyboard even to a moderate degree. Imagine that an annoying dialog pops up and instead of clicking on the close button or invoking alt + F4 or sliding up to the Esc key, you can instead quickly disregard the window with a mere slide of your pinkie. When an application informs that you have unsaved changes on closing, pressing escape is a lot faster than figuring out which of the buttons on the dialog correspond to “please don’t disregard my changes.”

If you’re a Vim user, you stand to gain much more utility from having the caps lock key stand for ‘escape’ instead. Firstly, inadvertent caps lock use will kill you in Vim. Most of the normal mode commands are case-sensitive, so instead of going down ten lines, you’ve just concatenated the next ten lines. Whoops. Second, escape is the function that you invoke to get from whatever mode they are currently in to the normal mode. You press escape a lot. The saving here comes from sliding your left-hand’s pinkie finger over a tenth of an inch instead of having your hand travel two or more inches. Over the course of a year you will save about eight million miles. Instead of using the crufty caps lock key, you can just select a section and press “U”, and then the section will be converted to uppercase. That’s if you don’t want to hold shift down for like five seconds.

On the other hand, if you’re an Emacs junkie or general keyboard user, you might consider remapping the caps lock key to a control key. This is probably still more useful than the caps lock, and moving it up an inch makes it more accessible.

If you don’t like it, you can always go back! You can also remap something you use even more rarely (like the scroll lock key) to function as a caps key. But I get by fine without any caps.

So how do you do this?

For linux, I would try this tip. Another good start is doing a web search or going to this c2 page.

Drawbacks

It takes about a week to get your muscle memory fully used to this. It takes longer if you have multiple computers that use different or default bindings. Once you get used to it though, you will be hooked.

If other people try to use your computer, they will be stymied in the unlikely event that they want to use the caps lock key for its intended purpose. So don’t let them use your computer.

Original article: Caps Lock Remapping

What is it?

The Pomodoro Technique is a system that Francesco Cirillo created and used when he was a student to help him focus. Staffan then used this technique successfully in software development, and believes that it can be applied to most things that people do. Pomodoro comes from the Italian word for tomato, which was the form of his original timer.

For the system, you just need a pen, paper, and a kitchen timer. I’m using this online stopwatch and using simple text documents to replace the pen and paper. The online stopwatch is nice because it has an alarm that rings through my headphones so I don’t bother anyone.

How do I use it?

So anyway, a pomodoro is a set period of 20 to 35 minutes in which you focus intently on the task at hand. After each pomodoro, you take a 3-5 minute break to stretch, relax, or just kind of space out. Nothing mentally challenging should be done. When you do four pomodoros back to back, it’s called a set. After each set, you should take a longer break (15-30 minutes.) This is an ideal time for lunch, running errands, making non-work related phone calls, etc.

The idea here is that the mind works best when single-dispatched, and that changing work habits to accommodate this reality increases effectiveness.

The more philosophical ramification is that instead of worrying about the passage of time (becoming), you simply work and record the activities. As Staffan says in a summary blog post:

Anxiety about not being done before some point of time is eliminated with Pomodoro Technique. One completed Pomodoro is the result. One more X marked next to the activity proves that I’m climbing higher. And the systematic reducing of interruptions gives me the opportunity to plan what used to be event driven actions.

I really think that this speaks to the sustainability of the work. Staffan noted that it reduces procrastination.

Before the pomodoro begins, you look at a list of tasks that you created at the beginning of the day and pick the best one to work on next. If you get distracted by an internal or external distraction, you need to 1) recognize and stop the distraction 2) write down the distraction so that you can reevaluate it at some point 3) get back to the pomodoro as quickly as possible.

Once a pomodoro begins, it must ring. This means that if you start working on something, you should work on it for the whole pomodoro. If you finish five minutes early, take the remaining five minutes and “overlearn” by ensuring you understand the solution completely. In the case of coding, perhaps you look over the comments to ensure that they make sense, or do some quick refactorings to make the code base more readable.

The first time I tried this, the internal distractions were quite numerous (“drink water”, “check bank balance”, etc.) However, once you can separate your desire from actually implementing the thing, your work goes a lot smoother. Really, this works with the Getting Things Done system by dumping things that seem important into another bin before actually dealing with them. However, if you don’t write down this distraction or review it in a timely manner, it keeps coming back. As David Allen would say with GTD, you need to keep the contract with yourself for it to be effective. But once you can file the distraction away, you are ready to get back to work!

Planning your day helps immensely to prioritize what you are working on. This is similar to sections of The 4-Hour Workweek that ask you “if you had a heart attack and could only work two hours today, what would you spend those two hours on and know that you had accomplished something significant?” When things come up during the day (which they invariably do), having a list of things that are important to you helps to put them in perspective. Moreover, by deferring things that are not really critical but merely seem that way, you allow yourself to get in a better rhythm. Ordering tickets to the show or emailing someone real quick might seem really important, but impedes your flow.

The system is simple, meaning that you get the maximum results for minimum overhead. The overhead in this case is winding up the timer and recording what you did. If you already track your time, the overhead is minuscule.

My thoughts

The greatest benefit to me is that instead of thinking in terms of fifteen minute or hour-long periods, I instead focus in terms of what I can do in twenty-five minutes. I think that this is a more natural time period and helps break tasks down a bit better, which helps with estimation. I haven’t gotten to the point where I have been able to estimate the tasks, but Staffan says that this is the next step. This makes sense, as it gives you feedback on how well you are estimating your tasks.

I also like seeing what my progress is like and where exactly I’m spending my time and doing a retrospective each day to see any personal process improvements. In a sense, the system is similar to the Personal Software Process promoted by SEI.

The hardest thing for me so far has been dealing with external distractions (other people. ) I shut off auto-alerts on emails. If there’s anything that can’t wait about twenty minutes, then that person should have called me or walked over. But it’s kind of tough when my manager walks over to chat about work. I can’t just say, “hey, come back in 16 minutes and I will have time for you.” So the result is a major interruption, which cannot be filed as a pomodoro (“a pomodoro is indivisible.”) I don’t have a solution other than to either seriously tell the important person to come back later or to just accept that there will be large but important interruptions at times and to optimize the whole by accepting them.

Part of my early success might lie in the fact that I have primarily been working in a non-team environment since I started the experiment. I found that often focusing for a few more minutes than I normally would have gives me additional insights and I solve the problem quicker. Moreover, taking a quick break helps to clear the mind. Often I see something in the first few minutes of the pomodoro that I missed at the end of the previous one. Staffan also suggests trying this for pairing, with similar results.

I think the real takeaway here is getting in the groove and not spreading your attention too thin. I think that this has been a large realization for me in the past year or so.

Mindmapping

Staffan also suggests mindmapping to more intuitively understand your day and to let the creative side of your brain work. Perhaps I will write more about that in the future, but here’s one that I created that I thought was representative and noncontroversial.

Original article: The Pomodoro Technique

Leaving one (and only one ) celebratory bragging comment saying that indeed, you are simultaneously a talented and lucky person

If you don’t want to leave your full name, just make sure that I can get back to or identify you via the email you put down (which is not shown on the page.) I think this will be an interesting exercise to see where potential delays are and to start a dialog on where we can try to remove delays in our processes. The description talks about code, but your answers don’t have to be limited to it.

Imagine that you had a magic wand that removed delays in your work. In other words, you’d do things the same way, but when you needed someone, they’d immediately be available. Perhaps your specifications or work description would be ready for the next task right when you got done implementing your current feature. What would happen if you didn’t have to wait for feedback from test or customers? In other words, as soon as code was written, you knew whether it worked or not. As soon as code was written and tested, a customer would tell you if it was what they wanted or not.

So the questions to answer are:

What delays would you remove? If you had to pick one, what would it be?
What would achieving this do for your productivity?
What is currently in the way of achieving this?

Original article: Removing delays — for prizes!