1. Programming languages
  2. Other technologies
  3. Documentation superpowers
  4. Natural languages

Grading scale:

10 You literally have written a book.
7 - 9 Expert, go-to person on this technology.
5 - 6 Solid daily working knowledge. Highly proficient.
3 - 4 Comfortable working with this, have to check manual on some things.
1 - 2 Have worked with it previously but either not much, or rusty.

I copied this grading scale mechanism from a failed Google interview ;-)

One problem with it is that I am always very hesitant to put a 5 on anything, who can not look at the documentation?

It is also hard to scope things right. Who can claim to be a C++ or Linux kernel expert, even if you wrote a book about it, since those are such humongous topics?

As a result, I haven’t updated this in a while, and things may be out of date.

If your project does something that interests me, I can what it takes to contribute. Tell me what I must know, how long I have to learn it, and I’ll call you back when I’ve mastered it.

Programming languages

Grade Name Notes
4 C / C++ Cheatsheets: C, C++, POSIX C API
3 x86 assembly, ELF Cheatsheet, Paging tutorial, Bare Metal
4 Python Cheatsheet
4 Bash Cheatsheets: language, POSIX / GNU utils
4 HTML, CSS, JavaScript Cheatsheets, Node.js, CoffeScript
4 Java Cheatsheet, school projects
3 Ruby, Rails GitLab contributions, cheatsheets: Ruby, Rails
3 GDB Cheatsheet
2 MySQL Tutorial
3 LaTeX, Markdown LaTeX cheatsheet, Markdown style guide, Markdown Testsuite contributions, Jekyll cheatsheet

Other technologies

Grade Name Notes
3 Algorithms Cheatsheet and implementations
3 Linux internals Linux Kernel Module Cheat
5 Git Tutorial
4 Buildroot Some .configs, Linux Kernel Module Cheat uses it a lot
3 OpenGL Cheatsheet and mini projects
3 Vim .vimrc + cheatsheet at end
3 Django Cheatsheet and mini project
2 Android Cheatsheet
2 OpenCL Cheatsheet
3 QEMU QEMU recipes, basic devices
1 Chef For GitLab Contributions
1 AWS, Heroku EC2, SES
1 Media formats Video, Images, FFmpeg
1 Networking Cheatsheet, basic POSIX networking

Documentation superpowers

I have the power to document stuff in a way that makes using them awesome.

If your project does something awesome, hiring me means that more people will be able to notice that it is actually awesome, and use it.

I like to do this in parallel to contributing new features, quickly switching between my “developer” and “technical documentor” hats.

This means of course that I will develop new features a bit slower than others, but I feel it is more valuable if end users can actually use your project in the first place.

My technique is to provide upfront extremely interactive and reproducible getting started setups that immediately show the key value of the project to users.

I back those setups with:

  • scripts that automate the setup much as possible to make things enjoyable and reproducible
  • a detailed description of the environment in which I tested: which OS, version of key software, etc.
  • a detailed description of what is expected to happen when you take an action, including known bugs with links to bug reports
  • theory and rationale on the sections after the initial getting started, but always finely interspersed with concrete examples
  • all docs contained in a Git-tracked repo, with the ability to render to a single HTML with one TOC
  • short sentences and paragraphs, interspersed with many headers, lists and code blocks

While I create this setup, I inevitably start to notice and fix:

  • bugs
  • annoyances on the public interface of the project
  • the devs were using 50 different local scripts to do similar things, all of them semi-broken and limited. Every new hire was copying one of those local scripts, and hacking it up further.
  • your crappy build / test / version control setup

Exploiting this skill, however, requires you to trust me.

When I tell to managers that I’m good at documenting, they always say: great, we need better documentation! But then, one of the following may happen:

  • managers forget that they wanted good documentation and just tell me to code new features as fast as possible

  • they don’t let me own the getting started page, but rather and expect me to try and fix the existing crappy unfixable existing getting started, without stepping on anyone’s pride in the process >:-)

    This makes me tired, and less likely to do a good job.

    Good documentation requires a large number of small iterative reviews, and detailed review of every line is not always feasible.

    Too many cooks.

A prime example of this ability is my Linux Kernel Module Cheat.

See also my articles for further examples.

Natural languages

  • English: Cambridge CPE grade B in 2004. Proficient, with minor defects in collocation / pronunciation.
  • French: TCF grade C2 in 2011. Proficient, with a bit more defects than English.
  • Brazilian Portuguese: Native speaker
  • Chinese: learning oral informally, estimated HSK 3