Ask HN: Please take part in experiment on HN's collective expertise.
There's a lot of really smart people from different backgrounds on HN. I thought I'd ask the HN community to post the one piece of advice that you could give a fellow HN'er from your own domain of expertise. Please upvote the ones you like the most, but only post one piece of advice.
11 comments
Having done information security for way too long, the one piece of advice I could give is:
Never trust input. Unless you can control access to the source and destination and secure the confidentiality and integrity of the transport, assume that any information is tainted by default. It doesn't have to be user-generated (that cookie in that request, don't assume it's not been tampered with) input, just input in general. However your app interacts with data, sanitise it by default and assume that the content may be malicious and you'll solve a fair chunk of your potential information security problems.
Never trust input. Unless you can control access to the source and destination and secure the confidentiality and integrity of the transport, assume that any information is tainted by default. It doesn't have to be user-generated (that cookie in that request, don't assume it's not been tampered with) input, just input in general. However your app interacts with data, sanitise it by default and assume that the content may be malicious and you'll solve a fair chunk of your potential information security problems.
Expanding on this advice: never assume that the libraries or programs you use are bug-free.
Before digging deep into your own code, make sure the bug actually is in it, and not somewhere else.
I have seen problems where a particular program didn't work, due to the other side - which I had nearly no information about - had a bad optimisation, which made it crash. Or another, recent case, where a particular third party library was abusing a cache, and stored freed objects in it, which resulted in interesting crashes all over the place.
Before digging deep into your own code, make sure the bug actually is in it, and not somewhere else.
I have seen problems where a particular program didn't work, due to the other side - which I had nearly no information about - had a bad optimisation, which made it crash. Or another, recent case, where a particular third party library was abusing a cache, and stored freed objects in it, which resulted in interesting crashes all over the place.
Randomness clumps, and randomness solves many, many problems. Be sure you understand first both your problems and the randomness you intend to introduce, otherwise many, many things will break in bizarre ways.
Single example: ballistic shotgun stochastic hill-(climbing|descending) will often get you a good enough solution far faster than most techniques that are more complex and more impenetrable.
Single example: ballistic shotgun stochastic hill-(climbing|descending) will often get you a good enough solution far faster than most techniques that are more complex and more impenetrable.
Test everything about your design. Your customers will tell you what works and what doesn't. Remember that copy is part of the design too, headline tests are boring but they can make a huge difference.
When you're debugging and you make that assumption that the error certainly isn't in one section of code so you should look elsewhere, check that one section of code first.
[deleted]
When presenting: Never, ever read from a slide. Always speak more words than you type. If possible, get rid of slides completely.
The motivated and hard-working will succeed.
Periodically test the infrastructure backing up your primary production assets. Make tests so close to reality as possible. Use tests results to learn and improve your processes.
K.I.S.S rule
"keep it simple s...."
it is usually better to subtract code to fix bugs (and to optimize) then to add code.
it is usually better to subtract code to fix bugs (and to optimize) then to add code.
The conventional wisdom is usually right. That's how it got to be the conventional wisdom.
When writing code, think of the people who will inherit it from you.