
Ask HN: Please take part in experiment on HN's collective expertise. - iuguy
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.
======
iuguy
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.

~~~
madhouse
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.

------
RiderOfGiraffes
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.

------
imcqueen
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.

------
Jacquass12321
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.

------
marklabedz
When presenting: Never, ever read from a slide. Always speak more words than
you type. If possible, get rid of slides completely.

------
proexploit
The motivated and hard-working will succeed.

------
stakent
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.

------
meaydinli
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.

------
hfinney
The conventional wisdom is usually right. That's how it got to be the
conventional wisdom.

------
aiurtourist
When writing code, think of the people who will inherit it from you.

