3 ms·

So what's an effective way to learn to develop well engineered code? I'm at the point currently where I would not be able to predict how well a program will do

by chris11 11y ago

So what's an effective way to learn to develop well engineered code? I'm at the point currently where I would not be able to predict how well a program will do running continuously.

ksk 11y ago
It might seem weak to not have a good alternate solution when criticizing someones attempt at one, but I don't have a ready answer. Well, okay so I'll try and give you advice anyway :P What kind of program is it? Is it a library, console/gui app? Does it have a variable workload? What are the ways in which people interact with the code? Is it primarily a desktop or server side application? What kind of test framework do you have in place? Do you have any instrumentation that would allow you to generate code coverage numbers? Can you run fault injection/fuzzing/etc type testing on it? Is the program resource limited? If so, do you have a CPU/Mem budget that you regularly check against? How many libraries does your program interact with? Do you keep track and test those libraries for failures? Do you try to freeze third party library/SDKs to minimize external bugs harming your own software's reliability? Do you always hard-crash at every bug or do you need to keep the software limping along till shit really hits the fan? Do you regularly (when there is no bug to track) run your software under a debugger to get a good feel for what the call stack, arguments, etc look like in a practical scenario (so that you can train yourself to catch it when things seem out of place). Its a lot about asking yourself what your blind spots are. Sometimes you have to think super-practically and just "look at the bits" and sometimes you have to try to see the forest. It all depends on what you're doing. And sure experience is a mean teacher. Nothing like getting a call at midnight and someone asking you why your embedded code running on-site in another state isn't working right after 5 months of no issues :P
sitkack 11y ago
Typing on tablet, apologies for terseness. * simple machines * highly regular, not littered with corner cases * state isolation, fast and easy to restart * linguistically and semantically simple The affordances of Erlang are a good starting point, as they encourage simple machines with isolated state while the language lacks the ability paint oneself into a corner semantically.

by chris11 11y ago

So what's an effective way to learn to develop well engineered code? I'm at the point currently where I would not be able to predict how well a program will do running continuously.

ksk 11y ago

It might seem weak to not have a good alternate solution when criticizing someones attempt at one, but I don't have a ready answer. Well, okay so I'll try and give you advice anyway :P What kind of program is it? Is it a library, console/gui app? Does it have a variable workload? What are the ways in which people interact with the code? Is it primarily a desktop or server side application? What kind of test framework do you have in place? Do you have any instrumentation that would allow you to generate code coverage numbers? Can you run fault injection/fuzzing/etc type testing on it? Is the program resource limited? If so, do you have a CPU/Mem budget that you regularly check against? How many libraries does your program interact with? Do you keep track and test those libraries for failures? Do you try to freeze third party library/SDKs to minimize external bugs harming your own software's reliability? Do you always hard-crash at every bug or do you need to keep the software limping along till shit really hits the fan? Do you regularly (when there is no bug to track) run your software under a debugger to get a good feel for what the call stack, arguments, etc look like in a practical scenario (so that you can train yourself to catch it when things seem out of place). Its a lot about asking yourself what your blind spots are. Sometimes you have to think super-practically and just "look at the bits" and sometimes you have to try to see the forest. It all depends on what you're doing. And sure experience is a mean teacher. Nothing like getting a call at midnight and someone asking you why your embedded code running on-site in another state isn't working right after 5 months of no issues :P

sitkack 11y ago

Typing on tablet, apologies for terseness. * simple machines * highly regular, not littered with corner cases * state isolation, fast and easy to restart * linguistically and semantically simple The affordances of Erlang are a good starting point, as they encourage simple machines with isolated state while the language lacks the ability paint oneself into a corner semantically.