How bad would it be if your code broke? That’s a question I wish we asked ourselves more. Sometimes the answer is really really bad. If you write code for airplanes or medical devices, failure is quite literally fatal. Or maybe you’re writing software that trades billions of dollars of financial instruments. Failure is bad there, but maybe not as bad as in the previous group. However, for the majority of us, the answer is not that dramatic.

I’ve noticed that there’s been a push-back on some commonly cited best practices for programming. If you’ve read programming advice of a certain era, the Code Complete, Clean Code, Design Patterns one, you’ve probably heard that you should split up your functions into small chunks, no more than 10 lines. Or that you should write code that only has one return. Or that you should use a Factory pattern to create a Strategy that uses a Visitor.

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.