> Never argue on the internet. No one will remember whether you won or lost the argument; they'll just remember that you are the sort of person who argues on the internet.<p>This is burned in my mind and doesn't anchor enough of my judgement of what to engage with on the internet yet, but I've never yet been steered wrong by it.<p>EDIT - This is equally applicable to realms outside of the internet. You have to be <i>really</i> right to be remembered as the person who was right about something in your friend group or coworkers. Like, you have to prevent someone from dying levels of correct. Otherwise you're just the person who kept talking about something until everyone gave in. And either way, they'll still remember you as that person who argues about things.
> Learn about Chesterton's Fence. Then, actively resist altering a given situation before you understand the reasons why it's remained unchanged for so long.<p>This is probably the most important advice for developers who start a new job, or have to work with existing code. Trying to refactor code or replacing it with a new micro service requires that you understand the old code. If you are not willing or able to take the time to understand it, you do not know enough to replace it.<p>I have made this mistake several times in the past, but it has taken time for me to learn this lesson. I have complex data flows and error handling and thought I could simplify it or rewrite it as a new service. I would later find out that the old code handled scalability, edge cases or unknown external dependencies that my new code did not. These issues appeared in small "drips" over time, so it was easy to focus on the individual bugs instead of noticing the larger pattern. This led me to believe that the next rewrite would turn out better. The real lesson is that I did not know enough about the existing code and made assumptions that turned out to be incorrect.<p>Sometimes you need to make changes because the old system has started to "rot", which makes it hard to add new features. Just make sure that it is accidental complexity and not necessary complexity.
In the past I've lambasted some of these collections of wisdom. There is a certain point in a man's life where he feels he wants to write down a collection of hard-learned thoughts and experiences. These often appear on HN. Most often they are pretentious.<p>For whatever reason, I liked this one. I can't say it is a better collection than others that I have pretty harshly criticized. I can't say it is better written. I can't say I agree with more or less in this list. I just liked this one.
Im not particularly fond of these types of lists, but given the author and the material posted, this is definitely an exception.<p>One thing I didnt quite get:<p>> Every project is a triangle made of time, money, and quality; shortening the length of one side necessarily lengthens one or—more often—both of the other sides.<p>If I'm assuming the longer a side is, the "more" of it that is required, then the way I understand it is that the "quality" side might need to rather be "inverse quality", such that shortening the quality side length increases quality. As per the original statement, a reduction in quality (shortening the quality length) increases time and/or money, whereas IME when building something out, quality results come at a (time/money) cost.
I guess it half makes sense if the perspective is that defering on quality (shortening the line) costs more in the long run (increasing length of the other 2 lines). But then taken from the perspective of the other 2 sides of the triangle: reducing money or time doesnt result in an increase (longer side) of quality... typically the opposite.<p>So genuine question: did I misunderstand the point?
> Frequently ask yourself: do I want to be right, or do I want to be happy?<p>I always felt that people giving this advice assume the latter is preferable. Is there something defective about me if I prefer the former?
Merlin's podcasts, particularly Roderick on the Line and the amazing Reconcilable Differences with John Siracusa, are amongst my favourite things to listen to.
Browsing this via the commit history helps break it down into smaller chunks: <a href="https://github.com/merlinmann/wisdom/commits/master">https://github.com/merlinmann/wisdom/commits/master</a>
Could someone please explain this one to me?<p>> If you really want a glass of water at a restaurant, always order that first. As you do this, look the server in the eyes and nod.<p>I don't understand it at all. Is is to make sure you get the water first, and not with the other dishes? Is it to test how the waiter would react, and whether you want to order other things?<p>Why that weird ritual with the eyes, what is it supposed to mean?
I'm very surprised that this list doesn't include Mann's Assumption: <a href="https://www.kungfugrippe.com/post/29776928258/manns-assumption" rel="nofollow noreferrer">https://www.kungfugrippe.com/post/29776928258/manns-assumpti...</a>
> Be sparing in how often you tell someone their negative feelings are wrong; it rarely helps a sad person to be told that they are also a liar.<p>Their <i>feelings</i> are a liar (or at least can be). That's an important difference.
Wait, what Flintstones am I supposed to have watched? The Hana-Barbera cartoon was so good that it deserves to be the go-to example for things that young people "somehow haven't heard of"?
> Buy slightly larger shoes.<p>Slightly larger than what? From my experience of wearing larger shoes because they initially seemed more comfortable in the shoe store, that seems like bad advice.