Quartz 4

Chris Scott mentoring 2021-12-26

6 min read

Email

Hey man! Sorry for the radio silence and I appreciate you following up.

Things are good here! I’ve found an angle towards getting a start in tech that I think could work well. Honeycomb, a company that I’ve developed a burning nerd crush on, is hiring for a “Senior Support Engineer.” They do observability for distributed systems, so they’re supporting devs not laypeople, and although they’re probably going to put their foot down and insist on experience (the salary band is 120-150), an SRE twitter buddy of mine said I wouldn’t be wasting their time by applying, what with the CS degree and the 15 years in restaurants. I feel like it won’t work out, but if I can get a conversation going with them maybe I can sell them on hiring a “Junior Support Engineer.” They just did a Series C for 50M so they’ve got some flexibility, and I LOVE this company.

But in the likely event that doesn’t work, I think I may have found a good way in. Working support for a dev-facing company would be a great way to get started, especially if they’re using an ops-type tool that is in demand for the work I want to do. Hashicorp is hiring a support engineer, for example, and I suddenly feel optimistic that with the degree, the restaurant experience, and a few good projects, I’ll make it.

Looking at Honeycomb and how to get on there has finally made it clear to me that even in ops, the only good foundation long-term (and for a lot of companies short-term) is just to learn how to code my ass off. Honeycomb really is where I want to land eventually, even a year or two from now, and they seem to be a Go shop, so I’ve dived into Go and it’s been awesome. Turns out I had missed that ugly old C-style syntax, and I really do prefer systems languages, with their static typing and their compilers and their sub-millisecond run times (Go has benchmarking out of the box!). I’ve found a site called Learn Go With Tests that teaches Go using TDD, and so far it’s awesome. I’ve been pretty strongly drawn to TDD, and I think that intuition was right on: I far prefer the rhythm of it, and it feels more productive as well (which says a lot about how inefficient I am normally). I feel a certain contentment when I’m using it, and it gets rid of a baseline anxiety I hadn’t known I had. The TDD also forces a degree of engagement with the material that I haven’t gotten with any other approach, and if that continues there’s a blog post here for sure. Could be a great step for people trying to get out of tutorial hell.

Speaking of, I have gotten stuck on Memeslingers, I ran into auth0’s docs and couldn’t figure them out (my idea is to offer only a Twitter sign-in, as a way to ensure that people are only making requests for responses to their own tweets). I’ll check it again before we meet but that’s my main technical question: if I’ve got a site that’s a vanilla JS frontend connected to an API Gateway (HTTP not REST gateway in this case), how do I hook up auth0?

The recipe reader site (input a recipe and approx time of steps, and it reads you the steps at the appropriate times) is gonna be really easy once we talk through it: I realized the simplest thing to do is to handle the timer in the frontend, and just make the API calls at the given times. Polly seems to work pretty much in real time. Actually, I’m not even sure you need JS—it’s a POST call with the payload in the URL, so maybe you can just use HTTP? That’d be cool.

And the cloud challenge is really close to done. I need to do the CSS for the resume, and I want to implement a dev/prod environment, which will be easy with Terraform. I think I need to get the Cloud Practitioner cert before I can get a code review on their Discord, which is super irritating but whatever.

In tutorial land, I started one for the AWS Sysops Associate, a little Udemy one for Terraform, and I’ve got a big, professional-level serverless course that will be a month long and starts January 11. It was actually $600, but it was 50% off, taught by a guy I like, had glowing reviews from people I trust, and all in all was the epitome of one of the reasons I avoided boot camps: you can get better instruction by just finding good paid tutorials. We’ll see how it goes. The main thing I’m looking forward to is the stuff on workflow, which looks extensive.

So progress has been made, in my typically weird ADHD way, and I really am excited about the idea of getting in through a dev-facing support role. Oh! And! Let’s please take a look at the OpenTelemetry open source project, and see if we can find an issue for me to work on or a plan for how to get to contributing. I’d like to make observability the vertical part of my “T-shaped engineer”, and OpenTelemetry is the foundation of where observability is going.

So I guess a tentative agenda would be:

  1. Talking about the support engineer idea—are there any fatal flaws to this idea I’m missing?
  2. Figure out how to hook up auth0
  3. Look at OpenTelemetry and see if we can find an issue for me to work on (or other things I should do to get started)
  4. Brainstorm a big fun Go project, one with lots of concurrency stuff

I just had a thought—I could work through a big tutorial written in another language (maybe Wes Bos’s Gatsby course?) and just write it in Go. This could really be a good way out of tutorial hell for people if it works.

Notes

Auth0

if I’ve got a site that’s a vanilla JS frontend connected to an API Gateway (HTTP not REST gateway in this case), how do I hook up auth0?

OpenTelemetry issues

Let’s please take a look at the OpenTelemetry open source project, and see if we can find an issue for me to work on or a plan for how to get to contributing.

Go project

Like the idea of implementing another tutorial in Go, but the Gatsby course might not be a good one (unless you’re going to implement Gatsby itself). Maybe Wes’s Node course instead?

Start with something that doesn’t need concurrency. Something you’re more familiar with.

Todo

  • [ ]

Graph View