Software · programming · remote
David Dyck
Software engineer. I write programs. Remote.
I write software that has to survive after the demo. Not the version that looks finished in a screenshot — the one that still works when a field is empty, a request times out, or someone who didn’t write it has to change a line six months later.
The job is the product, the data, and whether the next person can read the code. I don’t pick a library as a personality. If a codebase already has a shape, I work in that shape. If I’m starting fresh, I pick whatever will still be boring to maintain in two years.
I work on macOS, Windows, and Linux because that is the actual landscape: different machines, different clients, different constraints. I don’t romanticize tools. A browser, a server, a database, and version control will get you most of the way.
Work
Selected work lives on the Work page — titles and links load from the project archive.
- Things that have to last Web applications that need to be maintained after launch, not just stood up for a walkthrough. View
- The part people click Screens that stay readable after the visual pass — including empty, error, and “this field is missing.” View
- The layer underneath APIs and the data model everything else sits on. View
I look for a clear problem, real users, and code someone else could inherit without a decoder ring.
How I tend to work
Ship a slice, then another
I ship in increments. A thin slice you can click is more useful than a complete plan that never leaves a document. You see the thing, you argue with it, we change direction before a month disappears into the wrong version.
Read it before you replace it
I read existing code before I rewrite it. Most systems aren’t failing because the original idea was stupid. They’re failing because nobody stayed with them. Replacing a mess you haven’t understood is how you get a second mess.
If you have a problem that needs an engineer, use the contact page.