Learning from Giants #41
Learning from Giants #41
Code comments by the Redis author, Architectural decisions in Neon - a serverless Postgres alternative, and How to excel in tech without learning to code.
👋 Hi, this is Mathias with your weekly drop of the 1% best, most actionable, and timeless resources to grow as an engineering or product leader. Handpicked from the best authors and companies.
Did a friend send this to you? Subscribe to get these weekly drops directly in your inbox. Read the archive for even more great content. Also: I share these articles daily on LinkedIn.
On code comments
Code comments are probably one of the most debated, inconsistently applied software engineering practices, even among senior engineers.
There are some large companies where you almost won't see them at all.
For instance,
reports in their deep dive on Meta's culture:"Inline code comments are also very rare. [...] Originally, this was a conscious decision in order to both push people to write clean code - with easy to understand variable names and structure - and to foster more collaboration and personal connection."
Yet if you look at large, complex code bases, particularly some in harder-to-read languages, they will often have large amounts of comments. And when you'll hit edge cases or try to debug these systems, these comments should be a huge help.
Here's the take of Redis author Salvatore Sanfilippo aka antirez:
"In my opinion, writing comments is of paramount importance in order to produce good code, that is maintainable in the long run and understandable by others and by the authors during modifications and debugging activities."
📗 Salvadore Sanfilippo's Code comments article is a bottom-up retrospective on code comments in software by looking at the Redis codebase. The author categorizes comments and gives their opinion on each category. While function and why comments are well known and accepted, the author puts a name on the most debated ones: Guide and Trivial comments.
"Guide comments do a single thing: they babysit the reader, assist him or her while processing what is written in the source code by providing clear division, rhythm, and introducing what you are going to read."
"However, a guide comment can degenerate into a a very bad comment: it can easily turn into a "trivial comment". A trivial comment is a guide comment where the cognitive load of reading the comment is the same or higher than just reading the associated code."
Architectural decisions in Neon
Databases are not monoliths. They're a collection of subsystems that provide the expected querying and storage features and hopefully a bit of resilience.
For some of them, such subsystems can be deployed and scaled independently to optimize performance. Depending on if they're I/O or CPU intensive or require a lot of storage, they may even need different machine types.
When moving databases to the cloud, engineers are unbundling these subsystems to use existing cloud primitives.
⚡️ Introducing Neon.
"The idea behind Neon is to create a new serverless Postgres service with a modern cloud-native architecture. When building for the cloud it usually is a good idea to separate storage and compute."
Still not clear? Neon's idea is to keep full Postgres compatibility by deploying Postgres instances with a custom storage backend built on top of cloud primitives.
📗 Heikki Linnakangas's Architecture decisions in Neon and the collection of Neon RFCs in the Github repository are a great window into how databases are being built on cloud primitives. What's interesting is how much the cloud-native solution is inspired by the actual Postgres storage subsystem.
To read more: Neon’s RFCs on Github.
How to Excel in Tech Without Learning to Code [a16z]
"As a general rule, for product managers technical literacy is non-negotiable."
But if you're in Recruiting, Marketing, Sales or any leadership position in a tech company, that applies to you too. Because being technical is a spectrum, not a binary statement.
"Being technically literate simply means that you're comfortable with the basics of how technology works, and critically, you understand the area you work in with more depth"
Now that we all agree, how to grow this technical understanding? Your first action is to stop treating tech as purely magical.
Did something break in your company? Ask engineers to explain to you what happened.
Is a big project delayed because of technical complications? Read the details.
You won't understand everything from day one, but remember that none of the engineers did when they started either. They probably Googled their way through.
So get good at Google (and ChatGPT) too!
📗 Justin Gage's "How to Excel in Tech Without Learning to Code" explains the value of technical literacy for non-technical people. As the title says, it can make a huge difference in your day job, and it's not about writing code. Justin then gives tips for becoming more technically literate and recommends following some people on social media.