Sunday, July 19, 2015

My Daily Routine

For the past two weeks I have been following a daily routine, and I think it's been a success. At the end of this blog entry, I'll post the current version of my daily routine.

For anyone who doesn't have a daily routine written down, I'd highly recommend doing it.

I have always had a normal daily routine (more or less), but I didn't always write it down beforehand. By writing it down, you are forced to prioritize what you really want to do during your day. Unsurprisingly, most people prioritize doing positive things. It's similar to setting a new year's resolution in that most people aspire to do good things.

But unlike new year's resolutions, daily schedules are pretty easy to follow. In daily schedules, you are forced to list out tangible goals. Instead of resolving to do abstract things like 'lose weight', a daily schedule should have tangible work items like 'drive to gym' or 'go for run'. The constant reminder of a daily schedule makes it easier to stick to your plan.

But even if you find that you failed to do something in your daily routine, you can always shift things around to make it work for you, starting tomrrrow. For me, I found that I initially packed too many things into my mornings, so I shifted some things to the afternoon and it's been working better. If my priorities, commitments, or aspirations change in the future, I'm only 1 day away from revising the plan and trying out the new version. Hopefully, you can quickly zero in on the plan that works best for you.

Planning out the day in advance is important. It makes you more productive. There's less ramp up time getting started on something, because I already decided what I want to do next. I also worry less because I know that I sometime in the day, I will take care of everything I want to do.

To help me get through the routine, I use a bunch of tools. The most important ones for now are youtube (where I find home workouts to follow), anki (an android app which I use to create flashcards for studying Korean), and career cup (where I get programming puzzles to practice and study).

I'm now on the lookout for a simple Android App that I can use to help me follow my routine. If I can't find one that suits my tastes, I might just buld something myself. If so, I'll have to add it to my routine.

And without further ado, here's the latest version of my daily schedule:

  • 0630-0635 wake up
  • 0635-0730 study (these days it involves studying algorithms)
  • 0730-0800 workout
  • 0800-0810 shower and get dressed
  • 0810-0825 walk the dog while doing korean flashcards
  • 0825-0835 walk to work + listen to podcasts
  • 0835-1230 work
  • 1230-1300 lunch
  • 1300-1745 work
  • 1745-1800 walk home + listen to podcasts
  • 1800-1815 walk the dog while doing korean flashcards
  • 1815-1845 yoga and meditate
  • 1845-2000 dinner
  • 2000-2030 create new korean flashcards to study
  • 2030-2130 test what I have been studying in the morning (algorithms)
  • 2130-2200 miscellaneous
  • 2200 sleep (8.5 hours)

Sunday, July 5, 2015

Going Towards the Pain

I've noticed a funny pattern in my software development life. It is, Working on the worst things can be the best. Here's a story of one example in the pattern.

After a few years of professional software development, I was growing more and more dumbfounded at how difficult it was for us to deliver code. Our team was productive, but some things just seemed harder than they should be. For example, every time someone wanted to update an existing project or roll out updates, it seemed to require a lot of manual handwaving, hope and guesswork.

My manager sensed my discomfort with this and told me to embrace it. She told me to think hard about how we can improve the quality of our software and begin attacking it.

I started by writing a best practices documentation that standardized things for our team. This included simple things like doing code reviews for any change, using branches for parallel development, writing good unit tests, etc ... I wrote scripts to help automate some drudgery. I wrote example code for our team to learn from and model. Over time, our team began adopting more of these practices and I think we have become more effective.

So, by attacking something that was causing our team pain and difficulty, (surprise, surprise) the problem was mitigated. Additionally, I found a lot of interesting things along the way. For example, I learned where unit tests worked best (and didn't work). In fact, the boring, mundane thing became interesting (to me at least).

In the process, I also became the go-to person for all things related to improving the quality of our software. By focusing on one small niche of improving the process of delivering code, I got to learn from a lot of other people who wanted to improve their code for their specific workflow.

I think this process of picking out something that you find annoying, painful, boring or generally sucky and then working towards fixing it is a good approach. It's sort of the opposite of following your passion.

In time, the thorn in your side might become your favorite pet project.