Opens in a new tab.

#include "about.h"

I work where APIs meet the people trying to use them.

I’m Elijah Skeirik, a developer experience engineer making complicated systems legible across contracts, SDKs, documentation, interfaces, and tooling.

I publish open-source work under the name Elias Michaias.

git log --format=work

Professional work

Most of the work is translation between servers and specs, technical systems and non-technical users, and capability and discovery.

current

Payabli

Developer experience

Jun. 2024–Present

I help own an API platform’s public surface across docs, contracts, SDKs, interfaces, and developer outreach. You can see that work in Payabli’s developer documentation.

  • Maintain developer documentation and the OpenAPI specification as living product surfaces, not end-of-sprint artifacts.
  • Maintain custom server SDKs across eight languages and work through the awkward differences between their ecosystems.
  • Investigate API drift and verify the contract between production behavior, the specification, generated surfaces, and docs.
  • Design and implement accessible, responsive UI components that make the documentation journey easier to navigate.
  • Build and maintain internal tools that turn recurring checks and editorial work into repeatable systems.
  • Work directly with developers, carry their friction back into the product, and close the loop with documentation or code.

previously

Mr. Electric

Full-stack engineer and generalist

Sep. 2023–Jun. 2024

Small-team software with a broad remit, direct customer contact, and no room for “another department.”

  • Built a TALL-stack and Filament admin system for interactive internal workflows used by non-technical staff.
  • Scaffolded and maintained the SQLite database, including schema changes and migrations as those workflows evolved.
  • Aggressively optimized accessible interfaces so the important paths worked well for the company’s actual target market.
  • Went out to jobsites and spoke directly with paying customers to find friction in the site’s user journey.
  • Turned field observations and customer conversations into changes across the website, internal tools, and marketing.
  • Handled branding and marketing alongside the technical work, keeping the public presentation and internal system coherent.

show_toolchain(&toolchain, &buf);

Technologies I work with

A working set spanning systems programming, typed functional languages, and the web.

principles --applied

Where I work best

I work best where system quality and someone’s experience of it are the same problem, whether the medium is a website, docs suite, API, SDK, or compiler.

struct principle principles[];
  1. .0

    Make it understandable

    Whatever the medium, the person using it should be able to form the right model.

    • Clear contracts
    • Useful defaults
    • Precise language
    • Discoverable systems
    • Honest abstractions
  2. .1

    Stay close to the other end

    Watch where the work gets awkward, then carry that evidence back into the product.

    • Direct feedback
    • Workflow research
    • Developer outreach
    • Field context
    • Short feedback loops
  3. .2

    Finish the experience

    Accessibility, performance, error states, and sharp edges are the experience.

    • Accessible UI
    • Responsive design
    • Performance
    • Useful errors
    • Fit and finish

ls ./selected-work

Proof, not keyword soup

Open-source language machinery is how I think when nobody has handed me a ticket.

All projects

cat ./selected-thinking

Free thoughts

Essays on what language tools reveal, what they hide, and how those choices shape a developer’s experience.

All notes
struct note the_humble_pointer;
CC++

The humble pointer

Just use the daggum &

note_read(&the_humble_pointer);

whoami --after-hours

I do, in fact, have a personality.

Outside work: type systems, C metaprogramming, algebraic effects, Kierkegaard, and old books. An unbalanced list, but a useful one.