I’m a polyglot programmer, free and open-source software enthusiast and regular contributor from the Czech Republic1, currently based in England. Coding professionally since 2002.
If you believe you might want to hire me, see my CV/Résumé (PDF version), check my GitHub and LinkedIn profiles and the following sections about my strengths and quirks to get a better idea whether we’d be a good fit2.
Strengths
-
Solid background in Computer Science, studied3 at Masaryk University and Universität Wien.
-
Polyglot and polyparadigm. The languages I actively use today are (in alphabetical order): Bash, C, Elixir, Erlang, Haskell, JavaScript, Perl, Python.
On top of that, in the past I’ve used C++, Java, Prolog, Scala, TeX, and I can pick these up in no time.
With the exception of Prolog, I’ve used all the mentioned languages in a professional setting.
-
I know a lot about git, Linux, IRC, Jenkins, docker, PostgreSQL (and SQL in general), X11 window management, (La)TeX, bicycles.
-
Regular contributor to free and open-source software. My GitHub Resume lists my recent contributions and projects, and my Open Hub profile includes contributions before/outside GitHub. I’ve had my fixes merged to the Linux kernel, X11, Vim, and many other projects. Despite mainly focusing on my own projects and submitting fixes all around, I got trusted with a commit bit in fluxbox, xmonad, jenkins-job-builder4.
-
I’m deliberate about technical debt: embrace it when building a prototype, watch it (measure and track) when maintaining a production codebase, actively reduce it when taking over a neglected codebase.
This approach enables me to build products that sustain long-term maintenance and still be friends5 with those maintaining it now.
-
Instead of only treating symptoms (and, usually, increasing technical debt), I advocate finding the real root cause and treating that. Similarly, I always try to understand what I’m doing by reading manpages, reference docs and possibly source code, and not program by coincidence.
-
It follows from the above two points that I prefer a proactive approach to a reactive one. Operating in reactive mode outside of short-term crises is unhealthy and I’ll avoid such environments.
-
Whenever appropriate (i.e. not building a prototype6 or similar limited-use product), I value following good security practices, conforming to standards and other forms of doing things “the right way”, and I keep many of these in working memory, so it’s not much of a burden.
-
I can switch between being a maker and being a mender, recognize where others lie on this spectrum, and tell what projects are (in)appropriate for whom7.
-
When my code breaks in the middle of the night, I fix it, and I make pretty damn sure it doesn’t happen again. I don’t need on-call bonuses, I prefer to sleep well. Naturally, I try to avoid being on call for big chunks of code outside my control, as I can’t ensure my undisturbed sleep then.
Quirks
-
Not neurotypical: suspected ADHD (attention inconsistency), self-medicated with beer, coffee, exercise and afternoon naps.
-
The performance difference between my motivated self and my unmotivated self is hundredfold. If you manage to get me excited about something8, I’ll run circles around your 10x devs. If you don’t, I might as well take an unpaid vacation.
The consequence of this is that a full-time 9 to 5 arrangement won’t work for either of us.
-
Long, boring all-hands “meetings” (actually presentations) drive me crazy (literally). If effective written communication isn’t part of your company culture, I’m a bad fit.
I still value meaningful in-person interactions: brainstorming with a whiteboard or over a beer is hard to replace.
-
Obsessive about hardware/software choice. I need my 7-row ThinkPad keyboard, and I can’t be expected to install corporate spyware of any kind. If you don’t trust me to keep my laptop secure, why would you trust the code I write for you? By the way, the last time I had to reinstall Debian on my laptop was 2005 (netinst was 3 floppies back then).
Unsurprisingly, I’m a strong advocate of free and open-source software. I believe all software (and ideally also hardware) should be fixable by users.
-
I use Vim. I believe tabs are fine (but I don’t really care, consistency is more important anyway). I prefer IRC, and yeah, I’m that one guy from xkcd (my IRC client handles Slack threads fine, though).
-
Road/gravel/urban/fixed-gear/uni cyclist. Against cars in cities. Still better driver than many, though.
-
Not ready to relocate, I live with my wife near her university. Now that the world has returned to (new) normal, monthly travel to socialize/hack together is not a problem, and in fact quite welcome.
-
May need a sabbatical every few years. Took unpaid sabbaticals in 2014 and 2020.
-
Despite the .in TLD. It’s lisk.in because my GitHub handle is liskin. ↩
-
If you decide that indeed we are a good fit, feel free to contact me directly. I don’t mind LinkedIn, but the signal-to-noise ratio there is awful, so contacting me directly (and possibly hinting that you’ve read this) may be better. ↩
-
My study results: Bachelor’s degree programme, Master’s degree programme. Dropped out at the end. Didn’t get the degree, only the knowledge. ↩
-
No longer involved in some of these. ↩
-
Always code as if the person who ends up maintaining your code is a violent psychopath who knows where you live. ↩
-
Don’t you dare run that prototype in production. ↩
-
It’s really painful to watch makers trying to mend their prototype in production… ↩
-
I tend to get excited about things I believe are really useful. The shorter the feedback loop, the easier it is for me to see that something is useful.
Do I use it? Useful. Does it benefit my wife’s research? Useful. Do random people in the pub use it and ask me to fix something, and I can actually help them? Definitely useful.
On the other hand, if your idea of product management and motivation revolves around monthly all-hands presentations with pie charts and personas, or something that’s effectively isomorphic to that, I’m a bad fit.
I need short feedback loops. ↩