Its because of very high domain knowledge that's all. Its very foolish for a new guy in a team to do this without consulting those who have the high domain knowledge and yes confidence is also important. But when you are working on something for a very long time, you automatically gain this confidence provided that your product owners trust you.
It isn't Rust: I do this just as effectively in untyped Javascript. It's mostly confidence in your ability to put things back together (comfort with a debugger, comfort throwing together the rough outline of something new). These skills constitute the craft of coding, something most employers aren't even looking for because they lack faith that there could be that much more value to claim by having better code
I do think that Rust (or static types in general) plays into it. Because if you look at a piece of Rust code, you can see what it does. There are rarely any hidden side-effects that aren't observable from the code. (Modulo custom `Drop` implementations, which I'm not a fan of.)
That being said (and as I wrote) I'm not sure it's only Rust. The mindset, like you wrote, can be transferred to different languages.
The types in Rust don't document entirely what the code is doing. There are still invariants not captured by the code. You wouldn't delete code you don't understand *at all*.
That's why there is not such a large difference between shredding JavaScript and Rust. JavaScript can be perfectly readable. You can know a JavaScript codebase well enough to understand what deleting something means.
Even in languages with stronger type systems than Rust, you'd be able to shred. Unless of course everything is interdependent (on definitions, not declarations) like it can be in Coq.
This is a lot less frightening if you have e2e or system tests in place that do not need any modifications even if you destroy and rebuild half of your system
As somebody who wants to become a better software engineer , this sort of programming feels a bit erratic perhaps I am not familiar with how scoped rebuilding really works. In my limited experience, code for a system is divided into "core" and plugins/modules/subsystems, the implication being that core is stable enough that the other stuff around it can be changed without any fear of the system breaking down. Does that fact that zed is still making a mark as a product lend some additional value to being able to change it so quickly ?
Possibly? Like I wrote above, I don't have a clear answer. I do think that it's about the scope of a shred. It's not that someone tears apart half of the system that's responsible for making HTTP calls to our backend. But they might rewrite the 4 functions that handle authentication from scratch. Or someone might rewrite how we find the current word under cursor in the current buffer. These things are clearly scoped/factored and the input/outputs are clear.
Jonathan Blow calls this Sledgehammer programming.
He talks about this here: https://youtu.be/ubWB_ResHwM?si=9e9ZJP_uaZOoTghM
Thank you so much for sharing! This is 100% it.
Funny that he used the same word — sledgehammer.
Its because of very high domain knowledge that's all. Its very foolish for a new guy in a team to do this without consulting those who have the high domain knowledge and yes confidence is also important. But when you are working on something for a very long time, you automatically gain this confidence provided that your product owners trust you.
It isn't Rust: I do this just as effectively in untyped Javascript. It's mostly confidence in your ability to put things back together (comfort with a debugger, comfort throwing together the rough outline of something new). These skills constitute the craft of coding, something most employers aren't even looking for because they lack faith that there could be that much more value to claim by having better code
I do think that Rust (or static types in general) plays into it. Because if you look at a piece of Rust code, you can see what it does. There are rarely any hidden side-effects that aren't observable from the code. (Modulo custom `Drop` implementations, which I'm not a fan of.)
That being said (and as I wrote) I'm not sure it's only Rust. The mindset, like you wrote, can be transferred to different languages.
The types in Rust don't document entirely what the code is doing. There are still invariants not captured by the code. You wouldn't delete code you don't understand *at all*.
That's why there is not such a large difference between shredding JavaScript and Rust. JavaScript can be perfectly readable. You can know a JavaScript codebase well enough to understand what deleting something means.
Even in languages with stronger type systems than Rust, you'd be able to shred. Unless of course everything is interdependent (on definitions, not declarations) like it can be in Coq.
This is a lot less frightening if you have e2e or system tests in place that do not need any modifications even if you destroy and rebuild half of your system
Funnily enough, we don't have an e2e or integration test suite.
As somebody who wants to become a better software engineer , this sort of programming feels a bit erratic perhaps I am not familiar with how scoped rebuilding really works. In my limited experience, code for a system is divided into "core" and plugins/modules/subsystems, the implication being that core is stable enough that the other stuff around it can be changed without any fear of the system breaking down. Does that fact that zed is still making a mark as a product lend some additional value to being able to change it so quickly ?
Possibly? Like I wrote above, I don't have a clear answer. I do think that it's about the scope of a shred. It's not that someone tears apart half of the system that's responsible for making HTTP calls to our backend. But they might rewrite the 4 functions that handle authentication from scratch. Or someone might rewrite how we find the current word under cursor in the current buffer. These things are clearly scoped/factored and the input/outputs are clear.