⚠ You’re missing out! This page is designed for newer browsers than yours. You will not get the Full Experience™. Please use a proper web browser!
Résumés are a terrible way of judging candidates,
so I’m doing something a little different.
I give you my eponymous work:
Here’s a little visualisation I made, summarising some keywords and their priorities to me.
Don’t worry if things don’t quite make sense in this; the weighting of things is not on any particularly rational or consistent scale. But it is in alphabetical order.
Categories: Languages Libraries Life Tools Other ← hover to highlightArch Linux C Christianity CSS Cycling C♯ Django Documentation Flask Git Go HTML HTTP IE 6–8 IRC Java JavaScript Linux Mercurial NSIS PEP 8 Perfectionism PHP PostgreSQL Pyramid Python Ruby rust-http Rust Shell Shell scripts Singing Teepee Testing Usability Vim Web Writing
OK, enough fun; if you’re progressing linearly, my formal education is next. If you just want to get to the meat, you might want to skip to my skills.
I completed year 12 at Nunawading Christian College in 2009 with an ENTER of 93.45.
In 2013 I completed a Bachelor of Software Engineering degree at Monash University with Honours. I was the top student in several units through the degree.
Yes, this part was a little bland and boring. What you really want to see is the skills that I’ve got.
My skills in the world of software are quite broad, so I’ll separate them into different categories.
I’ve worked in many languages; I use the tool that is most appropriate to the task. I’m also always ready to try something new out—but here are some of the languages that I have worked with in the past.
Proficiency
My preferred and favourite language for 2007–2013. Until I got involved in Rust, practically all my personal coding was being done with Python unless compiled size was a problem or shell scripts were easier. (I still use Python quite a bit, but Rust has surpassed it for the position of “favourite”.)
I’ve been working a lot in Rust, an emerging systems language, since the middle of 2013, with my most notable work/contribution being the in the web ecosystem with rust-http and its successor Teepee, but I’ve been using it for non‐web things too. I’ve become closely involved in the community on IRC in particular.
I learned the language thoroughly and used it for a couple of personal projects, but decided that at the time Python and later Rust suited my requirements better. Overall, I still like Go.
I have several years of experience developing things like the PortableApps.com Launcher, plus some “normal” installers.
(Trivia: I suspect the PortableApps.com Launcher is the largest code base written in NSIS.)
It’s an esoteric Assembler‐like language which resists sound software engineering practices, but I tamed it in projects like the PortableApps.com Launcher.
I was an expert in all of this, but a few years have passed in which I have barely used it.
I used C♯ for a (one‐man) project at work, learning it on the job. I got quite a bit of mileage out of it, including digging into things like reflection.
Used basically in youth and more extensively at University. I’m entirely competent in the language (including Java SE 7), but significantly prefer languages like Python and Rust.
I have a good general understanding of C, but little practical experience.
I’ve written scripts from trivial to significantly complex, where shell scripts are an appropriate choice.
I have a general acquaintance with Ruby but have not used it much—I’ve tended to use Python for those situations where I might otherwise have used Ruby.
Python (python.org)
Rust (rust-lang.org)
Go (golang.org)
NSIS (nsis.sf.net)
C♯
Java (java.com)
C
Shell scripts (bash/sh)
Ruby (ruby-lang.org)
I grok the full web stack—frontend, backend, even to writing HTTP client and server libraries in Rust (rust-http and Teepee).
Proficiency
I am a very competent front‐end web developer and implementer of designs (I can also design—and enjoy the venture—but my designs are typically not as good as a professional designer’s).
I enjoy playing with new HTML5 features. I also enjoy hating older versions of IE (it’s decent now, though I still prefer Firefox).
I have some experience with JavaScript libraries like jQuery and Ext JS and interest in more recent frameworks like Backbone, Angular and Ember, but have not used these these latter tools beyond trivial things.
I’m also good with optimising web pages, libraries and applications, optimising code for size and speed of loading or execution.
I’ve worked with TypeScript, CoffeeScript, Sass, LESS and other similar tools in different projects.
I’ve used Django for smallish personal projects for over four years, a final year Uni project for CSIRO (sadly not public) and commercially with some quite advanced things like dangerous quantities of metaprogramming on top of Django REST Framework and Meteor integration.
I understand Django well.
I’ve worked in Pyramid enough to learn from and appreciate the differences in its design and used it in one prototype personal project. I have quite a fond spot for using traversal instead of routing.
I’ve learned some degree of Flask but haven’t applied that knowledge much. (All the concepts and designs are familiar, so it’s easy to finish picking up.)
HTML, JavaScript and CSS
Miscellaneous preprocessed languages
Django (djangoproject.com)
Pyramid (pylonsproject.org)
Flask (flask.pocoo.org)
I am familiar with and proficient in both Windows and Linux; I am also familiar with (though to a lesser degree) Mac OS X. My preferred operating system at present is Arch Linux and I use the i3 window manager.
I am furthermore familiar with the package management conventions of both the Red Hat and the Debian package management systems, including some of their differing philosophies; I have worked more with the Debian side than the Red Hat side but have administered both.
I like working in the terminal (mostly zsh) and am familiar with the standard tools of the trade, make (including writing fairly complex Makefiles), grep, ag, wc, sed, &c.
I’m also happy working with Command Prompt in Windows when unable to use Linux.
I am a Vim man to the core (which is why I created gVim Portable for when stuck on arbitrary Windows machines), including being quite capable of writing plugins and various filetype configurations. I’ve written quite a few Vim syntax files and other filetype configurations over the years.
I use Git most of the time now, having eventually folded to social pressures. (I preferred Mercurial, but Git’s inertia is substantially greater; I still use Mercurial for some of my existing personal projects, though.)
I also have considerable experience with SVN and Bazaar and can use them both quite comfortably.
I tend to test my code fairly thoroughly, being familiar with and using the standard tooling for the environments (e.g. unittest and some doctest in Python, JUnit in Java).
I’ve played with TDD and BDD but never been rigorous in their use.
I can also test applications and systems thoroughly and systematically—or randomly—with a view to breaking them, generally quite successfully.
I document my code well with comments and do not like to leave a project undocumented.
I like to use reStructuredText for almost all non‐code writing—Python docstrings, full project documentation using Sphinx, general plain text content, &c. In practice, however, I have to write a lot of Markdown, so I grok that too.
In instances where I want more complete control, I will work entirely comfortably in HTML. (For reference, this résumé was originally written in reStructuredText, but as I developed it further I decided I needed more control, so now it’s in HTML.)
Of the full technical writing side of things, I have had little formal training but have always had interest and skill in the area and have learned much myself.
I have little formal training in technical writing, but I do have fairly substantial experience, including in the maintenance of such writing projects as a whole (my tool of choice, as mentioned, being Sphinx, as the best tool I’ve found for my requirements).
As a sample of my documenting work, see the PortableApps.com Launcher manual, discussed in my open source involvement.
I care about coding standards, following the prevailing style (assuming there is one!) on any body of code I encounter; when starting afresh, I also tend to use the prevailing style, following PEP 8 in Python, for example, as closely as I can.
That’s enough about my skills for now. How about we move on to my interests?
I have a life of my own; here are some of the things that I care about and enjoy.
A note on programming: this has been an interest of mine for a great many years; I’ve been programming since a very early age (around five or six, in BASIC at the time, and around ten for web‐related things). My two elder brothers and my Dad enjoy software development and work in the industry; all of us have been largely self‐taught, with little assistance from the others.
Next you might care to look at my employment history or my open source involvement.
Duration: November 2015–July 2016.
Précis: Senior Developer maintaining in-house tools, but also sysadmin, IT guy and client website troubleshooter.
In theory, I was a Senior Developer, maintaining the internal tooling and CRM that had all been developed over the past few years (mostly three years prior), as half of a team of two software developers in the company. I would have freedom to improve lots of things, decide what was best, &c.
In practise, I spent more time as a systems administrator (maintaining internal servers, Windows and Linux, that had been left to rot for three years and several Plesk servers with zillions of malware-ridden client websites), all-round IT guy for the office and troubleshooter of client website issues. Then I made the mistake of demonstrating competence in fixing up an extremely annoying issue that had been costing several hours per week—demonstrating PHP skill in the process. I never got any more peace and was tasked with projects with poorly-written Wordpress and Magento code bases.
Combining all this with a CEO who was quite difficult to work with, I resigned in the end, joining the truly absurd employee turnover statistic for the company (it had an annual turnover rate of over 100% for the past six years where records were available).
I hope you can commisserate with me.
Duration: March–October 2014.
Précis: worked on various projects for various different clients, mostly in Python/Django but also quite a bit in Node and with frontend development as well. Some of the Python stuff I did was fairly deep magic with class generation, metaclass magic, tying things in with Django REST Framework, &c.
(Since acquired by Synchronoss.)
Duration: January 2010–December 2012.
Précis: casual employee; initially a Software Tester, I later became a Software Developer.
I was a full‐time employee during University holidays and worked one day per week during University semester time. I was initially employed as a Software Tester but spread my work in other disciplines too; quite early on I designed a new set of icons for the flagship application, spatialNET, which still had quick‐and‐dirty line drawings at the wrong scale, mostly from the 90s (unfortunately, for reasons of inter‐office politics, these icons never saw the light of day), and worked on some other user interface matters. By mid‐2012 my job title was recognised to have changed to Software Developer. Thereafter I was working mostly in C♯ on a couple of different projects—making a graphing library and working in XAML.
In 2013 I did not work for them in order to cope with an increased University workload.
You can get more of a feel for the things I’ve done from my open source involvement.
I’ve always felt a strong connection with open source software, using it extensively and contributing to it. Here are some of my activities in the world of open source software.
This is not at all an exhaustive list of my open source involvement, but rather just a few projects I’ve had significant involvement in. Some further (but still non‐exhaustive) details of my open source involvement are available through my Open Hub account.
Since the middle of 2013 I have been working quite a bit with Rust in the Rust community; I’ve helped out in the IRC channel, done a little work on the compiler, improved Vim support for Rust significantly and done other odd jobs.
My most significant contribution for Rust has been rust-http, a full HTTP library, covering both client and server. For quite some time it was the go‐to HTTP library in Rust, with Servo in particular using it. It was far from complete, but was already a solid and fast HTTP library.
However, rust-http was an experimental work, and so I decided to redesign it from the ground up as part of the Teepee project (still led by me). Although Teepee has not progressed to any sort of usable state as I have gotten busy with other things, almost all of its innovations and novel features have ended up in Hyper, the HTTP library that most people are now using. Teepee is still being used for experiments in fancy usage of the type system and such, and from mid-July 2015 I have begun to resume it as an HTTP/2-first server library backed by mio (non-blocking IO).
User since 2006, involved since April 2007, real developer since April 2008, full developer and project/site administrator from 2009 until about 2011; from 2012, not significantly involved owing to not needing the project so much.
My biggest project is the PortableApps.com Launcher; I’ve done almost all of this project by myself, with another developer in with the 2.1 release. The bulk of it is about 8,000 lines of NSIS code and over 5,000 lines of complete documentation (written in reStructuredText using Sphinx).
Summary: Thousands of lines of structured code in a language and culture that made it hard and solved the world’s problems. Remarkably bug free.
PortableApps.com produces portable applications (i.e. standalone with no need for installation and leaving nothing behind) for Windows. At the time of the beginning of the PortableApps.com Launcher project, the convention had been to write individual launchers in unstructured NSIS (an Assembly‐like language with quite a lot of GOTO usage). This was clearly not scaling as PortableApps.com grew; bugs proliferated, useful features were dropped from new launchers as “too hard” and things were getting worse. I stepped in with the PortableApps.com Launcher, a universal, INI‐configured launcher. In it I developed good structure and encapsulation in a language and project culture which made such things difficult. In consequence, it gained traction and is now how all launchers are written. Bug counts have gone down enormously (fewer bugs have been found in the PortableApps.com Launcher than two or three of the old launchers tended to contain) and everyone is happy.
(The PortableApps.com Launcher is a very “stable” product now with no real work happening on it; this is mostly because I don’t tend to need to use unknown Windows machines any more, so I have largely departed from my administrative role in the project.)
As well as the PortableApps.com Launcher, I also wrote a fairly substantial manual for it. Written mostly in 2009, the culture of PortableApps.com did not (and still does not) encourage documentation, but I considered it part of the duty, if it was to succeed, and so documented it quite thoroughly. The anticipated audience was people already somewhat familiar with the concepts and implementation of the PortableApps.com Launcher.
The PortableApps.com Launcher manual was implemented in Sphinx.
What comes next? Well, we’ve gone right through this document, so you might want to go back to other sections; or perhaps you’re ready to email me!
You found it! I’m really pleased.
Well, if I were the employer hiring an employee, I’d have put things like this in for bonus marks for employees who found it.
(Along these lines, I’ve found tiny links leading to useful information, comments in code, even in one case a custom HTTP header. Now that last one impressed me the first time I saw it; I only found it by accident.)
Of course, I’m kinda not in that situation just now. But tell me and it’s very likely I’ll want to work with you. And hopefully you want to work with me!
Next step? Hopefully you want to email me and offer me a job or something.
Just for a bit of fun, I made it so that this document can either be mostly monochromatic or completely monochromatic.
Here, then, is the Magic Switch™:
Gone! Gone! The colour is all gone.
Smatterings of colour enliven the page.