HN user

jdreaver

1,206 karma
Posts2
Comments199
View on HN

I learned recently that Spain uses the same timezone as Germany (GMT+2 currently, according to Google) despite the GMT line passing through Spain. I've visited Spain and did feel like we ate late, but the timezone being "wrong" has made me wonder if it would have felt as late if I knew about their timezone while I was there!

There are plausible scenarios where a region can go down for days or more at a time, like natural disasters. I'm not terribly worried about a region going away _forever_, but during a regional outage long enough to start losing business, having data in multiple regions is important so you can restore in another region (if you aren't able to fail over quickly).

Huge +1 to this, but I would also add walking _at least_ 8000 steps per day. I still had some minor, nagging pain until I started walking more. Turns out humans are not meant to sit all day!

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/

EmacsConf Live Now 3 years ago

Most of my company uses VS Code or IntelliJ IDEs, which are officially supported by our developer productivity team, but many of us use Emacs and Vim (I'm an Emacs user). I spend most of my time in Go, C, Rust, and the plethora of "infrastructure"-related languages like Puppet, YAML, Starlark, Python, bash, SQL, etc. I also sometimes use more of the common languages in our company's stack like Ruby, Java, and Python.

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.

The book is a bit more foundational than that. It teaches you about Bayesian statistics, and discusses (among other things) why the concept of binary yes/no statistical significance is usually not the best way of evaluating a hypothesis with data.

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.

The Elements of Computing Systems: Building a Modern Computer from First Principles [0] [1]

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 agree with basically everything you are saying, except I think a sprinkle of rote memorization can go a long way in some domains. Whenever I read a math book, memorizing definitions and some key theorems helps me apply them in problems. With programming, however, I tend to do zero rote memorization.

I've used Aurora and the IO is much better there than on vanilla RDS. Postgres Aurora is basically a fork of postgres with a totally different storage system. Their are some neat re:Invent talks on it if you are interested.

RDS is slow. I've seen select statements take 20 minutes on RDS which take a few seconds on _much_ cheaper baremetal.

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.

I've read this book and taken this course twice, and it is easily one of the best learning experiences I've ever had. Statistics is a fascinating subject and Richard helps bring it alive. I had studied lots of classical statistics texts, but didn't quite "get" Bayesian statistics until I took Richard's course.

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.

Interesting, I know folks at Stripe that have been remote since around or before 2019, and one of the reasons I joined Stripe was because of the fantastic remote policies (hint: they are awesome). I wonder if 2019 was a tipping point for remote work at Stripe?

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.

+1 to both of these approaches. Maybe once per year we would have a query plan regress because of out of date column statistics. This happened on some pathological cases like tables that had old data evicted frequently. Once we committed to running VACUUM ANALYZE nightly on a cron, we never saw query plans regress out of of the blue again.

If you see idle is above 20 it's recommended to explore using PgBouncer.

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.

Making a closure usually requires allocation. For example:

    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 }
    }
This prints:
    $ go run main.go
    closure(): 1

If x were allocated on the stack, it would get nuked after we returned from make_closure(). In Rust you could move x to the closure, but I think in this Go example x would be heap allocated, assuming the Go compiler doesn't notice it can inline all of this and avoid allocating. Maybe assume a more complex example with a struct that had to be computed via a function argument or something :)

This is solvable with vanilla table design. Add a version column to the discounts table, make your foreign key point to (discount_id, version) instead of just discount_id, keep old discounts around. Don't mutate discounts, just add a new row with a new version. You can still group by discount_id and exclude the latest version for each discount if you want.

Ah understood. I thought this comment thread was talking about replacing _production_ AWS use cases with a bare metal system that has a compatible API.

I've installed NixOS over wifi a few times, most recently for a desktop that wasn't next to my router and that I didn't feel like relocating to connect via ethernet. The fully featured install ISO (not the minimal version) comes with a GNOME desktop environment and you can point-and-click to set up your wifi for the install.

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.

I have lived in Riverside, California my whole life (about an hour east of Los Angeles), but I've been working remotely for companies in SF for the past 5 years. There are a ton of advantages over living in SF:

- 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.

Absolutely. I work at Stripe now. In fact, I wish I only interviewed at Stripe (hindsight is 20/20), because I would have done zero leetcode prep. It is well known that Stripe interviews are much more practical than FAANG interviews. The leetcode prep was definitely necessary for some of the FAANG interviews I did.

I did it over 4 weeks. I have two kids, so I spent about 1-2 hours per day. I usually did some reading or a couple leetcode problems in the morning before starting work, and a couple in the evening. Honestly, once you do about 20-30 problems, they start to feel the same. I found that if I treated each problem like an interview and slowly walked through a solution (versus just diving into code and mashing Compile over and over until I get it), the problem ends up being easier.

This is inconsistent with my experience in my most recent round of interviews.

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.