brianm

Cue only really exists in go, and has a dependency chain to make maven weep.

I think cue is better thought of as a language you use to generate JSON (or yaml, or, let's be honest, k8s flavored yaml) configs rather than a config language you use in your app.

thought it was million monkeys consistency, so `/dev/urandom`

Huh, I got cottage core, not dystopia!

Not really -- non-profit boards are usually volunteers, even ion the non-profit has revenue used for operations.

I've seen a couple of cli apps recently take the path of "config file is long form arguments, minus the --, separated by newlines, overridden by actual arguments", so if you were doing `dsh` (which doesn't support this) it might look like

    verbose
    show-machine-names
    remoteshell ssh
    forklimit 4

TBH, I quite like it. Less to memorize, easy to know what to override, etc.

A coworker, once, had a cool idea to use Taylor Series to encode histograms for metrics collection. Basically a digest method akin to sketches or t-digests. We wound up using t-digests as Stripe (iirc) had a good OSS implementation at the time, but using Taylor Series has been lingering in my mind ever since.

Introduced by mutual friend

20 years ago I was in a very similar position, but it was perl I was writing instead of python :-) This advice is therefore dated, and exhibits survivor bias, but it is what I know:

1) Shore up your formal learning in at least data structures, databases, and architecture. I took night classes at the local community college, but there may be better ways now.

2) Find something to hack on where you get useful critical feedback both on your design approach and code. Critical feedback on your work hurts, but it is necessary to grow. Open Source can work well for this, as long as it is some project you actually use for something real(ish) so that the contributions you make are driven by your actual usage.

3) Network -- join local user groups, go to meetups, be curious and engage with people there. Folks are usually thrilled to rattle on about the stuff they are interested in, listen, ask questions, care.

If you have a decade of experience in some domain, look for ways to leverage that experience in a transition into tech. My first job in this career was as a technical writer and trainer, because my previous career involved a LOT of writing, and I was good at it. My next job was at a company where I had a lot of domain expertise in their target market, so despite having limited technical experience in the role, I brought a bunch of domain knowledge to the table.

Learn both, you will eventually have to anyway, and it won't hurt your learning curve, in fact will probably help to see similar ideas implemented and expressed very differently.

beelink or minisforum have you covered

Most companies, in my experience, don't actually know how to make use of Staff+ engineers. I spent years at a medium sized public "tech" company just trying to help the company change engineering enough to make use of these folks, and we go to a place where we could... mostly.

FANG and FANG-model (anyone copying FANG engineering/product model) companies do it well and have the bulk of success cases. Look for engineering-lead companies first, product lead companies second.

A key question when interviewing is "how is the roadmap established?" You want answers where senior leadership establishes goals (strategic or metric), product provides their understanding of opportunities, and engineering decides what to actually do. Even then, there will be the common failure model of EMs doing the roadmapping, not senior (staff+) ICs, but you can tease apart how that works, as it is always going to be a mix.