3 ms·

Nevertheless, the more complete and accurate your picture of what you are attempting to achieve, and where you are, is (at every level of abstraction), the fewe

Nevertheless, the more complete and accurate your picture of what you are attempting to achieve, and where you are, is (at every level of abstraction), the fewer iterations it will take to get done - or the fewer bugs remaining after a given elapsed time. It's like situational awareness: https://en.wikipedia.org/wiki/Situation_awareness https://en.wikipedia.org/wiki/Situation_awareness

taeric 8y ago
The number one thing I try and build up for my teams is a mental picture of the entire system. It is amazing, to me, how much resistance I get to the idea.
seanmcdirmid 8y ago
If we want to go there, modern tooling allows you to forget some of the details you used to care about and focus more on other things, the tooling is rarely comprehensive and there will always be more to consider until the entire programming process is automated.
- mannykannot 8y ago
  As modern tooling chips away at the accidental difficulties of software development, systems-level situational awareness becomes relatively more central to the process.
lostcolony 8y ago
The difference is other people. Yes, if you're writing your -own- code, learning to envision what the system must do in your head first is very, very valuable. When you're on a team, however, you -have- to compartmentalize. You have to create abstractions, black boxes, functionalities that you -could- dive into, but which you will accept only understanding at a contract (interface) level. The skill of envisioning the system is still useful, of course, but there will be black boxes. The problem that causes, of course, is that every abstraction is leaky. You didn't know that calling this method also fired off this event, and so you -also- triggered that event. Or whatever. Hence, bugs and iteration. You also have to deal with -bad- interfaces, a bajillion parameters, or a parameter object that isn't intuitively obvious how to initialize, and you start having to iterate.
- mannykannot 8y ago
  The problem is not just, or mainly, leaky abstractions - you can't make a system out of a collection of opaque abstractions. An important part of Knuth's genius is seeing deeply and clearly how they have to interact. Leaky abstractions are just one sort of problem that arises when this doesn't happen.

taeric 8y ago

The number one thing I try and build up for my teams is a mental picture of the entire system. It is amazing, to me, how much resistance I get to the idea.

seanmcdirmid 8y ago

If we want to go there, modern tooling allows you to forget some of the details you used to care about and focus more on other things, the tooling is rarely comprehensive and there will always be more to consider until the entire programming process is automated.

mannykannot 8y ago
As modern tooling chips away at the accidental difficulties of software development, systems-level situational awareness becomes relatively more central to the process.

lostcolony 8y ago

The difference is other people. Yes, if you're writing your -own- code, learning to envision what the system must do in your head first is very, very valuable. When you're on a team, however, you -have- to compartmentalize. You have to create abstractions, black boxes, functionalities that you -could- dive into, but which you will accept only understanding at a contract (interface) level. The skill of envisioning the system is still useful, of course, but there will be black boxes. The problem that causes, of course, is that every abstraction is leaky. You didn't know that calling this method also fired off this event, and so you -also- triggered that event. Or whatever. Hence, bugs and iteration. You also have to deal with -bad- interfaces, a bajillion parameters, or a parameter object that isn't intuitively obvious how to initialize, and you start having to iterate.

mannykannot 8y ago
The problem is not just, or mainly, leaky abstractions - you can't make a system out of a collection of opaque abstractions. An important part of Knuth's genius is seeing deeply and clearly how they have to interact. Leaky abstractions are just one sort of problem that arises when this doesn't happen.