The original inspiration to write this blog started with an earlier post on dev.to written by James Hood. In that blog, James mentioned that he was using “text files” for to-do list which I thought of ‘old school’ at that time. I also added a comment on how I use ‘evernote’ for achieving the similar purpose. Couple of weeks ago, I was given a bit of advice given by one of my senior colleague(who I respect a lot) at my work.
His advice was,
Don’t be too dependent on apps as you may never know where you will end up working in the future.
My senior colleage’s advice made me to read James Hood’s blog again. As I read through the blog and the comments, I started to re-think about my work flow and also consciously monitor the tools that I use and the way I use them on a daily basis. I use Macbook Pro(late 2013) at my work. As an Android developer, My primary development tools are,
Besides that these are some apps I have installed and used on a daily basis,
- Evernote for making notes and tracking my work
- Source tree for version controlling
- Jayson: A Mac app to view JSON files
- Visual Studio code or Sublime text to view text files
Besides my macbook, I also remotely ssh into our build and release server machines running ubuntu 14.04. I don’t actively write code on those machines, however I do write scripts on occasions.
The idea is to reduce the dependencies of apps by taking a minimalistic approach and solve the problem with simple solution.
I took James Hood’s idea of using text files for to-do list, and his comment about using private ‘git’ repo to back up notes.
So basically, I made two simple changes in my work flow.
- Use text files with markdown support instead of Evernote
- Use git terminal commands instead of Sourcetree
Earlier I had created a repo for my blogs and the directory structure is as below,
I expanded on the idea and created a directory structure as below,
Now all my notes, blogs and work logs are in one single place in my private repository. All I need is a machine with git installed and internet to access them.
The reason I chose to use markdown instead of plain text files is that markdown makes it easier to review the notes in the future. As you read through the blog you can see what do I mean by that.
Migrating all my notes from Evernote to Git repository at once is a painful task. So I am following this approach.
- Any new notes will be written in markdown and commited to the repo.
- Whenever I refer any notes from my evernote, I copy them to my repo in markdown format. (It’s a slow process, however I’m sure it will be done over a period of time)
Under the Work Log directory, I created a master to-do list markdown file, 00 Todo List of Tasks.md (Name begins with 00 so that it would be on top in the directory stucture when sorting) and also created a sub-directory resources to add the additional resource files like screenshots, log files etc.,
As the name implies the idea of master to-do list to serve as common reference point to add/remove/review the tasks and also helps to jot down any new ideas that popped up as I work.
I started creating markdown files (in similar style as writing blogs in some sites) in the format, ‘date_day.md’ So after two weeks of my work, it looks like as below.
I usually plan my day ahead either the night before or early in the morning. The tasks may come from the master to-do list or based on the meetings/emails/JIRA tasks assigned. Each Markdown file follows the below format when created.
# Plan for the day - [ ] Task A - [ ] Task B - [ ] Task C ---
Once I add the plan for the day, I commit my changes.
git add Work Logs/file.md git commit -m "Adds Plan for the day" git push
As I start the day at work, I prioritize the tasks based on the priority and start working from top priority task. Any new tasks that come up will be added to bottom of the list. At any time only one task(Current taks) will be marked as bold (using markdown syntax) in order to keep my focus.
# Plan for the day - [ ] Task A - [ ] **Task B** - [ ] Task C - [ ] Task D --- ## Task B - Task description/Link - Notes related to tasks - To do list of actions
I follow a strict rule of not jumping to the another task unless it’s top priority task or time sensitive. Otherwise I don’t start on another task until I complete or reach a checkpoint on the current task. Before jumping to the next task, I update the task with the completion status and if there’s anything pending.
## Task B - Task description/Link - Notes related to tasks - To do list of actions - Actions taken - **Actions Pending**
And I make a commit as below.
git add Work Logs/file.md git commit -m "Completes Task-D" git push
I repeat these steps until the end of the day. And at the end of the day it will look like this.
# Plan for the day - [x] Task A - [x] Task B - [ ] **Task C** - [x] Task D - [ ] Task E --- ## Task B ... --- ## Task A ... --- ## Task D ... --- ## Task C - Task description - todo list of actions - **Action pending**
At the end of the day, I review the tasks completed and tasks that are pending. The final work log can have only the tasks that are completed on that day, which makes easier to review the completed tasks in the future. Based on the progress and priority, all the unfinished tasks goes to either the next day or to the master to-do list. For example, the Task C may go to the next day and Task E may go to the master to-do list.
When moving the unfinished tasks, I copy the progress made so far for the task. So I don’t really need to refer the previous day notes again. Also the unfinished tasks carried over from the previous day helps to prioritize the tasks in the following day.
Benefits of the approach
The most obvious benefit that I got from this approach was that I no longer needed several apps. I can access my notes from anywhere as long as I have internet connection.
# Gradle Notes ## Gradle Wrapper - Wrapper is a small shell script that can download gradle if itsn't installed and can run tasks. ## Gradle Daemon - Runs gradle in the background. - Gradle creates separate JVM to run tasks. - Gradle daemon re-uses the JVM created earlier. ## Tasks - Self contained piece of work - Performs operations in isolation - Can depend on other tasks - Can have input & output
On reviewing my work log, it’s plain to see what’s completed on that day and what actions that I took.
Also this opportunity helped me to master the git commands by using them on a daily basis.
- You might lose some mobilty in terms of editing the notes from mobile devices. If you use your mobile phone for primary note taking purposes, this approach may not be helpful.
- There is a learning curve when it comes to git version control through commands. For some it may not seem like it increases your productivity. But you can install extensions/plugins to auto-complete the commands.
- I use Visual Studio Code with markdownlint extension which helps me to avoid markdown formatting mistakes.
- I also make use of User snippets feature in Visual Studio code. For example, here’s a snippet that I use for inserting code blocks in markdown files.
Please feel free to share your thoughts.