If you know a lot about one single language, it may make it easier to get a job, but in the long run, language usage dies or loses its charms and you'll need to find something else. Knowing a bit about a lot of other languages helps in the long run, not to mention that may help you think of better solutions.

If it took you more than one hour for you to figure out what went wrong, it is a good idea to put it on list, 'cause these things have the tendency to appear again.

You know what's one of the worst function names ever? sleep().

Sleep for how long? It is seconds or milliseconds?

Think how the data you're collecting from your users will be used -- this is more prevalent on these days, where "privacy" is a premium.

One thing a team may decide to fix the continuous flux of code style comments in a code review is to use a code formatting tool to auto-format the code. That's ok, but they should never rely on it.

When doing code reviews, do not focus on style; focus on design things that look a bit weird.

If your project have a defined code style, you must follow it. Sometimes it may not be clear ("this struct/class should be singular or plural"?), but do your best to follow it.

Every freaking time Google comes with their own coding style, it's a garbage fire. The community came with a better style way before and Google seem to come with a style with high contrasting parts just to call it theirs.

Goodreads summary: Richard Dawkins's essays are an enthusiastic testament to the power of rigorous, scientific examination, and they span many different corners of his personal and professional life. He revisits the meme, the unit of cultural information that he named and wrote about in his groundbreaking work The Selfish Gene. He makes moving tributes to friends and colleagues, including a eulogy for novelist Douglas Adams; he shares correspondence with the evolutionary biologist Stephen Jay Gould; and he visits with the famed paleoanthropologists Richard and Maeve Leakey at their African wildlife preserve. He concludes the essays with a vivid note to his ten-year-old daughter, reminding her to remain curious, to ask questions, and to live the examined life.

GoodReads summary: You should learn a programming language every year, as recommended by The Pragmatic Programmer. But if one per year is good, how about Seven Languages in Seven Weeks? In this book you'll get a hands-on tour of Clojure, Haskell, Io, Prolog, Scala, Erlang, and Ruby. Whether or not your favorite language is on that list, you'll broaden your perspective of programming by examining these languages side-by-side. You'll learn something new from each, and best of all, you'll learn how to learn a language quickly.