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.

I was reading HN like a dutiful tech employee, when I stumbled upon a classic HN scene: a laudatory Rust post followed by a whole host of reactionary anti-Rust comments. In these comments was an inadvertently good question: Why is “(re)written in Rust” a good selling point? My first instinct was to respond with the typical arguments: Rust is safer; Rust has a nicer build system; Rust is faster. But after some thought, I actually wanted to respond with the answer that most people hold in contempt: Rust is fun!

I have a problem with the phrase “self taught developer”. It’s not that I take issue with autodidacts. Far from it; I find the phrase redundant. Every developer is a self taught developer. Some of us may take courses in school and may learn to write code under the tutelage of a brilliant, perhaps eccentric professor. Others might learn via after school programs or online courses. But the nice guided path of professors and courses never lasts.

What separates the super successful, 10k GitHub stars, front-page of Hacker News side project from the abandoned project that languishes on your GitHub, a starter template with a couple commits from June of 2021? I’d say it’s whether or not you revisit the project. In a perfect world we’d all start projects that we work on every day, make fantastic progress, and ship within a couple weeks to thousands of users and adoring comments on Hacker News and Reddit.

I’ve been playing around with a new language called Vicuna. It’s very much in the early stages, just a simple parser that compiles to JS. One thing I like to do when I write a compiler is to build a playground so that I can inspect the various compiler stages and test everything in an interactive fashion. To build this playground, I decided to compile my compiler to WebAssembly. That way everything could run in browser in a tight loop.