Hasnain says:

"Researchers have found some answers here, too. There is evidence for a decline in fathers’ testosterone even during the partner’s pregnancy, so cues from the mother could be important. There is also evidence that postnatal contact with the infant can both lower T and increase oxytocin. Perhaps something about the appearance, the odour or actual tactile contact with the infant is responsible. A notable 2015 study showed that skin-to-skin contact with premature infants increases both parental and infant oxytocin levels. These findings predict that human fathers should become more strongly bonded to their children if they spend more time in close proximity to them as infants, and this has indeed been demonstrated."

Hasnain says:

Really engaging read, not just on databases, but also on a long career journey and how to continue learning and growing.

The advice at the end definitely stands out for more than just database engineers.

"When deciding where to work, which team to be a part of, or how to spend your energies outside of work, it’s always helpful to remember that we have the ability to influence our own luck. While you can’t always control the “right time”, you may have a better sense for the “right place”."

Hasnain says:

Uhhhhhhhhhh

“The U.S. military is buying the granular movement data of people around the world, harvested from innocuous-seeming apps, Motherboard has learned. The most popular app among a group Motherboard analyzed connected to this sort of data sale is a Muslim prayer and Quran app that has more than 98 million downloads worldwide. Others include a Muslim dating app, a popular Craigslist app, an app for following storms, and a "level" app that can be used to help, for example, install shelves in a bedroom.”

Hasnain says:

Quoting one of the top hacker news comments on this:

"The author in a self-deprecating way says that he’s not a mathematician, but just a programmer. Bear no mind to that: this is one of the best popular expositions of Goedel theorem I’ve seen. Everything is very accurately explained, there are no silly mistakes and untruths one often sees mentioned in context of Goedel theorem, and even the original proof is sketched in a very approachable manner, striking a very good balance between getting across all crucial ideas, and skipping most of the distracting technical aspects (which are important and interesting, but I think only to mathematicians, haha). Great job all around."

This is a really good in-depth explanation of the incompleteness theorem and I can now finally say I (sorta) understand it.

(also trying not to get sucked back into doing some more proofs...)

Hasnain says:

Really good talk on understanding work that really makes a team succeed, from the perspective of the team, the manager, and a person trying to navigate their career.

"Your job title says "software engineer", but you seem to spend most of your time in meetings. You'd like to have time to code, but nobody else is onboarding the junior engineers, updating the roadmap, talking to the users, noticing the things that got dropped, asking questions on design documents, and making sure that everyone's going roughly in the same direction. If you stop doing those things, the team won't be as successful. But now someone's suggesting that you might be happier in a less technical role. If this describes you, congratulations: you're the glue. If it's not, have you thought about who is filling this role on your team?

Every senior person in an organisation should be aware of the less glamorous - and often less-promotable - work that needs to happen to make a team successful. Managed deliberately, glue work demonstrates and builds strong technical leadership skills. Left unconscious, it can be career limiting. It can push people into less technical roles and even out of the industry.

Let's talk about how to allocate glue work deliberately, frame it usefully and make sure that everyone is choosing a career path they actually want to be on."

Hasnain says:

While I'm a bit sad it took this long, I'm glad github did what is right here.

"No matter what we do to protect developer rights, we still must work within the boundaries of the law. And the DMCA’s current boundaries are hurting developers. One way to address the problems with the DMCA is to work to improve the law itself—and to prevent even worse laws from being enacted around the world."

"Nonetheless, developers who want to push back against unwarranted takedowns may face the risk of taking on personal liability and legal defense costs. To help them, GitHub will establish and donate $1M to a developer defense fund to help protect open source developers on GitHub from unwarranted DMCA Section 1201 takedown claims. "

Hasnain says:

Oof :/

“A college class had two teaching assistants: one male and one female. At the end of the semester, the students scored the male TA higher on course evaluations, while the female TA got five times as many negative reviews.

There’s just one problem: They were the same person.”

Hasnain says:

Good read on avoiding a common trap when getting used to expressing software better using the type system. Types are useful when they codify invariants or properties of your business logic - names, not so much. (I'll admit I do use `newtype` or equivalents a lot, but usually to cut down on typing).

"Newtypes like these are security blankets. Forcing programmers to jump through a few hoops is not type safety—trust me when I say they will happily jump through them without a second thought."

Hasnain says:

Such a motivating human interest story.

“He closed our last interview with the story of a tech worker who learned Kubernetes while watching videos of Hightower in prison. He met Hightower at an event, and in a low voice — his boss didn't know he had been in prison — he told Hightower his story and thanked him for changing his life.

"That's how I want to be remembered," Hightower said. "I want to be remembered as this person who helped other people find out how to be better than they currently are."”

Hasnain says:

This is a pretty massive collection of libraries, posts, and tools for better testing Rust code.

Bookmarking so I can use this starting uh... tomorrow