There is a gigantic pool of talented engineers that nobody has figured how to tap into. They’re the people who don’t apply to jobs. If you can find these people, you can build an incredible team. It’s a pretty obvious statement to say that you only get candidates who apply, but that belies a major truth: A lot of people really really really hate applications. They will do anything to avoid filling a form.

Do you ever look back and marvel at how much fashion has changed? In 2016 all the cool kids were wearing selvedge jeans, Clarks desert boots or maybe Stan Smith sneakers. Oh and they were writing ES6 with React classes, CSS in JS and Redux. Y’know, the cool front-end dev kids. Now it’s all kids wearing light-washed high-waisted bell-bottom (!) jeans with some chunky sneakers, writing Solid with Tailwind and TypeScript.

After reading a post by Graphite and some recent Hacker News discussion, I decided to jot down some notes on version control, specifically git. Saves vs Commits Commits are subtly tricky in that they are really two different concepts in one. In some cases, they function as a mechanism to save your code. It’s 5pm and you want to go home, so you commit your code. Or as the meme goes, in case of fire, git commit, git push, leave building.

I’m not claiming all of these will work, but they’re worth a shot: Gap Year Internship There’s plenty of really bright high school students who you could hire pretty easily. They’d be really cheap to hire, scrappy, and if they’re looking for internships as a high schooler, they’re probably going to be better than a lot of college students. In fact, if you can keep them coming back every summer during college, by the time they graduate, they’ll be pretty damn impressive.

If you haven’t already, check out part 1. These are more musings that I’ve written over time, so there’s some additions that contradict previous stuff as I’ve done more experiments over time. Resources Here’s a list of resources for chili oil. As a whole, it’s pretty remarkable how much more sophisticated the Chinese videos are for chili oil. They tend to have a lot more thought around infusion and chili processing.

If you’re gonna join an early stage1 startup, there are a few questions that I think you should ask the founders. This is by no means a comprehensive list. In fact most of these questions are obvious, but sometimes the obvious ones are the important ones. Also, I’m not exactly an expert on startups, these are just based off of my limited experience. What does the company do? This is a really obvious question and yet it will reveal a lot.

I’ve written about what I call Tooling for Tooling, basically meta-tools that help people build better developer tools faster and easier. Arguably the most famous and ubiquitous meta-tool is not actually a tool—it’s the Language Server Protocol (LSP). By defining a protocol for language implementations to communicate with editors, the LSP lets language authors write a single LSP server and let their users bring any editor that implements an LSP client.

Rust is in an interesting stage as a programming language. It’s gotten a lot of mindshare, and a decent amount of adoption. It’s not at the point where people are learning Rust by the droves, but there are a respectable amount of people who write Rust. As for jobs, Rust positions are not ubiquitous, though they are increasing in number. Basically, Rust is past the threshold of only being used by programming language nerds, and onto the stage of being a language that real companies depend on, i.

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.