2016: year in review

This post is a retrospective on all the tech/geeky stuff I did in 2016.

Quill - Android app for bloggers

After obsessing over it literally for months, perfecting small details and so on, in May I finally released Quill, an Android app for blogs running on Ghost. The highlights of the app include a robust offline mode (indeed, it is "offline-first") and a strong focus on design.

It's been 7 months since launch, and users seem to ♥ it so far!

Learning-wise, this app also represented the perfect opportunity for me to delve deeper into design - I prototyped several designs and iterated on them before settling on one.

I intend to actively add more features and maintain this app through 2017.

Udacity's Android Developer Nanodegree

I graduated from Udacity's Android Developer Nanodegree in October, having started in December 2015. It's a set of online courses covering most aspects of modern Android app development, with the highlight being the great projects (for example, see this post about the 2nd project, where I also describe a simple architecture for offline-first apps) and the solid review/feedback system. See my (rather brief) review of the Nanodegree here.

Github contributions

I had a total of 431 Github contributions in 2016. Of these, most commits were to my own projects, Quill in particular. Other projects I contributed small features/fixes to included Mozilla's min-vid addon and the bold new Eve programming language. I even got a Hacktoberfest T-shirt for my modest efforts ☺

Github contribution graph

Automated testing

I learned a bunch about the dark side of testing in 2016. After reading a number of blog posts, watching several talks, and thinking a lot about it over a period of many weeks, one thing that stood out to me was that getting testing right is a lot more difficult than it seems. To list just a few traps—it is extremely easy to make innocous, but costly, mistakes in test suite design; to write tests with unclear value or structure; or to write code that is practically untestable because of too many dependencies (at which point most people reach for their favourite bludgeon: mocks and stubs).

This is why I've come to believe that it is far more important to, early on, emphasize a purposeful approach to testing and discuss high-level testing strategy rather than spend hours on cute little examples that teach the boring mechanics of testing like "Arrange, Act, Assert".</rant>

Anyway, if all of that was incomprehensible, here's all the nice talks that explain what I just said and more in glorious detail:

Related to testing, I learned how to use assertions effectively to document assumptions and unfinished code paths.

Taking interviews

At work, I conducted dozens of JavaScript and basic design interviews for a front-end role in our team. Interviewing seemed like a black art to me at first, but in time I got the hang of the important bits (big props to Nimish - our constant back-and-forth on interview format etc was invaluable to me).

One observation I've made through this process is that the conventional algorithms-heavy interview is a poor signal of job-readiness, especially for front-end positions. There are more direct ways to judge front-end development skills. For example questions like the following:

  • Explain a particular JS/CSS concept and its uses1.
  • Given a small, real-world UI problem, come up with strategies to solve it, and then implement one of them in JavaScript.
  • Given a set of (close to) real-world feature requirements, come up with a few different UI designs and discuss the trade-offs. Sometimes the requirements are intentionally vague or under-specified, in which case the candidate is expected to drive the conversation, as they would do on the job (my own work often involves talking to users).
  • Often a design interview like the above can be followed by an actual coding session where the candidate needs to implement a simple UI as discussed in the previous interview. The candidate is free to use an IDE, Google search, documentation, etc.

Tech talk

Since November we've started a weekly series of talks at my company. I gave a talk on how the Bitcoin blockchain works. It was quite fun—hopefully I will get to do more of these going forward.

Books read

I read 12 books in 2016, of which my favourites were Quantum; Sapiens; The Double Helix; and A Short History of Nearly Everything. One recent change in my reading patterns is that I seemed to have moved over to almost completely reading non-fiction, as opposed to 90%+ fiction 2 years ago. This was an intentional move, because I realized I tend to get a lot more value out of non-fiction books, and because I've probably simply run out of great fiction (of the kind I like).

2017 plans

  • Launch the next major release of Quill with Ghost 1.0 support, a better architecture, and automated tests for regression
  • Learn to make more kinds of design artifacts, especially vector icons
  • Potentially learn Elixir or React Native


  1. Sometimes I frame these in a different way - fix a bug in a given piece of code, which requires knowing that concept, or at least one out of several alternatives

  2. That's one of my favourite tech talks of all time, right up there with Bret Victor's Inventing on Principle and Rich Hickey's Simple Made Easy and The Value of Values

comments powered by Disqus