Things that only someone who has been programming 20 years would know | Hacker News Reader

Things that only someone who has been programming 20 years would know

quora.com

23 pointscroqaz7 comments

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

Original discussion from 2018, for those who are interested: https://news.ycombinator.com/item?id=18046722

You can't estimate software. (I've been writing software for 50 years).

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

Agree with everything but with the automation: https://xkcd.com/1319/

I have seen so many times a repetitive tasks becomes not that repetitive. And maintaining the automating tool mattress difficult to adapt to changes.

I think it's better to remain flexible than optimized. Until the pattern has demonstrated to be solid.

can't figure it out? do something else for a while.

Reply on news.ycombinator.com