2016: year in review

By •  • tagged 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 uses[1].
  • 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 ↩︎