3 ms·

I'd even go so far as to say: If you're not spending at least half your time on so-called 'error handling', you're probably doing something wrong, like using a

I'd even go so far as to say: If you're not spending at least half your time on so-called 'error handling', you're probably doing something wrong, like using a language feature (like exceptions) to defer that technical debt to later -- and you'll regret it, if your project matures, I assure you. If you spend more than half your time in error handling, you have an architectural design issue with your code. If you need to be that vigilant then it's too easy for a junior hire to make a mistake that makes your code unreliable. Design out pitfalls. Reduce the amount of code in your system where you need that level of vigilance, and you'll no longer need to spend 50+% of your time on error handling.

electrograv 8y ago
Designing out pitfalls is precisely what I’m talking about and arguing for — and that takes time (in an application of any sophistication), either because you’re using a language (like Rust) whose compiler nitpicks your code in ways that 99% other languages would just accept without complaint, or because you’re being equivalently paranoid in your design of every single core data type, interface, platform service, etc. There may also be some disconnect here in the type of code we’re talking about. I’m talking about work on code that millions of people are relying on to be 100% rock solid. I don’t care if you’re junior or senior: when writing code at this standard of quality, caution and rigor are always part of the process (both by the author, and the review and testing process). If you can write absolutely rock solid, 99.9999% bug-free code that handles every possible error case gracefully, while spending more than 50% of your total coding time spent typing new code (which apparently has no error handling) literally as fast as you can type, well... WOW!! Consider me impressed; It seems we all have a lot to learn from you. If so, I genuinely would love to learn more of this seemingly-magical process where you can write perfect code at maximum speed, while also not having to think about edge cases or other errors. Anyways, back to reality: The fact that so much of this caution associated with writing bug-free code is loaded onto human judgement right now is exactly why I’m such a strong advocate for languages like Rust and Zig that aim to move much of this cognitive burden into the compiler. For example, let’s talk about designing out pitfalls: say I create an immutable data structure in C++ with a really efficient implementation (zero-cost copies, automatic memory sharing) that is virtually foolproof when accessed from multiple threads, used in computations, etc. No matter how foolproof I make this C++ class, I still can’t stop your “junior dev” from stomping over the end of another array into my class data, or using dangling pointers, etc. etc. etc. We can enforce “safe” classes wherever possible, but that also runs up against the wall of reality when interoperating with other C++ code that has a different idea of what constitutes that “ideal C++ subset”.
- mdpopescu 8y ago
  _I don’t care if you’re junior or senior: when writing code at this standard of quality, caution and rigor are always part of the process_ There are (at least) three stages for a program: make it work, make it good, make it fast. Most programmers I know (aka juniors) are happy to get the first stage done, for a value of done (it worked on my machine, when I tested it with this particular sequence). After many, many years of programming (aka senior), I'm proud to say that I usually take care of the second stage, and sometimes even the third. The whole point of the junior / senior distinction is that seniors have been burned more times by some things so they insist on processes like always having source control, at least trying to have automated tests and so on - processes that a lot of juniors find irrelevant to getting things to work in the first place.
  - jcelerier 8y ago
    What kind of "junior" are we talking about here ?? The average comp. sci student will insist on source control. Are you hiring high schoolers or what ?
speedplane 8y ago
> If you spend more than half your time in error handling, you have an architectural design issue with your code. Ha, I once wrote a lock_file(...) function in 30 minutes. Then spent the next two years getting it to work on various platforms, on network drives, dealing with re-entrance, and so many other corner-cases you couldn't believe. The initial 10 line function turned into a whole module. I'm not sure that counts as error handling as much as handling things you don't expect.

electrograv 8y ago

Designing out pitfalls is precisely what I’m talking about and arguing for — and that takes time (in an application of any sophistication), either because you’re using a language (like Rust) whose compiler nitpicks your code in ways that 99% other languages would just accept without complaint, or because you’re being equivalently paranoid in your design of every single core data type, interface, platform service, etc. There may also be some disconnect here in the type of code we’re talking about. I’m talking about work on code that millions of people are relying on to be 100% rock solid. I don’t care if you’re junior or senior: when writing code at this standard of quality, caution and rigor are always part of the process (both by the author, and the review and testing process). If you can write absolutely rock solid, 99.9999% bug-free code that handles every possible error case gracefully, while spending more than 50% of your total coding time spent typing new code (which apparently has no error handling) literally as fast as you can type, well... WOW!! Consider me impressed; It seems we all have a lot to learn from you. If so, I genuinely would love to learn more of this seemingly-magical process where you can write perfect code at maximum speed, while also not having to think about edge cases or other errors. Anyways, back to reality: The fact that so much of this caution associated with writing bug-free code is loaded onto human judgement right now is exactly why I’m such a strong advocate for languages like Rust and Zig that aim to move much of this cognitive burden into the compiler. For example, let’s talk about designing out pitfalls: say I create an immutable data structure in C++ with a really efficient implementation (zero-cost copies, automatic memory sharing) that is virtually foolproof when accessed from multiple threads, used in computations, etc. No matter how foolproof I make this C++ class, I still can’t stop your “junior dev” from stomping over the end of another array into my class data, or using dangling pointers, etc. etc. etc. We can enforce “safe” classes wherever possible, but that also runs up against the wall of reality when interoperating with other C++ code that has a different idea of what constitutes that “ideal C++ subset”.

mdpopescu 8y ago
_I don’t care if you’re junior or senior: when writing code at this standard of quality, caution and rigor are always part of the process_ There are (at least) three stages for a program: make it work, make it good, make it fast. Most programmers I know (aka juniors) are happy to get the first stage done, for a value of done (it worked on my machine, when I tested it with this particular sequence). After many, many years of programming (aka senior), I'm proud to say that I usually take care of the second stage, and sometimes even the third. The whole point of the junior / senior distinction is that seniors have been burned more times by some things so they insist on processes like always having source control, at least trying to have automated tests and so on - processes that a lot of juniors find irrelevant to getting things to work in the first place.
- jcelerier 8y ago
  What kind of "junior" are we talking about here ?? The average comp. sci student will insist on source control. Are you hiring high schoolers or what ?

speedplane 8y ago

> If you spend more than half your time in error handling, you have an architectural design issue with your code. Ha, I once wrote a lock_file(...) function in 30 minutes. Then spent the next two years getting it to work on various platforms, on network drives, dealing with re-entrance, and so many other corner-cases you couldn't believe. The initial 10 line function turned into a whole module. I'm not sure that counts as error handling as much as handling things you don't expect.