Nah, if you have some complex logic you are not sure about then you need to see it run to be able to see how it reacts to changes. You cannot run pseudocode so it is far harder to validate it will do what you want it to do.
I guess maybe its my sysadnin coding /DevOps domain that makes a couple of people spit balling on a white board faster to get started then rack and stacking, powercycling, or provisioning new instances.
There is a big difference in planning server layouts and similar tasks and writing pseudocode. In comparason the planning is much cheaper and the cost of getting things wrong can be quite high. But with pseudocode, it is not that much cheaper to write than real code is, it gives you a lot less useful information and the cost of a mistake is quite cheap in code (that is while you are still developing things and for the types of problems pseudocode might even be able to catch).
Agreed it seems like the largest factor is what is cost (both time, effort, and capital) is to run with real data vs tabletopping it. Mapping out unknowns might help if the costs of not catching unknowns is too high.
Makes sense when try to work through a complex logic flow that you just aren’t sure about.
Nah, if you have some complex logic you are not sure about then you need to see it run to be able to see how it reacts to changes. You cannot run pseudocode so it is far harder to validate it will do what you want it to do.
I guess maybe its my sysadnin coding /DevOps domain that makes a couple of people spit balling on a white board faster to get started then rack and stacking, powercycling, or provisioning new instances.
There is a big difference in planning server layouts and similar tasks and writing pseudocode. In comparason the planning is much cheaper and the cost of getting things wrong can be quite high. But with pseudocode, it is not that much cheaper to write than real code is, it gives you a lot less useful information and the cost of a mistake is quite cheap in code (that is while you are still developing things and for the types of problems pseudocode might even be able to catch).
Agreed it seems like the largest factor is what is cost (both time, effort, and capital) is to run with real data vs tabletopping it. Mapping out unknowns might help if the costs of not catching unknowns is too high.