ryankemper

Are you considering remote candidates in all of North America, or do they need to be based out of Canada?

(I'm based in the US thus the question)

  Location: Santa Barbara, CA
  Remote: Yes
  Willing to relocate: No
  Technologies: Kubernetes, Docker, Chef, Elasticsearch, Kibana, Prometheus, Python, Ruby
  Résumé/CV: https://github.com/ryankemper/resume_public/blob/master/Resume_RyanKemper_Scrubbed.pdf
  Email: ryankemper.cs@gmail.com
  Desired Role: Infrastructure Engineer, Site Reliability Engineer, Backend Engineer, etc

I've got strong experience operating Kubernetes/Chef-based production infrastructure, architecting/scaling Elasticsearch, monitoring&alerting, improving CI/CD, coaching developers/operators on incident management and development best practices, performing root cause analysis and blameless post-mortems.

I'm looking for a US-based remote position, or a on-site position in Santa Barbara, CA.

You might be interested in checking out this article I recently released on debugging:

https://www.ryankemper.io/post/2020-02-29-debugging/

This question is a bit hard to answer because programming with RSI just means that your input method is different. Which comes with a whole set of challenges, as your question implicitly recognizes, but I'm not sure that it makes much difference as far as your career moves are concerned.

I guess as a start, a big key is to find a job / company culture that promotes an asynchronous workflow more broadly. That way, you're not being forced to bang out a bunch of code under immediate time pressure, which would make having to use voice software feel frustrating. With async, it matters less if your raw input velocity is slowed down relative to someone without RSI, since there's no _immediate_ pressure.

None of that obviates the need to work hard and produce value, of course.

Disclaimer: I wrote this.

The intro already says this, but this article is about the high-level mindset of effective debuggers, as opposed to a list of useful specific tricks. I think the latter article is extremely valuable but (a) I don't quite have the raw experience to do such an article justice, and (b) I think the high-level philosophy of debugging has broader relevance across different languages, frameworks, or even disciplines (that is to say, one thing that struck me while writing this article is that the approach isn't just relevant to Software Engineers but really anyone who needs to identify and solve problems more generally).