About Slava Akhmechet

I currently work at Azure on distributed services. Before that I worked at Stripe, and before that I cofounded RethinkDB.

The RSS's url is : https://www.spakhm.com/feed.rss

Please copy to your reader or subscribe it with :

Preview of RSS feed of Slava Akhmechet

Linear algebra self-study

2024-05-12 09:18:24

I finished self-studying Axler’s Linear Algebra Done Right (3rd edition). I wanted to understand linear algebra and picked up LADR because it’s the most recommended book online. Some notes below.

After picking the book I found a corresponding syllabus online. I wanted one that has a clear reading schedule and homework assignments. The one I initially used was this one from Brown. I tried to follow the actual class schedule, but dropped that pretty quickly. Sometimes I ended up going faster, sometimes slower. I finished the course in three months– on balance about the same time as the original class schedule. The Brown syllabus didn’t cover the entire book, but I wanted to do more chapters. So when I was done I found another syllabus from Berkeley that covers more of the book, and did the remaining problems from there.

I did all the homework problems in Overleaf. There were a total of 197 problems assigned; I ended up finishing 167. There were 30 problems I couldn’t solve quickly enough and decided to move on. I’d like to come back to these, but have not done that yet.

I extensively used ChatGPT 4 to check my homework problems (the paid version; I found ChatGPT 3.5 isn’t good enough). Prompts like check the following homework problem” or critique the following proof” usually produce very good results. Sometimes ChatGPT was wrong in its critique. Typically, but not always, tinkering with the arguments to make ChatGPT happy made for better proofs anyway.

One edge case where ChatGPT performed poorly was proofs by contradiction. It tends to have a lot of trouble understanding those. A minor nit is that ChatGPT UI renders Latex correctly maybe half the time. When it does, the experience is excellent. When it doesn’t, reading the output is a pain.

Sometimes I needed hints to solve homework problems. For those I texted a friend with a math degree and he’d usually point me in the right direction (thanks Ryan!) I never found a prompt that would get ChatGPT to give good hints; my friend’s hints were always dramatically better.

In general I find myself bored with lectures, I almost always would rather read a textbook. But there were a few points where the material got especially difficult. For those I supplemented with these lectures from Penn State that are pretty faithful to the book. I must admit to occasionally phoning it in on understanding some proofs. Axler’s proofs are beautiful, but his proofwriting was a hit and miss for me. Some proofs flowed like a poem. Others sputtered. It was never too hard to understand the sputtering ones, but it did require a degree of conscientiousness I sometimes wasn’t able to generate.

Which brings me to the book itself. I have mixed feelings about LADR. On the one hand, Axler delivers. If you diligently read the book and struggle through the exercises, you will understand the material. And once you’ve understood the material (and often even before that) you can appreciate the elegance of the exposition.

This commitment to elegance makes the material more difficult to absorb. Some struggle is endemic in learning math, but it need not be any more difficult than necessary. Later I found Terence Tao’s linear algebra notes, which are roughly as rigorous as LADR but are much easier to understand. One plausible reason is that I found Tao’s notes after I’d already worked through LADR and understood the abstractions. But I don’t think so. It seems to me that Tao set out to minimize student confusion and Axler set out to write an elegant linear algebra book. Both texts achieve their respective goal.

How to send progress updates

2024-04-04 03:12:56

If you work on anything worthwhile, sooner or later people will care about it and will want you to send progress updates. These could be quarterly investor updates, weekly updates to your boss, emails to adjacent teams, etc. Here are tips on how to do this well.

  1. Understand your role, and with each update add to the body of evidence that you’re a good steward in that role. If people want your updates, they’ve entrusted you with something– a successful delivery of a product or feature, investment capital, company budget, their reputation, something. Convey that you value their trust and take stewardship seriously.
  2. Add a little randomness to the cadence. People think they want regular cadence, but they’re happier with bounded irregularity. For example, if you send project updates every Tuesday they will seem transactional and no one will read them. If instead you send updates every 2-3 weeks, your audience will look forward to them because they’ll assume you have something new to say.
  3. Know what your next update will be and work toward it (instead of coming up with an update when it’s time to send one). This is Headline driven development for an internal audience. If you don’t have a headline you don’t have an update, and you can’t generate good headlines post-factum.
  4. Always start with a one sentence TL;DR and a 2-4 sentence recap of the overall goals of the project. Assume your audience is smarter than you are, but is very busy and remembers nothing about your work.
  5. People love pleasant surprises, but these don’t come along often enough by chance. Within reason, deliberately engineer pleasant surprises so you can include them in your updates.
  6. People hate unpleasant surprises. Obviously, avoid these if possible. But if unavoidable, take two steps. First, talk to each person privately before informing the group. Second, deliver negative news in 2-3 escalating phases. For example, start by softly expressing the possibility of a problem to give people time to adjust. The next time, state the problem as fact. (But don’t do this if there is a genuine emergency or crisis.)
  7. Acknowledge changes explicitly. If you said a the last time and b this time, and b conflicts with a, you need to explain the inconsistency. People perceive acknowledged inconsistencies as cost of doing business, but unacknowledged inconsistencies as broken promises.
  8. Don’t insult anyone, accidentally or on purpose. I once wrote an update that said something along the lines of our engineers don’t know anything and therefore can’t ship, we need better engineers”, and sent it to everyone including the engineers themselves. It was factually true, but crude and unnecessary. Don’t do this.
  9. People want a steady hand at the helm. Your tone should reflect that. You want the text equivalent of pilot radio voice. (I know, I’m mixing my metaphors.)
  10. Many people (correctly) worry they’re being personally evaluated by their updates, so they sanitize every sentence to death. Don’t do this. Make it all about the work, not about you, and leave the evaluating to others. (I visualize myself in a third-person view physically separate from the work, and pretend my character is writing the update.)
  11. Know the top three questions your audience wants answered, and state the answers as clearly as possible.
  12. Add a dedicated section for worries and failures. Be honest, have good plans, and don’t panic. People are drawn to conscientiousness and vulnerability but repelled from haplessness and histrionics.
  13. The goal of updates is for your audience to know how your project is doing at any given time without having to ask you.
  14. Elon yells at Wall St analysts in quarterly earnings calls, why can’t I?” If you built a company with a market cap greater than the rest of its industry combined, you have my blessings to ignore my advice.
  15. These tips don’t work if you’re incompetent.

Headline driven development

2024-04-01 11:54:33

Here is a simple process for shipping software projects that works. First, decompose the project into a stream1 of headlines. Then pick an aggressive date to ship the first headline and work like hell to meet that date. Have everyone work only on one headline at a time– the upcoming one. Ignore everything else. Don’t work on anything that doesn’t help you ship the headline. Once the headline is shipped, switch to the next headline in the stream and repeat. That’s all, you can fire your agile consultant.

A headline is a very short sentence that contains only the highest order bit, with all the other bits culled. Imagine you bump into someone on the street after not having seen them for a few months and they ask what you’ve been up to. What kinds of responses work well in this situation? I trekked through Southeast Asia”, I switched jobs”, I got married”. Software release headlines work the same way. You can now rent VMs through an API, we rolled out FSD autopilot”, Treasury is available in India”.

Headline driven development works really well for three reasons.

First, headlines is how humans process change. If you ever found your users confused, your boss frustrated, your investors anxious, your peers indifferent– these problems go away when you organize communication around a stream of headlines. But it doesn’t work as an afterthought. Communicating through headlines but developing in some other way is like leading a double life. It gets too messy. So to communicate with headlines you must develop with headlines too.

Second, it makes it easy to ruthlessly prioritize. If you can credibly ship a headline without something, cut that something. For example, suppose you’re working on your Southeast Asia trek headline and you’re planning to visit six countries. Can you credibly say to your friends I trekked through Southeast Asia” only having visited five countries instead of six? Obviously yes. So one of the countries gets cut. How about four countries? Repeatedly go through this exercise and stop before the credibility of the headline is at risk. You want to do the minimum possible amount of work that still leaves the headline credible.

Third, the deadline effect is real. Most of the work in college happens at midnight before the project is due. The industry isn’t that different. So simulating class assignments turns out to be a very effective way to ship quickly. You need a discrete chunk of work, with an arbitrary deadline2, and a binary outcome. You get this with headlines– a headline has either shipped by a given timestamp or it hasn’t.


  1. I mean stream” in a programming language sense– an infinite list of elements with ability to pop one at a time.↩︎

  2. Advertise arbitrary deadlines to candidates up front and let self-selection do its magic.↩︎

Commit/bullshit ratio

2024-03-20 11:57:32

Big companies have all kinds of complicated ways to evaluate engineers. I’m skeptical that this is necessary, even at large scale. But that aside, I like the following simple system that works well and is yet to fail. Assign each engineer a commit/bullshit ratio. Then write off (or ideally fire) everyone whose ratio isn’t high” or very high”. Ignore everything else.

What’s a commit to bullshit ratio?

You already know what a commit is. It’s an object in git identified by a SHA1 hash that leaves the codebase in a more useful state than one before the commit was pushed.

You also intuitively know what bullshit is. It’s delays, bad taste, fighting a lot, being dogmatic, complaining, broken code, laziness, cynicism, activism, pedantry, entitlement. Bullshit is everything that makes your coworkers’ life more of a pain than it needs to be.

Everybody is allowed a little bullshit because if you only allow zero bullshit you can never work with anyone at all. But bullshit must be paid for with commits. The more bullshit you generate, the more commits you need to push. It’s not an exact science, but it doesn’t need to be. Everyone already knows. Think of a coworker and ask yourself– what is their commit to bullshit ratio? The answer probably leaps to mind. Maybe the answer is unusually high”. Or maybe it’s neutral at best”. Whatever it is, you already know.

This system is very easy to use. If you’re an engineer, keep your commit/bullshit ratio as high as possible. If you’re hiring and firing engineers, fire everyone whose ratio is lower than high”.