Remote: Yes, open to hybrid

Willing to relocate: No. Could be talked into commuting to Seattle.

Technologies: Scala, Java, Typescript, Rust, Python, AWS, Nix, (no)SQL, React, ML-style syntax

Résumé/CV:https://github.com/ccarlile/resume/blob/master/resume.pdf

Email: see Resume

Hello! I'm a functional programmer with lots of experince doing distributed systems in regulated environments. I left my job as Tech Lead in an extractive industry to seek roles with missions that align more closely with my own - I'm looking for opportunities to make a positive impact (in e.g. climate tech or med/bio tech). I'm also a "people person" so I'm happy to teach, lead, or represent as well.

The answer to this question is the same as the answer to "what if climate change is a hoax", and that is that I would love to be wrong and would gladly admit it rather than live under a dictator or on a dying planet

https://store.minisforum.com/products/minisforum-v3

[1] https://ditaa.sourceforge.net/

As for writing code and playing games, I use vim keybinds everywhere and play games with WASD controls. So nav keys aren't particularly critical either.

I actually use a mix of both. Project.el being built in means it properly leverages the built-in completion stuff, which has a level of awareness for the types of things I search and gives appropriate icons and context information (see all-the-icons-completion[1] for details). I fibbed a little bit about my workflow - to switch projects and find a file I use this:

  (defun project-find-file-from-projectile-project ()
    (interactive)
    (project-switch-project (completing-read "From which project?" projectile-known-projects)))

Indeed, in my global git ignore, same with other workflow-specific stuff that nobody else at $WORK uses

Projectile works OOTB with .git directories, so if you visit a git-controlled dir it's added to your projects. You can similarly specify other directories as projects by putting a .projectile file in them, and the contents of the .projectile file act as an ignore list.

So the workflow is work/myMonolith is the git controlled root, while I have work/myMonolith/frontend/.projectile and work/myMonolith/backend/.projectile. So I can use the project-scoped find file, grep etc. to inherently narrow the search space to that module. When I'd want to globally search, I'd use projectile-find-file (or grep, or whatever) on the myMonolith root.

The next step is to actually take that digraph and instantiate a bunch of packages on your system. Each package has its dependencies symlinked to it using env magic, and bubbles up into your shell session or whatever.

All the different offerings in the nix ecosystem are based off this idea. Home-manager focuses on user session environments, NixOS extends the concept to a linux system (e.g. systemd units are managed in the same way - its just another hashed object in the nix store that gets symlinked to systemd), NixOps lets you do it to other machines, and nix-shell lets you create per-project development environments.

Nix flakes are the next evolution in the ecosystem, where some of the "inputs" get taken out of your env where they were black-box magic and put into a flake.nix (with a pinned version locked in flake.lock) so the input package set is controlled for across builds.