Résumé

I have fairly extensive experience in Rust, given how new it is. I've been working in Rust since before its 1.0 release; I've written libraries to parse data from smart watches, deployment tooling, monitoring tooling, documentation tooling and more.

I enjoy Rust for its strong typing, extensive crate ecosystem, and ability to accomplish high-level tasks while remaining low-level efficient. I find Rust (once it compiles!) tends to not break in production compared to other more popular languages.

I'd love to work with it again.

I have extensive knowledge of Python, and I've professionally worked in it for over a decade.

I've written backend HTTP APIs (using Flask, aiohttp, FastAPI) for tasks such as geospatial property UIs & searching, CRUD APIs; tooling; scripts; and more with Python. I have fairly extensive knowledge of the Python ecosystem.

While I enjoy Python for its ease to get things done, I also understand the problems a dynamically typed language can have in production; I have knowledge of Python's new type annotation system, and the tooling around that.

While I have not professionally done frontend development, I still find that even solely in backend development good tooling is indispendisble, and creating that good tooling requires & exposes me to HTML/CSS/JavaScript.

Shell scripting is a language with innumerable sharp edges. While I am not a proponent of the language, it is impossible to do extensive backend work with Linux and other *nixes and not run into shell.

I have knowledge of shell, and have used it for innumerable shell scripts, CI scripts, small tools, wrappers, etc. over the years. I have knowledge of its warts and sharp edges, and I have knowledge of the distinctions between POSIX sh and bash specific features. (And, due to the extensive use of macOS amongst employers, also specific knowledge of what features I must avoid on such ancient versions of bash.)

While shell has its place, I find that once tooling grows organically to a certain point, cutting over to Python is usually wise, and I have converted a number of such shell scripts into Python. (And often fixed significant bugs during the conversion.)

My experience with assembly is light: I am able to look a disassembly for amd64 instructions to determine performance or in the case that a particular instruction sequence is desired. (I am familiar with Godbolt.)

I also have some experience, though quite old now, coding for the Z80, for the TI-83+.

While I have extensive experience in “the cloud”, I wouldn't mind working in non-cloud environments such as self-hosted environments.

While I love cloud environments for their flexibility and wide range of services, the costs of continuously renting someone else's hardware are not lost on me.

I've worked with AWS's EC2, ALB, RDS, S3, Route53, and SQS services; as well as both IAM and IDC (and directly with IDC in an SSO environment), and more.

I've worked with GCP's compute, storage, GKE (Kubernetes), hosted PostgreSQL, pub/sub, IAM, and networking services.

I've worked with Azure's compute, blob storage, AKS (Kubernetes), ACR (hosted Docker images), hosted PostgreSQL, event hubs, IAM, and networking services.

I have more experience than I'd like with Azure support, too.

I've worked with a variety of Linux distros (though primarily Ubuntu), professionally.

I have solid experience in Linux (and other *nix OSes); I have solid experience in shell scripting, Linux itself, and how the operating system works, including low-level understanding of system calls, containerization, etc.

I also run Arch and Gentoo at home. 😉

I not only use git, I understand the fundamentals of it, and how it works.

I also have used SVN. (And … p4.)

I've worked extensively with Kubernetes.

I've not only run workloads on a Kubernetes cluster, I've upgraded clusters, interacted with clusters dynamically via the Kubernetes API (e.g., I have written workloads that manipulate k8s resources, e.g., by storing data in ConfigMaps.) I've used and worked with CRDs, though I have not designed a CRD myself.

I understand Kubernetes' design & resources well enough to teach the fundamentals to other engineers.

I used to run a Kubernetes cluster at home, too. 🙃