tl;dr:“An article about a couple of relatively recent additions to my workflow which I wish I knew about years ago: Split And Go To Definition. Go to definition is super useful. But often, when I use “goto def” I don’t actually mean to permanently go there. Rather, I want to stay where I am, but I need a bit more context about a particular thing at point. What I’ve found works really great in this context is to split the screen in two, and issue “go to def” in the split.” Alex shares an example.
tl;dr:“This post describes my current approach to testing. When I started programming professionally, I knew how to write good code, but good tests remained a mystery for a long time. This is not due to the lack of advice — on the contrary, there’s abundance of information & terminology about testing.”
tl;dr:“After working on the initial stages of several largish projects, I accumulated a list of things that share the following three properties: (1) They are irrelevant while the project is small. (2) They are a productivity multiplier when the project is large. (3) They are much harder to introduce down the line.”
tl;dr:“After working on the initial stages of several largish projects, I accumulated a list of things that share the following three properties: (1) They are irrelevant while the project is small. (2) They are a productivity multiplier when the project is large. (3) They are much harder to introduce down the line.”
tl;dr:“There are a bunch of posts on the internet about using git worktree command. As far as I can tell, most of them are primarily about using worktrees as a replacement of, or a supplement to git branches. Instead of switching branches, you just change directories. This is also how I originally had used worktrees, but that didn’t stick, and I abandoned them. But recently worktrees grew on me, though my new use-case is unlike branching.”
tl;dr:“This post describes my current approach to testing. When I started programming professionally, I knew how to write good code, but good tests remained a mystery for a long time. This is not due to the lack of advice — on the contrary, there’s abundance of information & terminology about testing.”
tl;dr:“After working on the initial stages of several largish projects, I accumulated a list of things that share the following three properties: (1) They are irrelevant while the project is small. (2) They are a productivity multiplier when the project is large. (3) They are much harder to introduce down the line.”
tl;dr:“After working on the initial stages of several largish projects, I accumulated a list of things that share the following three properties: (1) They are irrelevant while the project is small. (2) They are a productivity multiplier when the project is large. (3) They are much harder to introduce down the line.”
tl;dr:The article presents two interdependent coding principles: (1) "Push Ifs Up" - move if conditions to the caller to simplify functions and enhance readability by centralizing control flow. This approach reduces bugs and makes code maintenance easier. (2) "Push Fors Down" - handle operations on batches of objects, not individually, for better performance and flexibility. This method is efficient, especially when combined with the first rule, as it streamlines processing and can enable advanced techniques like vectorization.
tl;dr:Rust is vertically scalable as you “can write all kinds of software in it,” as well as horizontally scalable - you “can easily parallelize development of large software artifacts across many people and teams.” Alex elaborates on both.