Minimalistic Developer
Tags: markdown, git, minimal, productivity
Published: 2017-09-05 07:32:57

---
title: Minimalistic Developer
published: true
description: Simplify your work flow
tags: markdown, git, minimal, productivity
---

## Inspiration

The original inspiration to write this blog started with an earlier [post](https://dev.to/jlhcoder/the-power-of-the-todo-list) on dev.to written by [James Hood](https://dev.to/jlhcoder). 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,

1. Android Studio (obviously),
2. [pidcat](https://github.com/JakeWharton/pidcat) for logging,
3. [Android Tool](https://github.com/mortenjust/androidtool-mac) for taking screenshots

Besides that these are some apps I have installed and used on a daily basis,

1. **Evernote** for making notes and tracking my work
2. **Source tree** for version controlling
3. **Jayson**: A Mac app to view JSON files
4. **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

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,

![blog directory structure](https://s3-us-west-2.amazonaws.com/my-blogresources/screenshots/blogs_dir_structure.png)

I expanded on the idea and created a directory structure as below,

![dev notes directory structure](https://s3-us-west-2.amazonaws.com/my-blogresources/screenshots/dev_notes_dir_strucutre.png)

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.

## Making notes

Migrating all my notes from Evernote to Git repository at once is a painful task. So I am following this approach.

1. Any new notes will be written in *markdown* and commited to the repo.
2. 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)

## Tracking work

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.

![Work Log File Structure](https://s3-us-west-2.amazonaws.com/my-blogresources/screenshots/work_log_complete_structure.png)

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.

```markdown

# Plan for the day

- [ ] Task A
- [ ] Task B
- [ ] Task C

---
```

Once I add the plan for the day, I commit my changes.

```git
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.

```markdown

# 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.

```markdown

## 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
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.

```markdown

# 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.

```markdown
# 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.

![Sample work log](https://s3-us-west-2.amazonaws.com/my-blogresources/screenshots/work_log_sample.png)

Also this opportunity helped me to master the *git* commands by using them on a daily basis.

## Disclaimer

1. 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.
2. 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.

## Few tips

- 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.

![User Snippets](https://s3-us-west-2.amazonaws.com/my-blogresources/screenshots/user+snippets.png)

Please feel free to share your thoughts.