I'm building inconsequential projects for fun and learning. The more inconsequential the better. -- lived intentional irreverence

---

---

Howdy. I'm Nathan, a.k.a. Skenvy (which started as my mid-2000's online gaming alias, and just stuck).

This is my "personal" GitHub account that I use to delineate from my "work" GitHub account.

Degreed in Computer Engineering, Maths and Geology; I've spent several years working across a range of technical roles: FPGA development, product support, Azure apps, "consulting", and data engineering. Since 2020, I've worked as a hybrid at the intersection of "DevOps" / "SRE" / "Cloud" / "Platforms" / "DevEx".

"Take your victim developer as you find them."

It's worthwhile applying the "eggshell doctrine" [+] to your peers - assume every engineer / developer comes with their own peculiarities, sensitivities, and ways of working, and figure out how to collaborate with the person actually in front of you, rather than some idealised version of yourself.

Have you ever wanted to start a cult?

In the software development space, there's already a variety of cults to choose from!

The Cult of Done

The "Cult of Done" is a nice set of quip-based motivationals, if those would help you. I first encountered it on NoBoilerplate @ yt.

The Cult of Done Manifesto

1. There are three states of being. Not knowing, action and completion.
2. Accept that everything is a draft. It helps to get it done.
3. There is no editing stage.
4. Pretending you know what you're doing is almost the same as knowing what you are doing, so just accept that you know what you're doing even if you don't and do it.
5. Banish procrastination. If you wait more than a week to get an idea done, abandon it.
6. The point of being done is not to finish but to get other things done.
7. Once you're done you can throw it away.
8. Laugh at perfection. It's boring and keeps you from being done.
9. People without dirty hands are wrong. Doing something makes you right.
10. Failure counts as done. So do mistakes.
11. Destruction is a variant of done.
12. If you have an idea and publish it on the internet, that counts as a ghost of done.
13. Done is the engine of more.

These are supposedly licensed Creative Commons by Bre and Kio, but I can't find a link to the original license. If you're reading this and you know the source of the original license, please submit it in a PR.

Usually writing yaml in vsc out of wsl.

Languages / Ecosystems

• Python
• Bash
• Java
• Yaml
• Make

• Ruby
• TypeScript
• C#
• PowerShell
• VHDL

• Rust
• Go
• Julia
• R

• Kotlin+Android
• Erlang/Gleam

The JS, TS, Node ecosystem evolves so fast it feels like you're "always" learning it.

At least as important, if not more so, than the tools someone uses, is how they maintain their toolbox.

By which, of course, I mean, dotfiles! Take care of the tools you use, so they can take care of you!

1. julia-release: A github action to release a julia project in a way that feels more ideologically alligned with how I'm familiar with releasing, as opposed to julia's officially recommended release pattern.
2. dispatch-suggestor: A github action for commenting on PRs with a list of suggested workflow_dispatch triggered workflows to run based on what workflows it determines will run when the PR is merged.
3. Collatz: An attempt at a personal Rosetta Stone and collation of language-fu-isms, all attempting to achieve sort of the same thing, along with various general repository health examples, and learning github actions. There's probably more collatz repositories on GitHub than you could poke a stick at. This is just one of them. I picked the topic to match the goal of "personal Rosetta Stone" rather than the other way round. The choice of topic came from having a bunch of python scripts written years ago that went down a rabbit-hole, so I made this to make myself stick to KISS.
4. Sudoku: A java JFrame implementation of a sudoku solver I wrote circa 2013 and have been sitting on with the desire to one day convert it into an android app. The distinction between this and other solvers is that this tries to catagorise the difficulty of the puzzle by which tactics it needed to solve it, that is to say, it tries to solve it using only specific techniques, in order, without resorting to heuristics / brute force that would be unobtainable for a person.
5. dependabot-linguist :archived: A ruby package that can be used to have a guess as to what sort of dependabot configuration is appropriate for a given repository, with the primary use case of automating the configuration across multiple repositories without the need to manually investigate their contents.

• Honours Thesis (2017): ECDSA and ECDH in VHDL for FPGA

I communicate heavily through memes. See some here.