Layers of Abstraction and Product Engineering
This is an incomplete thought.
A fundamental problem with browsing code and doing software product engineering is that there is an insufficient method for handling the simultaneous layers of abstraction that occur.
Consider a workflow, of any kind. As product people, we speak of “the workflow”, generally referring to the highest level of abstraction of that workflow; the “happy path”. There is of course a second, more complex, more complete, “full workflow”, that includes all of those little nitty rules about handling this case or that case. These are the “edge cases”.
But our code - generally - doesn’t distinguish between the “happy path” and the “edge cases”, not when we browse. When we edit a file, we’re editing all of those rules at once. We can’t hide the edges, and manipulate just the big concepts, then fill the edges back in.
This is, of course, what Object Oriented Programming, and every programming discipline, is designed to do in theory. Type systems, automatic compile time checking, all of it, is designed to help us in one way or another manage that complexity.
Code generation tools and scaffolding helps us do this in some way - in that it allows us to generate a lot of code for the “happy path”. But once it is generated, then we’re stuck operating at that lower level of abstraction again.
Why can’t we go back up a level of abstraction and push the shapes around once we’ve filled them in? Why are we stuck shoveling edges around one by one?