I’ve been getting a little obsessed with chili oil. A little…lost in the sauce so to speak. Here’s some notes and general thoughts on chili oil. Chili Extraction There are two main ways of extracting flavor from chilies with oil: hot flash or slow infusion. A hot flash basically means you heat up the oil until it’s really hot, almost smoking , i.e. 375F. You pour it over the chilies in one dramatic swoop.

In so many of my conversations around career stuff, I reference “knowing how to play the game”. I’ve never thought to explain what exactly “the game” is, because when you’ve become acclimated, it’s just obvious, self-evident even. And no, this is not anything close to The Wire, so apologies if you expected me to talk about drug dealing. The game consists of figuring out any possible way to increase your resume to appear as impressive as possible.

I get rejected, a lot. Whether it’s for job applications, conferences, startup accelerators, mentorship programs, universities, I have gotten hundreds if not thousands of rejection emails. Each time they sting a little. I’m not gonna lie. I apply to stuff because I want to be a part of it and it sucks when that application is denied. It’s gotten easier to take rejection as I’ve progressed in my career, but it still sucks.

Aside: Sorry, this is a morbid post, so feel free to skip if you’re not into medical stuff. I, for one, rewatch way too much House MD (S6E22), hence this post I’ve been working at Vercel on porting Turborepo from Go to Rust. In this process, I’ve learned a lot. One particular lesson that I’ve found particularly illuminating concerns the dangers of dead code. The analogy that comes to mind is of crush syndrome.

I recently wrote a post about how you should embrace being an amateur. There’s one addendum I’d like to make. Often times this predilection that companies have for “professionalism”, i.e. rigid, slow processes, comes from a sense of importance. Every startup has to be a little self-important. That’s what gets employees and customers to buy into what’s honestly a pretty risky proposition. But this self-importance can backfire. If you believe that the mission of the company is so grand and important, it’s easy to be afraid of making mistakes.

Here are some principles of IDEs that I think are worth codifying: The principle of least navigation Navigating in an IDE is annoying. In text, sure, you may know all the fancy navigation shortcuts like C-a M-< M-f and so on, but it’s still a non-zero amount of typing. And when it’s navigating in a file system, that’s even more typing and searching. An IDE should minimize the amount of time spent navigating.

I’ve been working on a new programming language, Vicuna. I’ve detailed some of my thoughts previously. So how’s it going? Well I have a repository with a playground, a basic compiler, and a CLI. The compiler has a lot of the basic language features implemented, with a JavaScript backend and a simple type checker. I’m hoping to implement some form of imports, enums, traits and JavaScript interop, then I can start writing non-trivial programs in Vicuna.

I used to write a blog on CS advice for other CS students. What qualified me to write this blog? Absolutely nothing! What I harped on in many of my posts were what I called “academic participation trophies”, achievements your parents could brag about to their friends, but weren’t very useful for getting a job as a programmer, stuff like getting a masters degree1, having top grades, or graduating early. All of these sound vaguely impressive, but don’t actually matter for becoming a successful software engineer.

If you’ve discussed CS education or gotten a CS education, you’ve probably encountered this line. It’s often given as a retort for why a CS program is not centered on teaching programming. As a pure factual statement, it is absolutely correct: CS is not programming. Even as an overarching statement about CS programs, it is indeed correct: CS is not programming and therefore CS degrees should cover material that is not programming.

You don’t get paid to write dependencies. To an extent, I think everybody knows this. But it’s worth saying bluntly because people will not say it to your face. Instead they’ll attempt to say other, nicer things, like “don’t reinvent the wheel” or “not-invented-here syndrome”. But really, that’s what they mean. You don’t get paid to write dependencies because your users don’t care about your dependencies. Your users aren’t deciding to use your library on the basis of your node_modules size.