jdreaver

This format really took off in the Python community in the 2000's for documentation. The Linux kernel has used it for documentation as well for a while now.

    $ perf record -g -F 99 ./my-program
    $ perf script report flamegraph

I can highly recommend a book called _Built to Move_ [0]. It tells you to do a lot of things that many people consider common sense, like walk every day, eat vegetables, sleep 8 hours, etc. However, it also explains _why_ to do these things pretty concisely. The most impactful argument it made to me was you can't counteract sitting for 12 hours a day with any amount of exercise. You have to sit less and move around more.

[0] https://thereadystate.com/built-to-move/

My experience using Emacs at work for the past 15 years has been outstanding. I find that when I join a new company, there is sometimes a bit of legwork getting Emacs working with potentially bespoke SSH, tooling, or VPN configs (for remote development), but once it works I don't touch it. I touch a lot of languages at work, including more I didn't mention above, and not having to leave Emacs to learn a new tool is a huge boon to productivity. I get all the niceties of an IDE via LSP and some other Emacs packages, including autocomplete, code navigation, Github Copilot, and more.

I don't ever tell anyone they _should_ learn Emacs at work, but once in a while someone sees me use it while screen sharing and they get interested.

However, for your question specifically, the choice of prior is less meaningful when you have lots of data, and presumably a web app seeing hundreds or thousands of requests per second can gather enough data to determine if the canary has a different latency profile than the deployed version within a few seconds. Also, presumably you would use an uninformed prior for a test like that. If I were trying to prevent latency regressions in an automated deployment pipeline I would just compare latency samples after 1 minute with a t-test or something simple like that.

Easily one of the most interesting and engaging textbooks I've read in my entire life. I remember barely doing any work for my day job while I powered through this book for a couple weeks.

Also, another +1 to Operating Systems: Three Easy Pieces [2], which was mentioned in this thread. I read this one cover to cover.

Lastly, Statistical Rethinking [3] really did change the way I think about statistics.

[0] https://www.nand2tetris.org/

[1] https://www.amazon.com/Elements-Computing-Systems-second-Pri...

[2] https://pages.cs.wisc.edu/~remzi/OSTEP/

[3] https://xcelab.net/rm/statistical-rethinking/

I'm sure you observed this, but concluding that RDS is slow as a blanket statement is totally wrong. You had to have had different database settings between the two postgres instances to see a difference like that. 3 orders of magnitude performance difference indicates something wrong with the comparison.

Even if you aren't a data scientist or a statistician (I'm an infrastructure/software engineer, but I've dabbled as the "data person" in different startups), learning basic statistics will open your eyes to how easy it is to misinterpret data. My favorite part of this course, besides helping me understand Bayesian statistics, is the few chapters on causal relationships. I use that knowledge quite often at work and in my day-to-day life when reading the news; instead of crying "correlation is not causation!", you are armed with a more nuanced understanding of confounding variables, post-treatment bias, collider bias, etc.

Lastly, don't be turned off by the use of R in this book. R is the programming language of statistics, and is quite easy to learn if you are already a software engineer and know a scripting language. It really is a powerful domain specific language for statistics, if not for the language then for all of the statisticians that have contributed to it.

The other large companies I've interviewed at for the past couple years definitely felt like they tacked on remote work because of COVID, and I wasn't confident it would last once the pandemic calmed down.

[0] https://aws.amazon.com/blogs/database/set-up-highly-availabl...

[1] https://aws.amazon.com/rds/proxy/

Exploring pgbouncer when you have lots of idle connections is a great tip, but 20 idle connections feels _extremely_ low to me. I've seen postgres databases on AWS Aurora serving over 13,000 transactions per second with hundreds of idle connections (because of client side pooling with a few dozen backend clients) just fine. In fact, around that scale is when we switched _from_ pgbouncer to client side pooling to simplify our architecture, and we noticed no degradation in any major metrics.

    package main

    import "fmt"

    func main() {
        closure := make_closure()
        fmt.Println("closure():", closure())
    }

    func make_closure() func() int {
        x := 1
        return func() int { return x }
    }

    $ go run main.go
    closure(): 1

> The downloadable version of DynamoDB is intended for development and testing purposes only. By comparison, the DynamoDB web service is a managed service with scalability, availability, and durability features that make it ideal for production use.

I don't think this is accurate. There are plenty of legitimate critiques against intellectual property, for example: https://plato.stanford.edu/entries/intellectual-property/#Ge...

However, a fun trick I learned recently is to tether your phone to your computer while installing any Linux distro. My phone's tether connection over USB just looks like ethernet (as far as I can tell), so there is less fiddling around. My Android phone can tether to my wifi as well, so no need to use your cellular data.

- Houses are probably 1/3 the cost of houses in SF (or the bay area in general).

- I can get to SF with a 50 minute flight and I live 15 minutes from an airport. This was a huge plus when I convinced my last job to hire me as the first remote engineer.

- I am in the same timezone as SF.

- The cost of living adjustments to my salary have been either zero or very small (like 5% less salary than an engineer in SF). Totally worth it in my opinion.

We have talked about moving to a cheaper CoL state entirely, but my whole family is in this city and it is definitely cheap enough. My wife is also a teacher, and teacher salaries in CA are much higher than in lower CoL states.

I interviewed at a few places at a senior/staff level, and most of my interviews were behavioral, architectural, or discussions about past work. The few leetcode-style or coding questions I had were easily prepared for from my ~40 hours of interview-specific coding prep.

There is zero chance I would have gotten those interviews or passed them without excelling at my job. My resume would have looked terrible if I didn't go above and beyond at my last role, and I would have given weak answers to some of the questions I was asked if I didn't have real experience with the subject matter or a relevant situation.

I think I understand why you have the perspective you have. Indeed, many modern software interviews can feel far removed from the actual job, and we all know that even well-executed interviews sometimes result in decisions barely better than a coin flip. However, unless you really enjoy leetcode, I can't think of anything more depressing than studying for interviews all day. Also, it is hard to prepare for interviews at higher levels (senior/staff) without actual experience produced by doing a good job.