- The impassable bottleneck will be in the database
- Don't make any decision that you can delay. Very often you will see the initial requirements have changed, or not relevant any more.
- Listen to your team colleges, replay to them what they just said, even if you don't agree make them sure you have listened and understood what their proposition is. If you don't agree say something like "I maybe wrong but I am going to go this other way". Most of the discussions will end, no with an agreement but when the other person feels that they have been listened.
- Use "boring" technology when your objective is to build solid things.
I recently rediscovered Tom DeMarco's article "Software Engineering: An Idea Whose Time Has Come and Gone?" where he makes an interesting argument that tight control is much more important for a $1M project that yields $1.1M in value vs. a $1M project that yields $50M in value:
"...the more you focus on control, the more likely you're working on a project that's striving to deliver something of relatively minor value."
It is safe to keep using a malloc'd memory region after you've freed it, as long as you haven't done any more malloc calls after the free. (I think this stopped being true a lot longer than 20 years ago, but it was true in old UNIXes and documented in the manuals, so some code legitimately relied on it.)
Judicious use of register declarations can make your C code run a lot faster (true back in the day; most compilers ignore those declarations now).
Fermat's last theorem is an unsolved math problem. Reference: Knuth TAOCP presented it as an "M50" rated exercise, designating a research problem. (FLT was solved in 1995, after which I think Knuth lowered that exercise's rating to M49).
