Time Check: 10 Minutes

12 Sep 2018 | Comments | tags: speaking conference

Last year, I wrote about my talk preparation process. I mentioned that I try to practice my talk verbatim a bunch of times, especially the night prior.

I have been trialling out a new strategy for my talks recently and I think it works really well.

During one of my practice runs, I keep a notepad beside me and jot down a few key slides in my talk. The more evenly-spaced out they are, the better. I then set a stopwatch (I use Timely), and start practicing.

Once I hit those slides I have written down, I put that down as a lap and jot the time down across the slide number. I keep on going until I finish the whole talk.


Keeping time (and please pardon my handwriting)

I try to do this at least twice – the more data points the better! I found out that my lap times tend to diverge +/- a minute or so on each iteration. Once I am happy with the general timing, it’s time to make the times official!

I then add the times to my speaker notes, making sure I use a BIG FONT so that it’s easy to read.


Time for a time check!

I find that having those time checks in there help make sure that I pace myself well during the actual talk. I tend to speak fast when I am nervous, so knowing that I am going at the right speed helps calm me down a bit.

I cannot rely on just the number of slides remaining, as some take longer or shorter than others (I had a slide during my talk at Mobile Refresh Wellington that took me two minutes to get through 😝). Having the time written down means I can concentrate on what I have to say without worrying about timekeeping in my head!

Bonus tip: Taking a sip of water helps calm down the nerves! Highly recommend to add “WATER BREAK! 🥛” notes as well.


Next Move

16 Mar 2018 | Comments | tags: bye

Today is my last day at Domain. After three years, seven months, and three days, it is time to move out.

I will forever be grateful to Domain for bringing me to Australia. Everyone has welcomed this tiny Filipina with open arms, helping me adjust to a new country (there were a lot of trips to the pub).


They also made me jump out of a plane

Our scrappy little app has grown so much over the years. I could never be prouder of what we have accomplished over the years.


We finally get 4.0 🌟!

We were able to share our Developer Story to the world, got a bunch of awards, get recognised as one of the best apps of the year, and launched a lot of features.


I spy with my little eye the Domain logo at Google I/O!

Since joining Domain, I have become a Google Developer Expert, vastly expanded my speaking portfolio, learnt how to bake, and most importantly, met some pretty great people. 😊

What a rollercoaster it has been!



That Thing About Commit Messages

03 Mar 2018 | Comments | tags: git

Last week, I was giving feedback to someone about improving the commit messages they write. I was very taken aback by their response – “it does not matter what the commit messages are”. Now this is confusing for me, mainly because I know from years of experience that having relevant commit messages is important.

Their argument was that change descriptions go into the pull request anyway, so they – not just him, his whole team – do not really care if the commit messages are vague.

I whole-heartedly disagree with this assessment. To illustrate my point, say we are looking for a commit that broke a feature. What I usually do in this situation is to look at the whole commit history to look for anything obvious. It is not very easy when the history looks like this:

😩😩😩😩 We can either go through each of the changed files in each of these commits. This might be too tedious, and the commit messages does not give us any clear idea if that might be the case.

I know this is a super-simplified example, but imagine combing through the history of a repo with five or eight or 20 or 200 contributors.

Going by their reasoning that all the details are in the pull request, I should go into Github and look at all the PRs from this time frame. How many would that be? And would you have to check out each of those branches?

git bisect would be helpful at this point. But if the commit messages were a bit more helpful, wouldn’t we have at least have an educated guess of which commit we are looking for?

By all means, feel free to write a dissertation on your pull request descriptions. Just bear in mind that if you move from one service to another, you would need to move all your pull requests as well. Otherwise you lose all context of your project’s history.

Logan Johnson wrote so eloquently about Square and how they write commit messages. If you are in the “Well that is overkill camp”, then maybe we can compromise by following this tip from @dzaporozhets: