Jones Melton

Mostly backend development and will do it in any language or framework. I love learning new things and if given the choice will always go for the unfamiliar framework. But I also find "use boring tools" to be a valuable guideline, and that the right choice for most projects is the technique that people working on it will already know. There is a contradiction here and navigating it is one of the more engaging parts of software work.

I've worked professionally in node, typescript, php, elixir. In my personal projects I use a wide variety of languages, simply to satisfy my curiosity and enjoyment of learning them. I find typed languages with strong inference to be a sweet spot for reliability and ergonomics, though any lisp is a lot of fun too. I originally learned to code in ruby and still love it, though I never got around to learning rails. I don't think functional programming is an inherently superior approach, but I do find it closely fits how I think in code so I lean towards it when it fits the problem.

I'm particularly driven by helping peers: automating frustrating work, empowering non-programming coworkers with code-adjacent tools, querying data to answer business questions, or building and improving development tooling. I've taught programming professionally and loved it, my ideal job would have a fair degree of mentoring or teaching in it. I have a bit of an affinity for legacy code, and genuinely enjoy working in legacy codebases, when given support and clear expectations within them.

I value working as part of an intentional team. I'm really fascinated by some research, and my own observations, that what makes for effective teams is a sense of individual psychological safety. When people feel comfortable showing ignorance and making mistakes, and know they won't be punished or shamed for it, they experience more freedom to accept challenges and attempt bold solutions.

I think most teams could benefit from more intentionality about their structure, process, and dynamics. It's easy to conflate that with formal process though, which leads teams to believe they already have or don't want it. I like thinking about and engaging in this literal team-building, and have always managed to have a positive impact, even as I've discovered that almost no single technique or process is universally valuable.

I consider full accessibility a requirement and build to wcag standards by default.

Not necessarily where I think the future is, but maybe. Certainly where my interests have taken me recently.

BEAM

The venerable erlang runtime, built with concurrency, error correction, and observability as first class concerns. Functional programming semantics with a message-passing model that makes it the legitimate successor to object oriented programming as envisioned by smalltalk. Its approach to processes and supervision trees directly solves some of the most common routine problems in backend development. Most applications that start to feel the itch for "distributed systems" would be able to directly address them with beam primitives. The comprehensive, disorienting, and charmingly roughneck standard library is an adventure all on its own. And if offputtingly esoteric syntax isn't for you there's elixir, one of the most successful language design projects going, with phoenix, taking the best ideas from rails and building them from the ground up around beam processes.

SQLite

It's the SQLite renaissance! What a cool project. Most webapps aren't and won't ever grow to be constrained by write concurrency, so a huge category of projects will never experience its only downside. In exchange you get a dead simple operations & deployment model and sub-to-single-digit millisecond queries for all the routine things websites do. Its reputation as being limited or small is completely unearned, it's a full blown db with aggregate, window, math, row value functions, indexes, generated columns, check constraints, json, ctes, fts, and a solid extension system with a full and growing ecosystem. Light enough to be an alternative to ini, heavy enough to be an alternative to postgres. Plenty of situations where it's not the right choice but always worth considering first.

Gleam

A new ML-family language with rust-like syntax that compiles to erlang or javascript. People seem most excited about the beam target but I love it as a more versatile successor to elm. Elm's model-view-update architecture on top of strong type inference is my favorite approach to UI in functional programming, and an incredible fit for complex web interface state.

I believe Hindley-Milner type systems in general are about to have a big moment with llm-assisted coding. My own experimentation has shown me that llms write much better code in languages that use global unification vs bidirectional inference and especially compared to local inference. llms produce working code with a lot less guess-and-correct using ocaml and f# than they do using go and typescript, despite relatively very small corpuses in their training data. Global unification places very strong constraints on the expressiveness of the language, which I suspect gives the llms less room to create problems.