Jim Nielsen arguing that values should drive decision making, not data: Data tells you what people consume, not what you should make. Values, ethics, vision, those can help you with the “should”. “What is happening?” and “What should happen?” are two completely different questions and should be dealt with as such. The more powerful our ability to understand demand, the more important our responsibility to decide whether to respond to it. We can choose not to build something, even though the data suggests we should. We can say no to the data.

Jampa Uchoa sharing the learnings from being an engineering manager for a decade. The metaphor of 'transparent umbrella' struck a chord with me. A good manager is more like a transparent umbrella. They protect the team from unnecessary stress and pressure, but don’t hide reality from them. Telling the team: “Our users aren’t thrilled so far. We need to find ways to better serve them. The project risks cancellation if we don’t.” That’s fair game. They deserve to know. When you do deliver hard news, state it clearly and focus on how the team will do about it. If you act scared, they’ll be scared too. Your goal is to get them thinking about the next steps.

There's a GitHub project called posturr that blurs your screen when you slouch. This comment on Hacker News by avalys explains the inverse relationship between a developer's posture and their productivity. You can measure my productivity by how slouched I am. Sitting up straight at my desk, chair locked, perfect posture? I’m doing nothing, maybe looking through System Preferences to change the system highlight color. Sliding down in my chair like jelly, with my shoulders where my butt should be and my head resting on the lumbar support? I’m building the next iPhone and it’ll be done by 2 AM. Ha!

Mark Carney's speech from Davos 2026: […]we aim to be both principled and pragmatic – principled in our commitment to fundamental values, sovereignty, territorial integrity, the prohibition of the use of force, except when consistent with the UN Charter, and respect for human rights, and pragmatic and recognizing that progress is often incremental, that interests diverge, that not every partner will share all of our values.  So, we're engaging broadly, strategically with open eyes. We actively take on the world as it is, not wait around for a world we wish to be.

This research report from Motilal Oswal which compares the current AI headwinds for the Indian IT industry, with the cloud build-out period of 2016-18: Lessons from the cloud build-out: Headwind, then a huge tailwind: The present AI investment cycle closely resembles the early cloud build-out period (2016-18), where cloud initially acted as a headwind for Indian IT services. During those years, cloud migration and platform consolidation eliminated several traditional service lines (infrastructure management, legacy hosting, on-prem ops) and triggered pricing pressure in adjacent portfolios. However, once the cloud infra build-out stabilized, the next phase created an entirely new set of revenue pools: application modernization, cloud-native development, re-architecture of legacy estates, data engineering, DevOps, managed services, and security. These work streams ultimately more than offset the services that cloud displaced, leading to a multi-year technology services upcycle. This gives me hope.

Kent Beck's thought provoking post on, what he calls, 'bridge model' to make connections with others: Here’s the mental model that finally helped me: a bridge. I can unilaterally construct a bridge to another person. I can reach out. Make contact. Say something real. The further the distance—emotionally, culturally, socially—the harder the bridge is to build. But it’s possible with almost anyone of positive intent. (It’s also possible with people whose intent toward me is negative or merely transactional. That’s a different problem.) With the bridge in place, I can walk halfway across.

This insightful post by Stephan Schwab where he shares a brief history of how we have dreamt of replacing developers and failed. But the pursuit of this dream has created enormous value. Perhaps the recurring dream of replacing developers isn’t a mistake. Perhaps it’s a necessary optimism that drives tool creation. Each attempt to make development more accessible produces tools that genuinely help. The dream doesn’t come true as imagined, but pursuing it creates value. COBOL didn’t let business analysts write programs, but it did enable a generation of developers to build business systems effectively.

This comment by nicbou who is sharing their thoughts on the layoffs among technical writers due to AI. I write documentation for a living. Although my output is writing, my job is observing, listening and understanding. I can only write well because I have an intimate understanding of my readers' problems, anxieties and confusion. This decides what I write about, and how to write about it. This sort of curation can only come from a thinking, feeling human being. I revise my local public transit guide every time I experience a foreign public transit system.

Carette Antonin reflecting on the recent viral tweets of Jaana Dogan and Andrej Karpathy and how 'Influentists' are hyping up AI only to add context later on, which ends up deflating the hype. This pattern of “hype first and context later” is actually part of a growing trend. I call the individuals participating to that trend “The Influentists”. Those people are members of a scientific or technical community, and leverage their large audiences to propagate claims that are, at best, unproven and, at worst, intentionally misleading.

Bryan Cantrill reflecting back on his days when he decided to become a software engineer. When I entered university in 1992, it didn't feel like the right time: the economy for new grads was very grim -- and I knew plenty of folks who were struggling to find work (and accepting part time jobs that didn't need a college degree at all while they searched for something better). I never doubted going to school, but I also have never taken a job for granted. When I fell in love with computer science as an undergraduate and realized that I wanted to become a software engineer, it didn't feel like the right time: Ed Yourdon had just written "The Decline and Fall of the American Programmer", which boldly told any young computer science student that they were wasting their time -- that all programming jobs would be done by cheap labor abroad.

Morgan Housel shares his theory about nostalgia. I have a theory about nostalgia: It happens because the best survival strategy in an uncertain world is to overworry. When you look back, you forget about all the things you worried about that never came true. So life appears better in the past because in hindsight there wasn’t as much to worry about as you were actually worrying about at the time. Ha!

Gokul Rajaram explaining the difference between dashboard product and pipes product, and why it is important to identify early on which product are you are working on. Every startup needs to make a choice: is their product a dashboard product or a pipes product? Dashboard products are used directly and regularly by end users as their primary interface for accomplishing tasks. The goal for these products is to get customers to live in the product. The primary North Star metric for these companies is active users (daily / weekly / monthly, depending on the natural frequency of customer usage for the category).